How to Write PRDs for Product Managers
Lesson 3
Step Two: Identify Stakeholders
A PRD does not live in isolation. It is produced for people, reviewed by people, and acted on by people who each bring a different perspective and a different set of concerns. Identifying those people before you write is what ensures the document serves all of them rather than surprising some of them.
Stakeholders in a PRD process fall into three categories.
- Decision-makers: the people who need to approve the direction before development begins. This typically includes product leadership, engineering leadership, and depending on the initiative, legal, finance, or compliance. Knowing who holds approval authority prevents late-stage surprises that send you back to the beginning.
- Contributors: the people whose expertise must shape the PRD before it is finalised. Engineers who can assess technical feasibility. Designers who can flag user experience implications. Data analysts who can confirm metric trackability. Customer success teams who can represent the user perspective at scale.
- Informed parties: the people who need visibility into the initiative without being directly involved in shaping it. Sales, marketing, customer support, and sometimes external partners who need to prepare for what is being built.
What this step requires you to do:
- Map every stakeholder against these three categories for this specific initiative
- Identify who needs to be consulted before you write, not just after
- Confirm who holds final approval and what their specific concerns are likely to be
- Note any stakeholders whose absence from the process is likely to create problems during review
A PRD that surprises a key stakeholder during review is a PRD that was not ready to be written yet. This step is what prevents that.