Prd Builder

PRD Builder

Purpose

Most PRDs fail in the first 30 seconds because the reader can't tell what problem they solve, for whom, and how success will be measured. This skill produces a PRD where those answers are front-loaded and every section pulls weight.

This is for product PRDs (consumer or B2B SaaS framing). For enterprise B2B delivery specs (use cases, FRD, traceability), use a BA-style spec writer instead.

When to use

• Feature ask from leadership ("we should do X") with no underlying spec
• Fuzzy problem from a stakeholder that needs structure before discussion
• Drafting a PRD to circulate for reactions, not a final delivery contract
• Turning your own thinking into a doc others can poke at

When NOT to use

• For detailed engineering specs (architecture, API contracts)
• For one-line tickets in a sprint
• When the problem is unclear and needs discovery first (run deep-market-research or synthetic-user-interview first)

Inputs

Required:

• Problem statement, feature ask, or short description

Optional but strongly improves output:

• Target user / persona
• Current workflow being replaced or augmented
• Business context (strategy, OKRs this serves)
• Known constraints (tech, legal, timeline)
• Adjacent features or systems

If only a one-liner is given, ask three sharp questions before writing:

1. Who hurts today and how do they currently cope?
2. What outcome would tell us this worked?
3. What's the hardest tradeoff you already see?

Do not write the PRD until these have at least rough answers.

Process

Phase 1: Frame the problem

• One-paragraph problem statement in plain language
• Current state: what the user does today, with friction
• Why now: what changed in market, tech, or business to make this worth doing now

Phase 2: Hypothesis

• "We believe that [change] will result in [outcome] for [user/business]"
• Why this hypothesis is non-obvious (if it's obvious, the doc isn't worth writing)
• Counter-hypothesis: what would we expect to see if we're wrong

Phase 3: Solution sketch

• What it is, in 3-5 bullets max
• What it is NOT (boundary clarity)
• Optional: 2-3 alternatives considered and why rejected

Phase 4: Scope

Three explicit lists:

• Must: in scope for v1
• Nice: nice to have, cut if needed
• Out: explicitly not in scope, with one-line reasoning

If "Out" is empty, the scope is undefined.

Phase 5: Success metrics

• North metric: the one number that proves this worked
• Input metrics: what we'd see moving first if it's working
• Guardrail metrics: what should NOT get worse (regressions to watch)
• Each metric with a directional target ("up", "down 20%", "above baseline")

Vague metrics ("improve engagement") are not allowed.

Phase 6: Open questions and assumptions

• 3-7 open questions where the PRD is making assumptions
• For each: what we're assuming, why we're assuming it, what would change if wrong

Phase 7: Risks and tradeoffs

• Top 3 things that could kill this
• Top 3 second-order effects (what changes in adjacent systems)
• Explicit tradeoff: what are we choosing not to optimize

Output

# PRD: [Feature name]

**Author**: [user]  |  **Status**: Draft  |  **Date**: [today]

## TL;DR (3 sentences max)
## Problem
## Hypothesis
## Solution sketch
## Scope: Must / Nice / Out
## Success metrics
## Open questions
## Risks and tradeoffs
## Appendix: discarded alternatives

The TL;DR is non-optional and must work as a standalone summary. If a reader stops after TL;DR, they should still know what's being proposed and why.

Common failure modes to avoid

• Solution before problem: writing the spec before the problem is sharp
• Vague metrics: "improve UX", "drive growth" - useless without numbers
• Empty "Out" section: scope without explicit cuts isn't scope
• Missing open questions: every PRD has assumptions. Hiding them doesn't make them less risky.
• No tradeoff: a PRD that claims pure upside is lying to itself

Recommended companion

Run prd-critic on the output before sharing with eng or exec. The pair catches what either alone misses.