The PRD Journey: Transforming Ideas into Successful Products

PRD isn’t a document that you write just once. Rather, you write it over time.

It’s important for for a PRD to provide clarity by reflecting the current state of the team’s thinking.

Here are the 6 stages of evolution I suggest:

Check out the deep dive to understand this with more examples and specifics.

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 have identified business metrics to move, and you have 85%+ confidence of the user problem direction you’ll solve. You don’t know the exact problem or solution, but you’re describing your best guess.

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-page doc. You’ve started to explore the problem space with your design and engineering teammates.

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, showcasing the summary of your learning during the process.

3 — XFN Kick Off

Once you’re ready to start working on the solution space, it’s time to bring all the stakeholders in: sales, customer support, product 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 to get feedback by putting your stake in the ground on the results of the solution space exploration.

5 — Launch Readiness

Once you’ve received all that feedback and completed your exploration of the solution space, it’s finally 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 that only engineers 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 take any other action, adding a note of it in the PRD.

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