Skip to content

Step 7 - Product Requirements Doc (PRD)

Purpose

Translate an approved business Outcome into a clear, business-facing set of requirements.

This step exists to define what the business needs to be true for an Outcome to be considered successful, without introducing solutions, technical design, or implementation detail.

When To Run This Step

This step is executed by a person after an approved Project Initiative Package (PIP) exists.

Run this step when:

  • Stage 2 has produced an approved PIP
  • One or more Outcomes in the PIP have been approved to proceed
  • Business requirements need to be defined before design or delivery work begins

This step must not run if:

  • A PIP does not exist
  • The Outcome has not been approved
  • The team is attempting to design solutions or implementation details

Inputs (Required)

  • An approved Project Initiative Package (PIP)
  • A single approved Outcome selected from the PIP

Prompt to Run

  • Prompt Name: Product Requirements Document (PRD) Generator
  • Prompt Version: v1.0
  • Prompt Location: PRD Generator

Instruction: Run the PRD prompt using the PIP as input and explicitly select which approved Outcome is being expanded.

Focus strictly on business requirements. Do not introduce solutions, system design, or technical detail.

Outputs (Produced)

The step produces a Product Requirements Document (PRD) containing:

  • Outcome reference and problem context
  • Business objectives
  • Detailed business requirements
  • Refined business workflow
  • Roles and permissions
  • Business constraints and policies
  • Assumptions
  • Business-facing acceptance criteria
  • Open business questions

The output must strictly follow the PRD template.

Artifact Storage

Store the PRD in the predefined system of record selected during setup.

  • One PRD per approved Outcome
  • One primary storage location only
  • The artifact must be referenceable
  • Ownership must be clear

Validation Rules

The PRD is valid only if:

  • It describes what the business needs, not how it will be built
  • All requirements are business-facing and testable
  • Workflows reflect real business operations
  • Constraints are business constraints, not technical ones
  • Acceptance criteria are written in business language
  • Missing information is explicitly marked as TBD

The PRD is invalid if it:

  • Introduces technical design or implementation detail
  • Proposes solutions or architectures
  • Reframes or alters the approved Outcome
  • Includes system-specific steps or assumptions

Invalid PRDs must be corrected before proceeding.

Decision Gate

Question: Is the business Outcome fully and unambiguously defined in business terms?

Outcomes:

  • Yes: Proceed with Strategic Domain Design using the PRD
  • No: Gather missing business information and revise the PRD

No other outcomes are allowed.

Failure Modes & Anti-Patterns

  • Treating the PRD as a technical specification
  • Allowing solution ideas to leak into requirements
  • Writing vague or non-testable requirements
  • Describing system steps instead of business workflows
  • Skipping acceptance criteria or assumptions

If this step is polluted with implementation thinking, downstream design will be constrained or invalid.

Traceability

  • Previous: Stage 2 — Project Initiative Package (PIP)
  • Next: Stage 3 — Strategic Domain Design
  • Consumes: Project Initiative Package (PIP)
  • Produces: Product Requirements Document (PRD)

Status

  • Maturity: Stable
  • Enforced by Tooling: Planned