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.

It seems to me that most of the points made are examples of bad requirements practices, but should not be taken as an argument for eliminating requirements entirely. The alternative activities described highlight practices that support the development good requirements.

In my experiences developing software for DOD contractors, I saw many examples of the issues highlighted in the article – partly due to poor practices and partly due to the long term lumbering nature of some of the projects. However, I also could see the necessity for numerous and detailed requirements – they provided a basis for planning, contractual agreements, and communications among the many developers and teams on large projects. No doubt better practices could have improved the requirements that were developed, but they still needed to be developed.

On the other hand, I also developed software for clients using exactly the alternate process you describe: I sat with actual users watching them perform the work that I was to implement in a software solution, I developed the solution from the outside in – essentially prototyping the interfaces and process controls first so I could sit with the customers and walk through the solution so I could ask “What do you do here” and a lot of “what happens in the event that…”. Very little in the way of requirement writing was done on these projects (and these were Fortune 500 clients), and the products delivered literally delighted the customers. But these were small projects and better suited to such practices – I would call them agile, but this was in the first half of the 90’s and the term wasn’t coined yet.

So, as is typically the case, the answer to the question of whether (or to what extent) we should have requirements is “it depends”.

About the author

Martin Eriksson

Martin Eriksson has 25+ years experience building world-class online products in both corporate and start-up environments for global brands such as...

Comments 19

Let’s say I don’t have a detailed requirements document, rather the detailed requirements reside in various task descriptions. Going forward a few months after the feature was released, a bug is found or we need to make changes and test the existing functionality. How would the developer/PM/QA know the expected behavior? They would need to search in Jira (or similar system) to find the tickets? How would they know the requirements they found are the most up-to-date (perhaps there have been a few iterations on the feature’s implementation)?

That’s why we need good documentation – which is after the fact and not to be confused with an upfront requirements doc. And to your point after a few iterations your requirements doc doesn’t reflect reality anyway.

We call them “User Requirement Specifications”, so they describe the problem, not the solution, and they are absolutely mandatory.
You describe the internal dev documents from the PM down to the dev teams, how the goal to the URS can be reached. Most of your concerns are valid.

But:

ad # 3 Customer collaboration can only be done by a URS, and not by just meetings with the customer, visits, meetings, observations and thoughts. It needs to be written, down and accepted by both parties. How you implement that internally is the dev. team problem

ad # 2 Bigger projects cannot be prototyped. You need to have technological prototypes of course, but before, otherwise you shouldn’t even talk to the customer. Or have fallback solutions.

Ad ‘They are open to interpretation’: If specs are open to interpretation you failed your job. That’s the only reason such a document exists. To weed out misinterpretations. They are the biggest reason to deal with customers who forgot what they spec’ed, change their specs on demand and are the basis for final payment.

I gotta say this article is mostly relevant to working in small product-focused groups. And the fact is that a lot of companies simply don’t work this way. Especially not big corporates, even if they do work in an agile manner. In addition, at some point, the paying customer is not the only client – for instance: features the company wants to promote and try-out also have inbound consumers requiring A/B test, business logic etc.

I belive that mock-ups and prototyping are super important and so do personal interactions – but at some point – you’re gonna need these two teams to align to the same business need and it’s gonna get hard setting up meetings every day for that 1 relatively small feature.

I hate to be the party pooper but sometimes MRDs & PRDs are a necessity 🙂

Like any tool, there is a time and a place where it makes sense, and
where it doesn’t.

I think what you are arguing is that thick
waterfall-style stage-gated requirements are not adaptive to iterative
software development ideology and process. That’s fair.

I think Agile can be equally as dysfunctional as writing a 100 page requirements document however, when a Product Owner just throws a bunch of stories into an epic without thoroughly composing the project, writing a basic summary of what that epic is, or providing the fundamental strategic justification behind the project. This lack of context can be problematic, for engineers, portfolio managers … and the product mgr alike, when they have later to defend, justify, or present the project/epic .

