So when it comes to the PRD templates, people try solving world hunger with it. In fact, that is also what general people try to solve with their products - and that's precisely why a PM is *required* - to find the method in the madness.
PRD is a Product too
Oh! How did you miss this?
Your first Product is you, Mr. Product Manager (or your resume). And the second one is what you are hired to manage and the third one is your PRD.
If you aren't dealing with the PRD like a Product you are definitely either ignoring it or overdoing it. In either case, it's a major loss in your personal efficacy and the org is definitely suffering from communication gaps, expectation mismatch, team battles between tech and non-tech stakeholders.
So a simple and obvious solution is to create a comprehensive PRD that has everything any stakeholder would ever need. Besides, that's not a solution. It's just that same, how you don't add everything that the users asks for to the product.
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 detail but still be flexible to incorporate comments from various stakeholders.
Moreover,
It needs to be maintainable.
It needs to be usable.
It needs to be unambiguous.
When I was new to product management, in the pre-PM-euphoria days, I couldn't find a good PRD template. So I created my own. When I found that it works really well, I put the "Sample Mobile Apps PRD" format on slideshare back in 2012 and it is still being viewed/downloaded by about 10 people every day since last 8 years. That's over 42k people from over 50 countries. This was more from my Business Analyst days, and 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.
That's not how most documents get created anyway. If you are in anyway similar to orgs that I have worked with - a lot of documentation happens on a task/ticket management software like Jira. A lot of documents start as a list of items on spreadsheets (asks, feature ideas, whiteboard screenshots) and then more keeps getting added to it as discussions happen. So, if one ever gets to write a proper PRD, it's more likely for your own job satisfaction. Btw, IMHO that's not a bad reason to be writing PRDs. Most PRDs end up being short lived, unread and futile.
And it's not just me, or my org. People around the world think PRDs must die.
So why are we looking to templatise futility?
If you look at various PRD formats from best product companies across the world now so easily available on the internet - you'd realise that not much has changed from what I created 8 years back. Everyone wants to keep the key elements like the Problem, the Solution, the Scope (in-scope, out-of-scope), the Success Metrics, and the Dependencies. Some also like to include the 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.
Well we need a way to ensure we don't forget something important. The right word for such a thing is a checklist.
Checklists v/s Templates
With templates comes the fear/lethargy of maintaining the status quo. If every document is different – it should look different and focus on solving the problem instead of maintaining the so-called standard format. Templates are one of the last remnants of the industrial revolution era factory system. Auditors and Managers wanted one to stick to their ‘prescribed’ formats because it was easy for ‘them’ to monitor and review. But, that’s not what modern docs are for. They are used across various stakeholders - and every one tries to get what they need from it - sales guys are interested in dates, customer success want to know how it works, devs want to know what needs to be built, QA wants to know what they have to test. What we need is checklists and not templates.
So, we've talked about PRD being a product, and that in most cases they are mishandled and so they've not being very effective.
But, where is the world's simplest PRD template?
The 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 document or Jira ticket.
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 tickets and largest of Epic documents that you create.
This covers most essential elements of the PRD. Here's what each of the check means:
1. WHY - Start with a why. It makes sense to start every ticket, every doc by answering this question however briefly it may be. 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, we ensure that we have given enough context and described to the reader why we are doing this at all. The way I like to do it is describe something very briefly and then provide larger context - just the way I have done it in this blog post.
E.g. Engagement of the app is low. User's are not able to discover the feature X on their own. Expected engagement for such apps is nX/user/week.
Target: Even though I dread the term 'everyone' - this section is actually meant for all stakeholders. More than anyone this section is for you. 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 customer success team, marketing team understand it well.
2. BUSINESS - 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. Order of this (or any other) section is not important. So here's where you discuss/define the current state and what 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 super critical. The real difference between 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 - gut feel doesn't work. If PRD has a section on business feasibility, impact this checkpoint is clear.
E.g. Higher engagement would lead to increase in DAU/MAU ratio which proportionately increase our chance to covert from free to paid version. Higher engagement is critical for increasing conversion.
Target: This would appeal the most to 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 15% within 5 weeks of launch. The increase in revenue should be upwards of 3% as measured after 10 weeks of launch.
Target: Your data analytics and marketing teams should appreciate you for this. This section also nudges you to ensure 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. 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 your 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: QA and developers mostly, but in many cases it will help customer success teams prepare themselves better for the new roll out.
5. BEING THOROUGH - Finally the section you've been itching for. Where is the solution you'd ask? 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 helps.
E.g. Should the filter be checked when you come to edit it?
E.g. Who's the sender, subject and signature of the email that needs to be sent.
E.g. What should the error message exactly say? How does it guide the user to take appropriate action is this error occurs.
Target: Developers mostly - Try your fiction writing skills to make sure they read it. QA teams and every other team who wants to try the functionality out all by themselves would like it too.
Parting thoughts
Let's revise why this is more useful than a template.
- Easy to remember and follow, easy to make jokes around. 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 docs - 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.
- Works for self-review, or review of specs by a peer/senior. Do you have a spec review process?
- Works for keeping most stakeholders on the same page. It has elements for everyone. In fact if you have specific comments for a team: you should mention that clearly.
- It isn't boring like a template and comes with the flexibility to add your own creativity. All great PMs always improvise. 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, etc.
----------
Leave a comment for the author. It makes his day.
