Step Two: Identify Stakeholders | Who Needs to Be in Your PRD Process

How to Write PRDs for Product Managers

Why this module matters

The Role of PRDs in Product Development

Common Misconceptions

Why this module matters

Standard PRD Components

Writing a Strong Problem Statement

Defining Goals and Success Metrics

User-Centric Thinking in a PRD

Why this module matters

Functional Requirements

Non-Functional Requirements

Writing Good Requirements

Acceptance Criteria

Why this module matters

Clarity Over Complexity

Outcome-Focused, Not Output-Focused

User-Centric Thinking

Testability and Clear Success Criteria

Iterative and Collaborative Approach

Why this module matters

Step One: Define the Problem Clearly

Step Two: Identify Stakeholders

Step Three: Gather Requirements

Step Four: Draft the PRD

Step Five: Collaborate and Review

Step Six: Finalise and Share

Why this module matters

How to Use These Exercises

Exercise One: Simple Feature PRD

Exercise Two: Complex Feature PRD

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.