PRD from Vision

---
name: prd-from-vision
description: Use when turning a founder vision into a PRD a team can build from. Triggers on "PRD", "product spec", "build a PRD", "turn this into a spec".
---

# PRD from Vision

Founder vision documents are usually too abstract to build from. The job of this PRD is to force specificity — who's the user, what's the problem, what's the smallest version that proves the thesis, what's NOT in scope. If the founder can't articulate these, the team will build the wrong thing.

## Required inputs

1. **The vision** — verbatim from the founder, including hand-waviness
2. **Who the user is** — segment, role, current behavior
3. **Why now** — what's changed in the world, or in the customer
4. **Constraints** — time, eng capacity, dependencies on other systems
5. **What success looks like** — the metric or behavior change you'd measure

If 2-5 are missing, ask. Specifically push back on:
- "Users will love this" — which users? what evidence?
- "It will be like X but for Y" — what's the actual job?
- "We'll figure out the metric later" — no, define the metric or don't build

## Structure

```
# PRD: [Feature / product name]

## Problem
- Who specifically (segment + role)
- What they're doing today (the current workaround / tool / behavior)
- Why it's painful — quantified if possible
- Why now — what's changed

## Hypothesis
1-2 sentences: if we build X, then Y will happen, because Z.

## Users (specific)
- Primary: [segment, role, frequency of use]
- Secondary: [who else interacts with this]
- Anti-user: who this is explicitly NOT for

## Solution (high level)
- What does the user experience?
- Walk through the core flow in 5-7 steps
- A sketch beats prose if helpful

## MVP scope
The smallest version that tests the hypothesis.
- 3-5 things in scope
- For each: 1-paragraph description, acceptance criteria

## Out of scope (explicit)
- 3-5 things NOT in this version
- For each: brief reason (premature, dependent, not testing the hypothesis)

## Success metrics
- **Primary metric** — the one that matters
- **Target** — what would make this a success
- **Counter-metric** — what we'd watch to make sure we're not making something else worse
- **Time horizon** — when do we measure

## Open questions
3-5 things still unresolved. Tag with owner.

## Risks
- Technical risks (one paragraph)
- Adoption risks (one paragraph)
- "What if we're wrong" — the cheapest way to find out

## Roll-out plan
- Internal first / closed beta / GA — which makes sense
- Feature flag / cohort / full launch
- What we'll learn at each stage
```

## Pushback patterns

When the founder hand-waves, ask:

- **Vague user**: "Founders" / "operators" / "everyone" → "Which specific role at which type of company?"
- **Vague pain**: "Save time" → "How much time? What are they doing now? How often?"
- **Vague metric**: "Engagement" → "Which specific user action, measured how, over what window?"
- **Vague scope**: "It will eventually do A, B, C, D, E" → "What's the SMALLEST version that proves the core thesis?"
- **Solution-as-feature-list**: "We'll have an AI agent, a dashboard, a mobile app, integrations" → "Which of these are required for MVP and which are aspirational?"

## Anti-patterns

- Long PRD without a clear hypothesis — you're decorating, not deciding
- Roadmap pasted as scope — scope is for one cycle, not a year
- Missing "out of scope" — without it, scope creep is guaranteed
- Vague success metric ("user delight") — if you can't measure it, you can't learn
- No counter-metric — building things that win on one axis but break others

## Tone

- Direct. Push back on vagueness in writing — the PRD is the artifact that catches imprecision.
- Specific. Every requirement has acceptance criteria or it's not a requirement.
- Honest about uncertainty. "We don't know if X" is more useful than fake confidence.

## Output format

Markdown. Length: 2-4 pages. Longer means scope creep snuck in. End with the open questions section so the next conversation has clear inputs.