The Lifecycle of a PRD

You don’t write your PRD once. You write it over time.

If the purpose of a PRD is clarity, then it’s important for it to reflect the current state of the team’s thinking.

Here’s the 6 stages of evolution I recommend:

1 — Team Kickoff

Often called a speclet, at this stage the idea is ‘just enough information’ for the team to explore it further. It might even be just a title and a few lines.

The idea is: you’ve identified business metrics to move, and you have 80%+ confidence of the user problem direction you’ll solve. You don’t know the exact problem or solution, but you’re describing your best hunch.

It’s an exercise in product sense. Then, with your designer and tech lead, you’ll explore further.

2 — Planning Review

This is when the PRD expands into a 1-pager. You’ve started to explore the problem space with your design and engineering partners.

It’s now ready for review with execs — your skip level, those VPs that care a lot about the roadmap, maybe even the CEO.

This new document ends planning reflecting the summary of your learning during the process.

3 — XFN Kick Off

Once you’re ready to take on the solution space, it’s time to bring all the stakeholders in: sales, customer support, marketing…

This is where you update the PRD for all of the input needed. What you need from legal, from privacy, from compliance, from QA, and everyone else.

It has a compelling problem space, initial data, and serves as a canvas to get input before going full on in the solution exploration.

4 — Solution Review

The next step for the PRD is generally the most stressful product review. This is the one, if it’s a big feature, you might even present to the Senior Leadership Team (SLT).

Many times, this will even evolve into a slide deck, or a Notion document that’s ready for presentation, or a 6-page PRFAQ if you work at Amazon.

The idea is, you put your stake in the ground on the results of the solution space exploration so you can get feedback.

5 — Launch Readiness

Once you’ve gotten all that feedback and completed your exploration of the solution space, it’s time to get the document ready for engineering.

Your tech lead has been in on the whole process, but now you need to create a concrete document of edge cases, metrics, and flows.

Then, the engineers building it can stress the final edge cases only an engineer can find.

6 — Impact Review

Many people make the mistake of ending the PRD there. But it’s worth going back to the PRD and adding a link to your feature results writeup.

And, if you roll back the feature or something, adding a note of it.

You want people who find the PRD to be able to trace back what happened after to complete the build-test-learn loop.

Ready to go further on writing a great PRD? Check out the full deep dive.