SUNDAY REWIND: Product requirement documents must die

In this Sunday Rewind post, we go all the way back to the pre-pandemic days of March 2016 when Martin Eriksson shared his thoughts on why Product Requirement Documents (PRDs) don’t always work.

Martin believes that PRDs and various other documents similar to this focus on the solutions, not problems. He says “I believe product manager’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) upfront.

Additionally, he mentions how they are often “open to interpretation”. The individual who reads them and has to act on them is generally not the person who wrote them, so you’re basically playing telephone whispers with your product.

Martin offers an alternative and argues that it’s important to go back to the first principles and work collaboratively with research, design, and engineering as one team to design the right product for your customer.

He closes by listing what you should focus on instead of writing a PRD:

• Individuals and Interactions.
• Working with software (or hardware)
• Customer collaboration

To delve further into Martin’s argument, read Product Requirement Documents Must Die in full.

Want to share your thoughts on this article? Use Circle—our members’ discussion platform exclusive to MTP members—to drive the discussion and share your product experiences.