Back to the Playbook
Define & DesignDD-06

How to write a PRD

Describe what users must be able to do, explicitly bound scope, and avoid substituting design or architecture for requirements.

Product statusAvailable now

Input3 required inputsResearch and agreed feature direction · Success measures and constraints · Initiative focus and approved Product Brain guidance
SkillsDraft product requirements · Prepare task context · Review an artifact against agreed criteriaProduct Manager + Product Manager Agent
OutcomeConcise PRD: problem and significance, users and approach, P0/P1/P2 requirements, boundaries, success and evidence.Artifact: PRD

Owner

Product Manager

Human + Agent

Participants · Agents

DesignerEngineerProduct Manager Agent

Trigger

ManualA known user problem requires shared requirements.

Required context

Customer evidenceResearch and agreed feature directionProduct BrainSuccess measures and constraintsProduct BrainInitiative focus and approved Product Brain guidance

Optional context

ConfluenceAccepted feature briefJiraExisting requirements and epicsCodeCurrent product behaviour

Skills

Draft product requirementsPrepare task contextReview an artifact against agreed criteria

Suggested conversation arc

  1. 1Confirm the problem is understoodCheck that research establishes the user need; if the problem is still speculative, record the discovery gap instead of manufacturing a complete PRD.Skills: Prepare task context
  2. 2Draft observable requirementsCreate a concise PRD with problem, business rationale, use cases, solution direction, P0/P1/P2 behaviour, exclusions, success measures and open questions.Skills: Draft product requirements
  3. 3Review scope and consistencyCheck requirements against the problem and success measures; remove solution-detail leakage and surface contradictions or unsupported scope.Skills: Review an artifact against agreed criteria
  4. 4Confirm the requirements baselineDiscuss remaining trade-offs with the PM and affected functions, then confirm a version as the working baseline without claiming implementation completion.

Output

Concise PRD: problem and significance, users and approach, P0/P1/P2 requirements, boundaries, success and evidence.

Artifacts

Creates: PRD

What good looks like

  • Requirements are observable and distinguish priority from approval.
  • Scope and success measures are explicit without implementation prescription.
  • Unresolved conflicts remain decisions, not silently chosen requirements.

Quality gate

The Product Manager confirms one version as the working baseline with the affected functions.

Destination

ConfluenceJira

Usually next

People and agents work from the same Product Brain. The owner stays accountable. Assigned agents prepare and check. A named person approves at the gate.

Deep dives from the AI PM Lab

Articles that explain the thinking behind this Activity.

Choose the path that matches your role.

Set the Product AI direction with us, or test the shared Product Brain on real work with Jira and code.