Ditch the long PRD
Writing a “Product Requirements Document” or “PRD” all too often the sole responsibility of a Product Manager. (Particularly in Africa.) It is a single document that outlines all of the reasoning, context, and scope of a particular solution or feature. It’s a comprehensive briefing document that you can share with designers to design and developers to build.
They’re hardly ever read.
PRDs can often expand into over 20 pages — I’ve even seen a +40 page one before. This madness has to stop. If you really need one, it should be shorter than 2 pages. It’s better to not have one at all. Let me explain…
The benefits of a PRD
The reason that these documents are so damn popular is that they give everyone a sense of clarity. To know what is going to be built. It keeps all of the information in a single place that is easy to find and reference.
They also define the process to follow and act as a record of what was supposed to be built and why. It created clear deadlines on when things will be shipped and might even include a timeline with dependencies and a list of all possible user stories.
Business leaders and the other teams in the business prefer them as they help draw clear boundaries of responsibilities. PRDs are also great for weighing one option off against another.
No plan survives contact with the customers.
The problem with a long PRD
Despite the benefits around certainty and scope, real-world projects don’t work like that.
Time
Firstly, these things take a lot to put together. The same as writing a Business Plan, there is no level of detail too low. We typically spend loads of time writing until all the uncertainty is gone. We end up with a document so verbose that no one has the time to read it. (Ask the devs what % they actually read.)
Uncertainty
The truth is that the uncertainty is never gone — just hidden. There are infinite real-world variables in building software products — in constant motion. Any comprehensive document is laced with hidden assumptions: the API docs are correct, the data is reliable, our polls are unbiased, etc. You only remove uncertainty by shipping.
Agility
The PRD leads you towards a waterfall approach where information only flows in one direction. Insights and learnings from the implementation never make it back into redefining the solution — only tweaking it along the way. You won’t iterate and ship multiple versions if there is already a single source of truth. And definitely not if that source of truth is 45 pages long. No ‘agile’ happening here.
The case for the 2 page PRD
There are plenty of company cultures and executive teams that require documentation of any potential solution. In these cases, you should adopt a 2 page PRD that summarises the direction and importance of the solution. A discussion document to get buy-in and budget in a direction to explore.
If you work in a big corporate, maybe start with Amazon’s 6-pager Memo — but this is not to be confused with the Amazon Backwards Press Release.
Share Context
A PRD must align with the business strategy and product strategy. Start with the high-level business objectives and unpack the gap between that and the data to show why there is a problem worth solving. (You probably should not build anything if you can’t do this…)
Outline the opportunity
At a high level, describe how the solution would solve this problem for a specific customer segment. This should be short and high level and a max of 1–2 paragraphs. Mention the key features and benefits as you describe how it all comes together.
Focus on measures & uncertainties
Stating what KPIs or metrics the solution should impact is critical to (a) show the value to the business and (b) put a stake in the ground that you can reference later. Specifically, outline some of the core assumptions that need to be true for this solution to be valuable.
Lay out the approach
Instead of defining the details of the feature, unpack the steps it will take to implement. Outline what you will build first, how often you will review the key assumptions, as well as the iterative approach to roll out, refine and test the solution. Highlight the biggest unknowns. Question the integrity of the data and leave it open ended to explicitly be updated as you learn more.
I am sorry I wrote you such a long letter. I did not have time to write you a short one.” — Blaise Pascal
You should understand the problem well enough to be able to explain it clearly and concisely. Fix your understanding before briefing it in if you don’t.
See: Amazon’s writing style tips
A better approach
If PRDs are so bad, what should replace them? The answer depends on the problem, your market, team culture, and experience. But it should involve the following:
- Focus on customer problems and the experiments to try, not solutions. The ProdPad Lean Product Roadmap has superb articles on ditching a timeline Roadmap. Their initiatives and experiments approach is a good way of helping you focus on the biggest problem. (If the next feature you plan to build does not address the most critical problem to solve, then why are you doing it now anyway?)
- Break down the silos of responsibility for different teams and different stages. Have team including developers, designers, sales, and marketing responsible for shipping the whole solution from input, build testing, and support.
- Have clear measures for what KPIs you think will be impacted and actively track how you’re affecting them. Make sure that the whole team knows them. You need to be able to tell success from failure to run experiments.
While implementing these suggestions will change from team to team and context to context, it generally works best as a Kanban-type board with a backlog of experiments and some swim lanes for goals. It helps to see all the options in a single view to better handle trade-offs.
A framework that I have found effective in these scenarios is Flight Levels. It has a clear way of breaking down smaller tasks from strategic objectives. I often suggest teams combine this structure with the experiment backlog approach from Lean Product Roadmapping.
Remember: there is nothing more expensive than building the wrong thing.
In summary: you don’t build great products by planning everything upfront and hoping the execution works out. You can only build great products by shipping, learning, and improving. Writing a PRD is more likely to give you a false sense of control — whereas it is better to stay honest about the uncertainty so that your whole team can improve the solution rapidly.
Does this resonate with you? What tips would you have for someone trying to get away from long PRDs? Let me know on Twitter or leave a reply below.