Personally, I’ve found a balance to exist somewhere in the middle – define the project/epic … provide that context and justification, in a short “project definition” document (1-3 pages), and link it to the user stories for that project/epic, providing context and purpose. I avoid the painstaking detail of a traditional PRD, but this at least provides the context and the glue that binds together the individual stories.

This approach may not be necessary for iterative UI optimizations, and may not be sufficient for a complex physical product – but it serves me well for software products.

Although I agree with your premise and your deconstruction of the requirements document is thorough, it is a shame that the alternative option you describe is so wishy-washy in comparison: “Do Agile” is a bit of a lazy riposte for those that see these documents as the only way to organise a product development process for all stakeholders. Some people “need” this crutch, it is a drug to them, how do you educate them otherwise in a real business setting?

I find time and again that the Jobs To Be Done approach works so well because identifying the problem can be hard. So it’s easier to focus on what the user is doing and as you define this, with the users, the problems start to become obvious. Our tool: https://www.getskore.com uses simple lean principles, along with JTBD, to ask what value each step delivers to the overall experience. This forces everyone to ask tough questions and really highlights the problems that need to be focused on. From this model we would create ‘stories’ that the dev team can work on.

thanks for posting this, it is aligned with the ongoing challenges that I think every product owner has

It so puts my feelings and experience in to words. Very well written Martin.

You need something. It “just” needs to be right-sized. If you start building blindly, you might end up with a house or a fence or the makings of a bonfire. If you spend too much time writing, the open window slams on your fingertips. Balance. Always about balance.

Product Managers are experts in minimum viable product. PRDs should also be in scope for that methodology. The characteristics you listed do not apply when MVP for PRDs is used.

While “requirements” is a misnomer, and having a document that takes more time to build that execute is a recipe for disaster, its good to have a small bible that shows the goals, initial feature requests with prioritization, and pain points that need to be solved, among other top level items. As everyone agrees, a document should not and can not replace collaboration with the various disciplines inside and outside of the company to create the best product. But there needs to be a single point as a foundation for the program to limit confusion.

Very well said. PRD’s can be overly long, but too much “high level” input without a guiding product definition can lose the voice of the customer and leave the product vulnerable to committee think. Then you get a Zune.

Can’t agree more as to how un-collaborative PRD’s are. Really bang on. In this day and age of slack like communication, writing long documents to communicate beats the whole purpose of collaboration. As long as there can be an archive of the communication between the stakeholders, breaking things down into smaller stories makes sense. It is all about design, develop, test, refine.

Good advice, and though it can seem scary to not have a 300 page req’s document to hide behind, it is a false security. On the money Martin.

I find that a combination of the two approaches is required in many settings (especially large enterprises). Agile approaches can lead to conversation fatigue as you go over the problems/requirements again and again with stakeholders & the lack of a signed off ‘spec’ can make it difficult to get business support, budget and work started (as not everyone in your business will ‘get’ Agile). I certainly wouldn’t say that PRD’s should die – just that they should be used to support the conversations and act as a higher level or holistic tool / record.

I agree you need some high-level documentation of the decisions you make through the agile process I outline – but these can simply be the prototypes, mockups and other artefacts produced along the way rather than an onerous document.

Personally, I’m more interested in defining/documenting the *problem* than the solution.

I believe it is Product’s key responsibility to the team – to thoroughly understand and communicate the problem, goals, and success criteria when kicking off solution design with the team. To me it always seemed inefficient to *not* do this – Greater risk of confusion among the team or a market-fit miss and needing by designing a solution that doesn’t fit the actual problem.

It might be more accurate to call what I’m describing a “Problem Definition Document” than a PRD. And it need not be a large document – a couple pages is ideal! Forcing yourself to crystallize the ‘what & why’ enough to articulate it concisely, drives clarity. And documenting it makes it reference-able by the team offline, which helps keep the solution aligned with the problem and success criteria.

Join the community