Your PRD is Alive: Stop Treating it Like a Fossil

Your PRD is not a one stop document. It’s rather constantly changing.

The purpose of a PRD is clarity. It is important for it to reflect the current state of the team’s thinking.

Here are the recommended 6 stages of evolution of a PRD:

𝗧𝗲𝗮𝗺 𝗞𝗶𝗰𝗸𝗼𝗳𝗳

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.

𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴 𝗥𝗲𝘃𝗶𝗲𝘄

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.

𝗫𝗙𝗡 𝗞𝗶𝗰𝗸 𝗢𝗳𝗳

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.

𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗥𝗲𝘃𝗶𝗲𝘄

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.

Ready to go further with examples and specifics? Check out the deep dive.

𝗟𝗮𝘂𝗻𝗰𝗵 𝗥𝗲𝗮𝗱𝗶𝗻𝗲𝘀𝘀

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.

𝗜𝗺𝗽𝗮𝗰𝘁 𝗥𝗲𝘃𝗶𝗲𝘄

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.