Skip to content

Product Requirements Document (PRD)

Stage: Stage 3 - Strategic Domain Design

Artifact Code: PRD

1. Purpose

The Product Requirements Document (PRD) exists to translate an approved business Outcome into clear, testable business requirements.

It defines what the business needs to be true for an Outcome to be considered complete - without describing solutions, systems, or implementation.

The PRD is the first artifact where meaning is deliberately expanded and made precise.

2. Decision This Artifact Supports

Decision: Is the business meaning of this Outcome fully defined and stable enough to model as a domain?

Possible outcomes:

  • Accept PRD and proceed within Stage 3
  • Revise PRD (requirements unclear or incomplete)
  • Pause (business uncertainty remains)

If business meaning is still ambiguous, the PRD is not complete.

3. Ownership and Roles

  • Owner: Business Analyst / Product Owner
  • Contributors: Domain experts, operational stakeholders
  • Reviewers / Approvers: Business decision-makers responsible for outcome definition

There must be one accountable owner responsible for requirement clarity.

4. Blank Artifact Template

# Product Requirements Document (PRD)

## 1. Outcome Reference
**Outcome Name:** {Name from PIP}
**Initiative:** {Initiative Name}
**Problem Summary:** {Short restatement from PAB}

---

## 2. Business Objective
{1–3 sentences describing what the business needs to accomplish and why.}

---

## 3. Detailed Business Requirements
List the business rules, conditions, and required behaviors.

- {Requirement 1}
- {Requirement 2}
- {Requirement 3}

(No technical details or implementation instructions.)

---

## 4. Business Workflow (Refined)
Describe how the business performs this workflow from start to finish.

1. {Step}
2. {Step}
3. {Step}

---

## 5. Roles & Permissions
List all business roles involved and what they must be able to do.

- **Role:** {Role name}
  **Responsibilities:** {Business actions}

---

## 6. Constraints & Policies
Business rules, timing constraints, compliance requirements, or operational limitations.

- {Constraint 1}
- {Constraint 2}

---

## 7. Assumptions
List any assumptions required for this outcome to function.

- {Assumption 1}
- {Assumption 2}

---

## 8. Acceptance Criteria
Define the business criteria for determining success.

- {Criterion 1}
- {Criterion 2}
- {Criterion 3}

---

## 9. Open Questions
List unresolved business questions.

- {Question 1 or "TBD"}
- {Question 2 or "TBD"}

5. Required Inputs

  • Project Initiative Package (PIP) - approved

The PRD must be derived only from approved Outcomes.

6. Input Acceptance Criteria

Before creating a PRD, verify:

  • The Outcome is explicitly approved in the PIP
  • Scope is locked for this Outcome
  • No design or solution expectations exist yet

If any of these are unclear, return to Stage 2.

7. Assumptions to Surface

Common assumptions at this stage include:

  • Requirements imply implementation
  • One workflow fits all scenarios
  • Roles are already well understood
  • Acceptance criteria are obvious

These must be stated explicitly or challenged.

8. What Must NOT Appear in This Artifact

The PRD must not include:

  • Technical requirements
  • System behaviors or architecture
  • UI descriptions
  • Implementation sequencing

If how appears, the PRD is invalid.

9. Example - Completed Artifact

# Product Requirements Document (PRD)

## 1. Outcome Reference
**Outcome Name:** Customer is identified
**Initiative:** Customer Identification Improvement
**Problem Summary:** Support agents re-enter customer details across multiple systems

---

## 2. Business Objective
Ensure support agents can reliably identify a customer at the start of a support case to reduce handling time and errors.

---

## 3. Detailed Business Requirements

- The business must be able to uniquely identify a customer at case creation
- Customer identification must occur before case resolution
- Identification must be repeatable across support channels

---

## 4. Business Workflow (Refined)

1. Customer initiates support request
2. Agent collects identifying information
3. Customer identity is confirmed

---

## 5. Roles & Permissions

- **Role:** Support Agent
  **Responsibilities:** Collect and confirm customer identity

---

## 6. Constraints & Policies

- Customer identification must comply with privacy regulations
- Identification must occur within standard case intake time

---

## 7. Assumptions

- Customers provide accurate identifying information
- Existing customer records are accessible

---

## 8. Acceptance Criteria

- A support case cannot proceed without confirmed customer identity
- Agents report reduced re-entry of customer information

---

## 9. Open Questions

- What identifiers are considered sufficient for confirmation?

10. Output Quality Checklist

  • [ ] Requirements are business-facing and testable
  • [ ] Workflow reflects real operations
  • [ ] Roles and constraints are explicit
  • [ ] Acceptance criteria are clear
  • [ ] No solution language appears

All items must pass to proceed.

11. Common Failure Modes

  • Writing requirements as features
  • Mixing business rules with system behavior
  • Over-specifying workflows
  • Hiding decisions in assumptions

These indicate solution bleed.

12. Review Questions

Reviewers should ask:

  • Could two business people interpret this differently?
  • Are requirements observable without a system?
  • Is success clearly measurable?
  • Is anything still assumed rather than stated?

If answers vary, revise the PRD.

13. What to Do If the Artifact Is Rejected

If the PRD is rejected:

  • Clarify business rules and scenarios
  • Separate assumptions from requirements
  • Remove implementation hints

Do not proceed until meaning is stable.

14. Readiness Signal - Moving Forward

The PRD is ready when:

  • Business meaning is unambiguous
  • Acceptance criteria are agreed
  • Stakeholders share the same interpretation

Proceed to Business Workflow Spec (BWS) and Domain Parts List (DPL).

15. What Invalidates This Artifact

The PRD must be revisited if:

  • The approved Outcome changes
  • Business policy or regulation changes
  • Acceptance criteria are revised

16. Downstream Dependencies

  • Next Artifacts: BWS, DPL, SDD

Unstable PRDs lead directly to unstable domain models.

Reminder: The PRD defines meaning - not implementation.