November 3 2015
Rethinking MRDs and PRDs at Retrospect
For Product Management, two requirements documents define a product: the outward-looking Market Requirements Document (MRD) and the inward-looking Product Requirements Document (PRD). The MRD describes the problem, and the PRD describes the solution. These documents provide a complete view of the product: what it is and why it is. They ensure everyone involved is on the same page.
I’ve read about other companies doing away with them. I doubt it. Every product needs something defining what it is and why it needs to be built. Code doesn’t count. Call them what you want. You need these two documents.
Every significant Retrospect release has an MRD and a PRD. In 2013, we redesigned our documents. I’ll walk through why and how for form and function.
Form
Like most companies, Retrospect originally used Microsoft Word documents for requirements documents. It’s the standard format for document, so it’s understandable. But it had downsides. The product manager would write up a draft and send it out to a group. Each person in the group would track changes in the Word document, comment on various points, and send it back. The product manager would then walk through each reply and edit the original to answer those questions. The editing proces was cumbersome and opaque, and it was difficult to compare drafts when successive versions were sent out. Irksome.
We wanted to solve four problems (like a meta-requirements document):
- One copy: There should only be one place to find the document, and people need to edit it in that location.
- Versions: The document should be transparently versioned with support for multiple authors.
- Comparisions: The versions should be easily comparable, so that anyone can see what changed and who changed it.
- Image Support: The document should support embedded images. Word supported this; the new system should as well.
All of these can be boiled down to transparent and useful. We wanted to remove the small bits of friction in our requirements document workflow. That friction made it harder to find the latest version of the document, update the document, see others’ updates, and remain on the same page.
Our solution was a wiki. Wikis provide all four qualities: one copy, versions, comparisions, and image support. And with links, we could easily connect the MRD, the PRD, and the per-feature Engineering specs. We already had a Mediawiki instance, so we leveraged it. One thing that came for free was automatic update alerts through Mediawiki watchlists.
What we lost in the migration was the universal language of Word. It’s esoteric, but people get used to it because everyone else uses Word. The Engineering team was comfortable with Mediawiki; the Sales and Marketing staff was not and still aren’t, two years in. But no medium is perfect. Choose a form that reduces the friction to a minimum for your team. Think about the path of least resistance between product ideas and people’s feedback.
Function
I imagine one reason companies abandon requirements documents is their content. I’ve read quite a few that had a remarkable amount of cruft–superfluous content that didn’t contribute in any meaningful way. Looking through a decade-old Retrospect PRD, I found a vision statement, a confidentiality agreement, a revision history, and a company logo.
Sections like “Vision Statement” are unnecessary business-speak, a professional veneer for content of any quality. You might as well play buzzword bingo with the remainder of the document. Points for “synergy” and “best of breed”. Larger companies find these sections necessary. We’re not that big.
When we redid ours, we removed cruft. Every section needed to be useful. Here is what we use these days.
Retrospect MRD
- Purpose: What problem are we trying to solve? Keep it simple and short.
- Audience: Who has this problem? Specify interested current customers and type of potential customer.
- Appeal: Why does the audience want this problem solved? Include customer interviews and feedback.
- Competition: Who else is already solving this problem and how? Link to details in a separate document.
- Notes: A record of decisions and on-going discussions.
Retrospect PRD
- Features: A list of features and use cases that solve the MRD’s problem.
- Release Details: Various topics such as version number, documentation changes, supported languages, and system requirements.
- Notes: A record of decisions and on-going discussions.
Useful documents. No cruft. This is what we do.
