PRD Framework
A decision-oriented product requirements structure connecting problem evidence, outcomes, users, scope, workflow, requirements, analytics, risk, rollout, and open decisions.
Use it when: A cross-functional team needs shared product intent.
Primary output: PRD
Core principle: Frameworks support judgment; they do not replace evidence or accountability.
Why it exists
The problem it solves
PRDs become large specifications that document features without clarifying the problem, decisions, trade-offs, success measures, or operational readiness.
Ownership and attribution
Adapted synthesis
Synthesized and adapted from established product practices for enterprise and AI application.
Use guidance
When to use it
- A cross-functional team needs shared product intent.
- The workflow, scope, dependencies, or risks are complex.
- A release requires measurable acceptance and readiness criteria.
- An AI capability needs evaluation and oversight requirements.
Context matters
When not to use it
- A tiny reversible change can be explained clearly in a short story.
- The problem and outcome have not been discovered.
- The document will not be maintained or used for decisions.
Method
Inputs and process
The framework is designed to produce decisions and learning, not simply artifacts.
- 01
Executive summary
State the problem, user, outcome, approach, and decision required.
- 02
Problem and evidence
Document the workflow problem and evidence that it matters.
- 03
Users and jobs
Clarify actors, context, needs, responsibilities, and permissions.
- 04
Scope
Define included, excluded, deferred, and dependent work.
- 05
Experience and requirements
Describe workflow, behavior, functional and non-functional requirements.
- 06
Measurement
Define events, success metrics, guardrails, and evaluation.
- 07
Risk and readiness
Cover dependencies, assumptions, rollout, support, monitoring, and open decisions.
- 08
Acceptance
Define testable criteria for intended behavior and release readiness.
Decision quality
Key decision points
Is the problem sufficiently clear?
What is intentionally out of scope?
Which requirement protects the core outcome?
How will success and failure be observed?
What must be true before release?
Outputs
What it produces
- PRD
- Workflow model
- Requirements and acceptance criteria
- Analytics plan
- Risk and dependency register
- Rollout and readiness plan
Success
How it is measured
- Requirement clarity
- Decision resolution time
- Scope stability
- Defect escape
- Release readiness
- Outcome instrumentation
Skills
What it demonstrates
Portfolio application
How I apply it
I use PRDs to translate product opportunities into shared decisions, executable stories, acceptance criteria, evaluation needs, and release-readiness expectations.
Common pitfalls
How the framework is misused
- Documenting a solution before validating the problem.
- Mixing requirements with implementation instructions.
- Omitting exclusions and open decisions.
- Writing untestable acceptance criteria.
- Ignoring analytics and operations.
Interview preparation
Discussion prompts
- What makes a good PRD?
- How much detail is enough?
- How do you handle unresolved decisions?
- What changes in an AI PRD?
References
Attribution and sources
This framework is presented as an original or adapted portfolio model. Any future external influences will be documented here.