Skip to content

v1.5.0 — Outcome-Centric PRD Rewrite

Choose a tag to compare

View all tags
@marfoerst marfoerst released this 09 Jun 08:35
· 9 commits to main since this release
v1.5.0
9172f87

Outcome-Centric PRD Rewrite

pm-prd is reframed from an engineering-handoff spec into a customer- and outcome-centric requirements document. The PRD now defines the problem, the customer, and the desired outcome — then stops at the boundary of how. The PM owns the what and why; engineering and design own the how.

What changed in pm-prd

  • New governing principle + "The Line We Don't Cross" — explicit ownership table (PM owns outcome/capabilities/metrics; team owns architecture, APIs, retries, tools, UI) plus a "write capabilities, not implementations" examples table.
  • Reordered spine so the outcome leads — Problem & Desired Outcome (Customer + Business Outcome) → Outcome Hypothesis → Success Metrics → solution detail.
  • New Outcome Hypothesis — frames the solution as a bet ("we believe… we'll know we're wrong if…").
  • Success Metrics moved above the solution + Decision Rules — every metric carries a scale/iterate/stop rule.
  • "Solution / Functional Requirements" → "Capabilities the Customer Needs" — capabilities as "the customer must be able to…", with a customer-observable "Done when" column and a "Serves outcome" traceability column.
  • "Non-Functional Requirements" → "Quality Expectations & Guardrails" — quality as the customer feels it (engineering sets thresholds); no prescribed P95/P99 or named tools.
  • Explicit Outcome Review milestone — launch ≠ success.
  • New quality checks — "no technical prescription" and "output → outcome traceability".

Full changelog: see CHANGELOG.md

🤖 Generated with Claude Code

Assets 2
Loading