Let’s simplify the PRD template
When it comes to the Product Requirement Document (PRDs), people try solving world hunger with a doc. They hope it would solve all their Product woes. The expectation from PRDs is no less than the expectation organizations have of PMs. In a recent survey I did with 20+ product guys across B2B and B2C companies, the PMs suggested an ideal PRD should help with problem identification, context building, user research, understanding market, user stories, scope, future possibilities, stakeholder alignment. And one can’t disagree.
They want it so exhaustive and elaborate that everyone from engineering to sales can know exactly what you want to get built. If you have observed, that is also what general people try to solve with their products — and that’s precisely why a PM is *required* — to find a method in the madness.
PRD is a “product” too
Sounds obvious right? (It’s called hindsight bias)
At any given time you are managing at least 3 products. Your first product is YOU (or your resume). The second one is what you’re hired to manage, and the third one is the PRD.
Like a Product the PRD has a lifecycle, it needs to find an initial audience and then cross the chasm to find wider acceptance.
If you aren’t dealing with the PRD like you would deal with a Product you are either ignoring it or overdoing it. In either case, it’s a major loss of your personal efficacy and huge suffering for the org. Wherever there is a lack of processes — there will be communication gaps, expectation mismatch, team battles between tech and non-tech stakeholders, blame games and you may find yourself firefighting — doing the same things over and over.
Here are some contradictory expectations from a PRD:
It needs to be comprehensive, but still, be readable.
It needs to satisfy all stakeholders, but still, be brief.
It needs to describe the problem and solution in all detail, but still, be flexible to incorporate comments from various stakeholders.
It needs to be maintainable.
It needs to be a living document.
It needs to be ... divine?
And so, not surprisingly, PMs keep searching for a panacea format/template of a PRD that would solve their problems.
When I couldn’t find one for my use, 8 years ago, I created my own and put the “Sample Mobile Apps PRD” format on Slideshare. It is still being viewed/downloaded by about 10 people every day for the last 8 years. That’s over 42k people from over 50 countries. The format is of course dated — I don’t use it.
I had evolved a new PRD format that I uploaded 2 years back and it is also being viewed by roughly 7 people every day. It covers most stuff that I figured other companies also try to follow. Also, it has a nice checklist for PMs.
But, the truth is I or My team DON’T USE any of those templates now.
Because…
…oh do we have a template? I didn’t know. Will try using it next time.
…it is boring to follow the same format every time.
…half the sections do not even apply to this feature.
…oh where did I keep it? It’s so hard to find the template every time, copy it in a new doc, and start filling it up.
…it’s a small thing, does it even need a PRD?
And, that’s not how most documentation get created anyway.
A lot of documents start as a list of items on spreadsheets (emails, chats, asks, feature ideas, whiteboard screenshots), and then more keeps getting added to it as discussions happen. And then the small items get converted to a task/ticket and go to the factory. So while PRD might still fancy a template, where is the template for shorter specs, is the user story format enough? The larger solutions get documented in a random format on google docs, confluence, etc. Most PRDs get created for a transient use case, for PM’s work satisfaction. And hence, it is no surprise that they end up being short-lived, unread, and useless.
And it’s not just me, or my team or my org even. People around the world think PRDs must die.
So, why are we looking to templatize futility?
It is rendered futile in the execution, but it still is one of the most important things that holds all PM processes together.
If you look at various PRD formats from the best product companies across the world — you’d realize that not much has changed from what I created 8 years back. If you extract the key components out of what Uber, Ola, Amazon, Airbnb, Figma, Intercom, etc. each of them wants to keep only a handful of unique things: the Problem, the Solution, the Scope (in-scope, out-of-scope), the Success Metrics, and the Dependencies. Some also like to include background research and roll out plans. So that’s it, you put these things in whatever format and you should be able to get a very functional PRD for your use.
Easy, right? Why do we need a template?
Well, we use templates because we need a way to ensure we don’t forget something important. The correct word for such a thing is a checklist.
Checklists v/s Templates
Templates are one of the last remnants of the industrial revolution era factory system. Auditors and Managers would have introduced templates or prescribed formats because the people below them were probably considered of lower intelligence. A template was easy for ‘them’ to monitor and review as documents travel up and down the hierarchy. But, that’s not how modern product organizations are structured. They have flat hierarchies, everyone is a knowledge worker. Documents are shared and used across the org by various stakeholders — and everyone tries to extract what they need from it.
Sales guys are interested in the future that they can sell today, CS (customer support/success) wants to know how it solves current issues for their clients, Devs want to know what ‘exactly’ needs to be built, QA wants to know what they have to test (and not test). An ideal template is bound to be big and hairy.
A scary process (or template) leads to excuses. A process that is hard to appreciate is harder to remember and the hardest to follow. What we need are simple checklists and not templates. Applies not just to PRDs, btw.
The simplest PRD/Spec Template
So, here’s the world’s simplest PRD template: It is not a template, it’s a checklist. It’s not even a standard long list of checkboxes kinda checklist. It’s a simple mnemonic that you’d be able to easily recall while creating your next documentation — A long-form PRD or a simple user story/spec.
Why,
Business,
Success,
Depends on,
Being thorough.
And you can read and remember it like “why business success depends on being thorough?”
Easy? I told ya!
How it helps is that you can apply it to the smallest of Jira stories and the largest of Epic documents that you create. I’d show you samples.
This covers the most essential elements of the ideal PRD. Here’s what each of the checks means:
1. WHY — Start with a why — says Simon Sinek. It makes sense to start every ticket, every doc by answering this question however briefly it may be. And it would help if you begin with the question, and not put it as an after-thought. Why are we doing this? This is the place to describe “the exact problem” you are solving for, and any analysis you may have done around it. Remember that this is a checklist and not a template — so you don’t need to put a heading “WHY” in the documentation. The heading/title of this section could be anything relevant. But, please ensure that you have given enough context and described to the reader why we are doing this at all.
E.g. The expected engagement for our apps is N/user/week. The engagement of the app is lower than expected, and that affects revenues. Our top engagement feature is not getting discovered by c% users.
Target audience: Even though I dread the term ‘everyone’ — this section is actually meant for all stakeholders. More than anyone this section is for you, the PM. This helps you start on the right note and then stay focused. However, make sure you word it in a way that most business stakeholders — especially, the design/UX team would love to know if they are adding that favorite icon for increasing engagement or just for competitive parity. It makes a tonne of difference. Also, the customer success team would love to know what exact problem of their customer is being solved, so they can boast about it and earn some brownie points. Marketing would love to be in the loop so that they can plan the rollout, campaigns, and experiments.
2. BUSINESS — The last section was about the problem, this one is about the potential impact of the solution. We need to define what is the Business Impact of the feature/change that you have defined or are going to describe in the document. The order of this section (or any other following sections)is not important. Here’s where you discuss/define what the current state is and what the future will bring. How many users will be impacted, and how much? There is a list of good products that did not make any money and died. So, being ROI centric is supercritical. The real difference between a real CEO and the PM (aka CEO of the product etc.) is that PM needs to talk ROI to persuade the stakeholders on their POV — their gut feel doesn’t work. If PRD has a section on business feasibility, the impact then this checkpoint is clear.
E.g. Higher engagement is critical for increasing conversion which directly relates to the revenues. The prime reason for the lower revenue is that the users are not able to discover the engagement feature X.
Target audience: This would appeal the most to the management and your sales and marketing teams. More so, if they are approving budgets or gearing up a campaign around it.
3. SUCCESS — There needs to be a section that talks about success metrics. How’d you know if the impact is achieved? How exactly would you measure it? Enough is said in the world about how to measure what matters, so I’d keep it short. Just do it.
E.g. this feature should increase the engagement by 5% within 5 weeks of launch and 8% overall. The increase in conversion should be upwards of 3% as measured after 10 weeks of launch.
Target audience: Your data analytics and marketing teams should appreciate you for this. This section nudges you to have a roll-out plan and GTM that will help you achieve the numbers. However, this is also a section that asks you if you’re not confident of meeting the success metrics, is it worth the effort?
4. DEPENDS ON — What is this feature/fix/change request depending on? Which other modules, third parties, features, channels, version, upgrade, roll-out are involved. Is the dependency one way or two way? This is the section that you most easily miss out on. The primary reason is that it’s hard to gauge all dependencies of the feature/change via the limited exposure the PM may have. But you might need the developers, tech architects, and QA to find some dependencies for you. That needs a low ego and a high patience level. So go the extra mile, identify all dependencies, and list them down. Add specifications around what change is expected or what’s possibly disruptive — it should act as a nudge for your QA team to test out the relevant dependencies.
E.g. This report presents data that depends on enabling the XYZ property which is disabled by default.
E.g. Changing the format of the API may impact the way data is stored in the warehouse for billing at a later point.
Target audience: QA and developers mostly, but in many cases, it will help customer success teams prepare themselves better for the new rollout.
5. BEING THOROUGH — Finally the section you’ve been itching for. Where is the solution you’d wonder? Here it goes. So, this is usually what PMs won’t miss except this is also where a lot slips through the cracks. Make sure you are thorough. You should assume that building the feature and testing it is going to be only as good as the PRD you write. Even if that’s not true, assuming it is true kinda helps. Here are some examples of how obvious stuff gets missed.
E.g. Should the filter be checked when you come to edit it?
E.g. What is the sender, subject, and signature of the email that needs to be sent on user’s action? Should it go immediately after an action, or after a cool off time, or as a summary at the end of the day?
E.g. What should the error message exactly say? How does it guide the user to take appropriate action if this error occurs?
E.g. The non-functional specs — performance, security, usability.
Target audience: Developers mostly — try your fiction writing skills to make sure they read it. Will also be referred by the QA teams and every other team who wants to try the functionality out all by themselves once it is built.
Parting thoughts
Let’s revise why this checklist is more useful than a template.
- Easy to remember and follow, easy to make jokes around it. If it ain’t easy to make jokes around a process/policy, it is forgotten and hence not followed.
- Forces you to focus on the right things and document them — thereby creating a better, more useful reference for yourself and the team.
- This works on ALL kinds of documentation — big and small, elaborate, and succinct. My rule of thumb — anything more than 4 hours of effort should follow the entire checklist. The smallest spec you can write, while following the entire checklist will be 5–6 lines. I am sure you won’t disagree with writing that much for a spec.
- Helps in the self-review, or review of specs by a peer/senior. Do you have a spec review process?
- It works for keeping most of the stakeholders on the same page. It has elements for everyone. In fact, if you have specific comments for a team: you should mention them clearly, and tag that team.
- It isn’t boring like a template and comes with the flexibility to add your own creativity. All great PMs improvise, always. Like you would have already done with Scrum/Agile, feel free to internalize this and create your own version of it. There are certain tweaks of this mnemonic that you can alternatively use. E.g. Why business success depends on the roll-out plan being through, OR Why business success depends on GTM being thorough, Why business success depends on coffee, etc.
- Here are samples from real documents and tickets we created while creating workinsync.io during the pandemic:
I hope you’d remember this simple checklist. To internalize this better, you can now pick any doc that you recently created and see what checkpoints you followed and what got missed out. Let me know in the comments if this was helpful or if you need more help with using it effectively.
The original, not-so-fun version appears on my blog — UVTimes.
— — — — —
Clap 1, Clap 2 … Clap 50! If you like the post do shower some love.
