How to Write PRDs for Product Managers
Lesson 7
Step Six: Finalise and Share
The PRD is finalised when it has incorporated review feedback, resolved the open questions that were within scope, and received sign-off from the decision-makers identified in Step Two. Finalised does not mean frozen. It means the document reflects current best understanding and is ready to guide development.
What this step requires you to do:
- Update the document status and version. Change the status from In Review to Approved. Update the version number and date. This signals clearly to anyone who opens the document that they are reading the current, authorised version.
- Share with all three stakeholder categories. Decision-makers who approved it. Contributors who shaped it. Informed parties who need visibility. Do not assume that approval equals awareness. Share deliberately.
- Brief the team, do not just send the link. A PRD shared via a Slack message with no context is a PRD that most people will not read until they need to. Walk key team members through the document. Highlight the decisions that matter most. Surface the open questions that remain and confirm the owners and timelines for resolving them.
- Establish the document as the living reference. Make clear to the team that this document will be updated as development produces new information, and that it should be consulted rather than remembered. A PRD that lives in people's heads rather than in the document is a PRD that will be interpreted differently by different people over time.
- Set a review checkpoint. Agree in advance on when the PRD will be reviewed again during development, typically at a natural milestone, to capture any changes that have occurred and ensure the document still reflects what is being built.
The PRD is not done when it is shared. It is done when development is done, the metrics have been measured, and the learning has been captured for the next initiative.