Product Requirement Documents Must Die

I’ve been doing product management for a long time, and I remember very well what it was like to work on Product Requirement Documents (aka PRDs, Market Requirements, Business Requirements, Functional Specs, and more). But the last one I wrote was in 2005, and it’s not because they’re a lot of work (and they are) but because they just don’t work.

Unless you’re building a nuclear reactor or similar high risk, capital intensive product then requirements documents are simply the worst possible way to bridge the gap between the customers’ needs and the team that are trying to build the solution.

Why? Let me count the ways…

Why Product Requirement Documents suck

1 Waste. Very little in a product is actually required, and by setting everything up as a requirement we conflate priorities and set the stage for feature bloat instead of what the customer really needs to solve their problem. This feature bloat is a massive waste of effort and resources, as studies such as the Standish Group Report showed as far back as 2006 – even in successfully delivered projects 45% of the features were never used!

“Software development has been steered wrong by the word ‘requirement,’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. The word ‘requirement’ is just plain wrong.”
– Kent Beck, Extreme Programming Explained

2 They focus on solutions, not problems. I believe product’s job is to focus on defining and prioritising the customers’ problem, not the solution. This means that once you get it in front of the design and engineering teams, you can work together to come up with the best possible solutions to that problem that fit within the scope or budget of the project. However, by definition, PRDs force you to start documenting features and requirements (the solutions) up front.

3 They are written at a point in time – and are as out of date as the time it took to write them. We all know how quickly the technical landscape we work in moves, but so do the markets, our customers, and even our companies’ strategy! By the time we’ve written a PRD it is almost always out of date, leading to an endless cycle of updating requirements instead of building product.

4 They are only as good as their input. Garbage in does not beget gospel out. The problem here is that several generations of stakeholders have learned to brainstorm requirements which they think they might just need someday, guaranteeing that a large percentage of the functionality that they specify really isn’t needed in actual practice. But since they’re all requirements – they still get built.

5 They are open to interpretation. The person who reads them and has to act on them is generally not the person who wrote them, so you’re basically playing telephone/chinese whispers with your product. The cumulative errors in interpretation of the requirements, from the writer to the implementer to the tester, is a recipe for a disaster.

6 They pass the buck. The hardest part about any software project is figuring out what to build – so engineering teams ask for specs, product teams write requirements, and everyone thinks they’ve done their job except the customer never ends up using the product.

“The hardest single part of building a software system is deciding precisely what to build.” – Fred Brooks, No Silver Bullet (1987)

7 They limit your product. This is counter-intuitive but by using requirements you effectively cap the possible outcome with those requirements and then continuously reduce scope from there as you begin to run out of resources or time. This means all those things that were meant to delight your customers usually get thrown out first in order to deliver anything functional.

What’s the alternative?

As usual I argue that it’s important to go back to first principles and work collaboratively with research, design, and engineering as one team to design the right product for your customer. Since what we’re trying to do is bridge the gap between the customer and the product development team as efficiently as possible, here’s what you should be doing instead of wasting time writing a Product Requirement Documents (borrowing those first principles from the agile manifesto):

1 Individuals and Interactions. There is no replacement for high bandwidth communication. Instead of relying on writing specs and throwing them over the wall to engineering, this should be an iterative process done collaboratively to leverage the insight and creativity of everyone on the team. Whether you’re doing user story mapping, design sprints, or any other technique, collaboration will yield faster, clearer results because they were achieved in conversation with each other.

2 Working software (or hardware). Prototype, prototype, prototype. Whether it’s a user flow in post-it notes, a page sketched up on paper, or a functioning interactive prototype, put something together that showcases the actual experience and can generate discussion internally as you hone the hundreds of minute decisions that make up a product experience, from the back-end infrastructure needed to support it, through to the precise user flow.

3 Customer collaboration. Get out of the building! Talk to your customers, understand what their problems really are and bring them back to the team. Then once you have some prototypes in place, test them – over and over again – to refine not just the user flow and usability, but also the desirability of the product, and thus its feasibility in the market.