Ditch the PRD template and embrace the PRD checklist

Aakash Gupta, author of the Product Growth Newsletter, shares tips for using checklist-based PRDs to streamline the product management process and enhance team efficiency.

August 13, 2024

8 min read

Share on

Aakash Gupta

Aakash Gupta is the author of the Product Growth Newsletter. A former VP of Product who spent 15 years in product management, Aakash has led the Product Growth function at companies like Apollo.io, thredUP, and Affirm.

The typical solution is the PRD template

The average company tries to keep all the various parties happy by coming together to create a PRD template.

It’s usually an earnest effort by some VP of Product. They’ve heard the complaints. As a result, they want to help both their teams and their cross-functional stakeholders.

They create a draft, they get it OK’d with their teams, and then they socialize it with cross-functional parties.

Each team slightly tweaks the template. Most? They add a few requirements and sections.

Analytics: “you need all the telemetry pre-specified, as well as point estimates for north-star and guardrails”
User research: “we must include the minimum required research plan - and no feature can go without talking to customers!”
Product marketing: “we mustn’t forget the GTM! We have to include what is needed from PMM”

And it continues on this way as each department hears of the template and adds on.

The result is template hell

Talk to your average product manager about writing PRDs — and why they haven’t written one for that next feature coming up yet — and you’ll hear the same set of refrains.

They mostly go like this:

I just haven’t gotten a good 2 hour time-block to write it yet. I wanted to write it last night after work, but I was just exhausted.

What’s going on here? There are four factors at play:

Your average PRD template has just gotten way too long.
Instead of being one thing that’s really good for a few people (eg, design and engineering), the PRD has become something that’s somewhat good for a lot of people.
The burden has landed on the product manager to deliver a full feature specification when in most models, this should be a team effort.
Product managers, already overworked and overstressed, lack dedicated maker time to put such a hefty document together.

This is not an ideal situation

This situation where PRDs are not being completed is not ideal. Most significantly, product leaders end up left in the dark.

As a VP of product, I regularly felt this pain. Other VPs are asking about features, the CEO is asking about features, and the PRD… it’s missing in action.

But it wasn’t just the leaders who missed the PRDs. The designers, the engineers, the analysts… everyone on the core product team also missed them.

What I realized is that product leaders need to relieve the burden on their teams.

The solution is to embrace multi-stage, evolving PRDs.

This means accepting:

At first, they will be bare bones.
Over time, detail will be added.
And yes, they will eventually be outdated.

To organize multi-stage PRDs, checklists work better than templates

If you’re going to switch to such a system of staged PRDs, templates become pretty outdated.

You end up having a bunch of systems and toggles that you don’t use.

Both as a leader and product manager, I find that checklists work better.

You can just check if your PRD has met all the questions in the checklist at whatever the relevant stage is.

When we implemented this on my teams, the feedback was immediately positive: from both PMs and their cross-functional partners.

The five stages of checklists

So what should your checklists be, and at what stages?

In my experience, five steps work best:

Planning: this allows you to actually have a concrete document in the planning phase for each feature.
Kickoff: this gets the whole team on the same page about the scope of what has been agreed to be funded.
Solution review: this gets IC engineers aligned with what PM, design, and the tech lead have been leading thus far.
Launch readiness: this gives everyone a good set of requirements so all teams are ready for launch.
Impact review: this ensures the PRD is updated for traceability after launch

So what should each checklist look like? This will depend on team and company.

But here’s what’s worked for me:

Planning checklist

Problem: Have you clearly defined the user problem you intend to solve?
Current state: Have you laid out how the problem currently fails to address this problem?
Metrics: Have you made it clear what business metrics you intend to move?
Qualitative evidence: Have you included compelling qualitative reasons to build this?
Next steps: Have you clearly outlined the gaps in your understanding, who will own them, and by when?
Competition: Have you surveyed what the market is doing here?
User insight: Have you identified a user insight, anecdote, or segment that motivates the feature?

Kickoff checklist

Potential solution: Have you added a product mock or description of how the feature could work to solve the problem at hand?
Metrics to measure: Have you clearly outlined the north-star, secondary, and guardrail (counter) metrics to measure success of the feature? Do you know everything you need to?
Impact sizing: Have you done the work to model out how this will move your input (OKR) and output (overall company) metrics? If not, what else do you need to know?

Solution review checklist

Edge cases: Have you gone through all the potential edge cases for the solution you have narrowed on that you know now?
Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when?
XFN requirements: Have you outlined what you need from cross-functional partners in other departments for success of the feature?
Tracking & analytics requirements: Have you specified what telemetry and tracking events eng should put into the feature so you can measure what you need to?
**Go-to-market strategy**: Have you worked out how you will work with go-to-market teams in order to cause this feature to do as best as it can?
Risks and mitigation: Have you thought through the risks for this particular solution and identified the right mitigants?

Launch readiness checklist

Eng-ready: Have you address all of dev’s concerns?
Design complete: Is your Figma or other design file totally complete?
Estimated and tasked: Have you created the individual JIRA tasks and story pointed them so you can share a date for delivery and execute against it?
Go-to-market: Have you done what you need to in order to enable go to-market (sales, marketing, CS) teams?
Make a splash: Are you ready to actually get users to use your feature, vs just making a good one?
Financials: Have you considered costs and would finance OK this?
Hypothesis: Have you clearly highlighted the hypothesized impact on key metrics?
Impact sizing: have you estimated the impact on key metrics?
Corner cases: Have you discovered and addressed all the edge cases?
Test plan: Do you have your plan for QA ready?

Impact review checklist

Blind eye: Is there any reason you would regret rolling out this feature?
Stats sniff test: Does the analysis fail any basic tenets of statistics?
Continuous monitoring: How will you monitor impact on an ongoing basis?
Improvements: Having gone deep into the feature and data, what could you do to improve this feature if you come back to it?

So go checklisting!

I hope that helps you, as a product manager or product leader, create a better solution than PRD templates for your team.

Let’s retire the PRD template. And embrace the checklist.

Aakash will also be speaking at #mtpcon North America this fall! In his talk, Aakash will share actual screenshots of leading PLG products to examine the evolution of the PLG motion, covering everything from problem communication to monetization, activation, and expansion. He'll provide practical tips to enhance your own PLG strategy. Check out the full agenda here.

Further reading: