“The faintest ink is more powerful than the strongest memory.” – A Chinese proverb
The term PRD —Product Requirements Document— has gone out of favor for a while now. The waterfall approach to solution delivery and its usage of the PRD has a lot of drawbacks. But did we dump the good along with the bad? Let’s explore.
Is your team agile?
The frequent refrain I hear about documenting the product requirements is, “we are an Agile shop.”
Agility is about the mindset. Unfortunately, the uppercase ‘A’ Agile took over the lowercase ‘a’ agile (or being agile). The Agile industrial complex has distorted the conversation. The jargon has become all-important — user story, epic, story points, retrospective, scrum master, product owner, and so on.
Words are our aid in communicating. For example, the word ‘tree’ is not the tree, or the word ‘door’ is not the door. Communication is a vehicle (the means). The words can become a hindrance if you’re not careful about distinguishing between the means and the end goal.
So, is your team Agile or agile? There’s nothing wrong with using a framework to orient. In fact, the Agile Manifesto has got several things right and proven so by several successful product launches over the years. Scrum and Kanban are fantastic methodologies to take inspiration from. The problem: you can’t make it a my-way-or-highway paradigm — taking the book too literally than what your situation/context demands. Be pragmatic.
Problems with the Product Requirements Document (PRD)
There used to those days when the enterprises believed that they have to write every bit down to the utmost detail so that the worker bees, the developers, can code those details. What’s the problem with it? Several, but let’s look at a couple of them:
- Requirements are not set in stone. You will keep learning more as you build. Envisioning is one thing, but building it and making it valuable for your customers and your business is entirely different. The iterative nature of agile is the key. You can’t arbitrarily draw a line and say here are the requirements, gold-plated, now run with it. (See: Explore to build or build to explore?)
- Undermining the autonomy. The traditional PRDs mix the problem and the solution. By providing a prescriptive solution, you’re undermining the autonomy a knowledge worker craves about. Your developers love it when you paint a vivid picture of the problem space and ask them to explore and propose viable solutions. Think about it, are you treating your development organization as knowledge workers or worker bees?
Did the pendulum swing too far?
Okay, we don’t like the PRDs, but did the pendulum swing too far to the other side? You’re uncool if you’re not writing a couple of sentences in a User Story format.
User stories and Job stories have their place, as I discussed here previously. However, as a Product Manager (PM), you need a command on the problem space to write them. Zoom out a bit. The command comes from the clarity in thinking. See the big picture. Show me any activity other than writing in long-form and presenting your thoughts to bring about clarity. Nothing can replace holistic thinking. Your user stories need to be tied together as a cohesive unit.
Fix the PRD or call it the Modern PRD™ (Whatever works for your team)
Instead of writing copious amounts of needless details, focus on few key points as a checklist:
- What is the problem you are solving?
- What assumptions (or bets) are you making?
- How do you plan to validate them?
- What user research have you done and a brief overview of how you’re using the personas (if you’re using them)?
- Have you provided details about the circumstances under which the job executors are hiring your solution ala JTBD?
- Are you providing enough leeway to the developers and the designers to develop alternatives and technical feasibility associated with it? (Note: A low-fidelity mock to explain your workflow is a good thing as long as it clarifies and empowers the designer to produce a superior user experience.).
- What metrics are you planning to track, and how are they aligned with measuring the right attributes of your progress?
Guard against these tendencies
Everything is set in stone fallacy
The fundamental problem with writing something as a PRD is for the team to treat it as a static document. One of the Agile Manifesto principles is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” So treat your PRD as a living and evolving document with a bias toward experimentation and progress.
Keep writing the document on-and-on is a good way to undermine the project. Sure, that’s not your intention. Prove it by making the document iterative. As soon as you have some sections ready, seek feedback, and more importantly, involve the key players early, including technical leads, designers, et al.
As a tech lead or a designer, I’ll reject anything that’s not described in the PRD
I’ve been there as an engineer, and I understand that you have to build something that’s not defined well enough. But as a tech leader, you have a role to play in refining and fleshing out the details. Partner with your PM and find out why there are gaps. Are they left out intentionally to allow some implementation freedom or require some technical expertise to fill in the gaps, or a genuine oversight? After all, we believe in “Individuals and interactions over processes and tools.” (That’s at the heart of Agile Manifesto)
Aversion to any documentation
The most abused part of the manifesto is: “Working software over comprehensive documentation.” Yes, I’ll take working software any given day. But the principle has stretched so much that some teams despise any documentation, not PRDs alone, technical design, product decision log, et al. I’ve already alerted about analysis paralysis above and the need for a balanced approach. Not documenting anything and saying, “I have a working software,” is a recipe for disaster. Writing working software is great, but maintaining it and enhancing it later is hard with no contextual write-up. If you’re building anything non-trivial: a) write to clarify your thinking, b) write to communicate with your team members and stakeholders, and c) in six-to-twelve months, your older self will thank you for writing these down.
My favorite PRD templates
There are several good templates available online. Here my top three favorites. The key is to adapt to your environment and modify them as needed.
Related – Further Reading