product-prd

name	product-prd
description	Write or critique a lean product brief, PRD, or PR/FAQ that frames the customer, outcome, evidence, risks, constraints, measures, and open decisions before implementation detail. Use when requirements are solution-heavy, scope is unclear, or a team needs an executable product definition.

Product PRD

Create the smallest product definition that aligns a cross-functional team and exposes unresolved decisions. Do not use document length as a proxy for rigor.

Choose the artifact

• Use a one-page product brief for early discovery or a reversible bet.
• Use a PR/FAQ when customer value and narrative clarity are the main uncertainty.
• Use a lean PRD when engineering, design, analytics, operations, or policy need durable shared constraints and acceptance signals.

Workflow

1. Name the decision owner, target customer, triggering situation, and desired outcome.
2. Summarize problem evidence and current alternatives.
3. Explain the value mechanism and strategic fit.
4. State assumptions and assess value, usability, feasibility, and viability risks.
5. Define in-scope behavior, constraints, and explicit non-goals without prematurely specifying every interaction.
6. Describe the end-to-end customer journey, including failure, recovery, support, and exit paths.
7. Define success, guardrail, instrumentation, rollout, and decision thresholds.
8. Capture dependencies, unresolved questions, and owner for each.
9. Add a decision log and change policy so later learning is traceable.

Output contract

Return:

• Summary and decision
• Customer, situation, problem, and evidence
• Outcome and strategic rationale
• Proposed approach and alternatives
• Scope, non-goals, and constraints
• Four-risk assessment
• Journey and failure handling
• Metrics, instrumentation, rollout, dependencies, and open decisions

Quality gate

• Evidence and assumptions are visibly different.
• The artifact explains why before what.
• Non-goals constrain scope.
• Acceptance is behavioral and measurable where possible.
• Failure and operational paths are included.
• Unknowns have owners and resolution dates.

Avoid

• A giant feature specification before discovery
• Requirements without a target outcome
• “User-friendly,” “fast,” or “accurate” without thresholds
• Hiding disagreements in vague prose
• Treating document approval as product validation

Source grounding

Operational synthesis informed by product discovery, four-risk, and prototype principles in Inspired, outcome orientation in Escaping the Build Trap, and strategy coherence in Good Strategy/Bad Strategy. PR/FAQ use is framework-informed rather than a faithful distillation of Working Backwards.