Skip to main content

Intent-Driven PRD Development

A Practitioner's Guide to Preserving User Intent in AI-Assisted Development

Document Type: Educational Reference
Audience: Product Managers, Technical Leads, AI-Assisted Development Teams
Based On: Empirical research - 9 identical applications built with varying PRD approaches


Executive Teaching Summary

This guide addresses a critical but overlooked problem in AI-assisted development: the silent loss of user intent at each stage of the development pipeline. Empirical testing reveals that up to 55% of original requirements are lost before reaching the final build—not due to unclear specifications, but due to systemic filtering at each handoff.

The Core Insight

Model intelligence does not determine build quality. Intent survival does.

The choice between a $0.01 AI model and a $1.00 AI model for PRD generation produces statistically indistinguishable results. However, the choice to verify intent preservation at each stage produces a 12-point quality improvement.


Part 1: The Problem

1.1 The Intent Loss Pipeline

Every AI-assisted development workflow contains multiple "handoff" points where information transfers from one stage to the next. At each handoff, intent is filtered, summarized, or dropped entirely.

┌─────────────────────────────────────────────────────────────────────────┐
│ THE INTENT LOSS PIPELINE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ STAGE 1 STAGE 2 STAGE 3 STAGE 4 │
│ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │ USER │──────▶│ PRD │──────▶│ PLAN │──────▶│ BUILD │ │
│ │INTENT │ │ │ │ │ │ │ │
│ └───────┘ └───────┘ └───────┘ └───────┘ │
│ 100% ↓ 80% ↓ 56% ↓ 45% │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ LOSS #1 LOSS #2 LOSS #3 │
│ ~20% ~30% ~20% │
│ │
│ "The why gets "Planning modes "Execution focuses │
│ scrubbed away" filter silently" on what's explicit" │
│ │
└─────────────────────────────────────────────────────────────────────────┘

1.2 Types of Intent Loss

Loss TypeStageCauseExample
Nuance StrippingIntent → PRDAI summarizes feeling into features"Delightful experience" → "UI displays results"
Context CollapseIntent → PRDBackground rationale omittedWhy a feature matters disappears
Silent FilteringPRD → PlanPlanning mode "normalizes" inputs20-30% of requirements dropped
Ambiguity AvoidancePlan → BuildBuilder skips unclear itemsEdge cases never implemented
Scope CompressionAll stagesEach stage favors "core" featuresNice-to-haves systematically eliminated

1.3 Why This Matters

In regulated industries (healthcare, fintech, aerospace), lost requirements create:

  • Compliance gaps — Audit trails, signatures, or controls never implemented
  • Safety risks — Critical warnings or validations missing
  • Rework costs — Features rebuilt after compliance review
  • Trust erosion — Stakeholders lose confidence in autonomous development

Part 2: The Experiment

2.1 Methodology

Objective: Test whether AI model intelligence correlates with build quality

Application: Dictionary/etymology lookup tool with:

  • Hot-key activation
  • Misspelling detection with learning hints
  • Multiple interpretations (Apple = fruit or company)
  • Word relationships and exploration

Variables:

  • Controlled: Build system (Claude Code + Opus 4.5 planning mode)
  • Varied: PRD-generating model (8 models tested)

2.2 Models Tested

ModelCategoryPRD Generation TimeCost Tier
GPT-5.2 InstantSpeed-optimized~15 seconds$
GPT-5.2 FastStandard~30 seconds$
GPT-5.2 ThinkingReasoning~2 minutes$$
GPT-5.2 ProPremium~15 minutes$$$$
Claude Opus 4.5Premium~3 minutes$$$
Claude SonnetMid-tier~1 minute$$
Direct to PlanningNo PRDN/A
Direct to ExecutionNo PRD, no planN/A

2.3 Results Summary

Expected Outcome:

GPT-5.2 Pro >> GPT-5.2 Thinking >> Standard models >> GPT-5.2 Instant

Actual Outcome:

All models scored within noise margin (mid-80s)
GPT-5.2 Instant OUTSCORED GPT-5.2 Pro
Direct execution produced one of the best-looking outputs

2.4 Key Observation

"I'm looking at these nine builds and I can't tell you clearly which one came from Pro and which one came from Instant."

The planning mode acted as an equalizing filter, normalizing all inputs to similar quality levels—but also dropping requirements from all inputs equally.


Part 3: The Discovery

3.1 The Planning Filter Effect

AI planning modes are designed to:

  • Organize scattered requirements
  • Identify dependencies
  • Create implementation sequences
  • Estimate complexity

Unintended consequence: They also filter out:

  • Features deemed "non-essential"
  • Requirements lacking explicit acceptance criteria
  • Capabilities that don't fit standard patterns
  • The "why" behind features (rationale)

3.2 Measured Loss Rates

Planning PassRequirements CapturedItems Missing
Pass 170-80%18 items
Pass 2 (with fallout list)85-92%8 items
Pass 3 (with fallout list)95%+Only ambiguous items

Critical Finding: Without verification, planning consistently drops 20-30% of requirements.

3.3 The Intent Experiment

Hypothesis: If intent preservation—not model intelligence—matters, then explicitly instructing the model to preserve intent should improve outcomes.

Test: Added instructions to PRD generation prompt:

  • "Carry the intent through"
  • "Don't just list features, explain why each one matters"
  • "Preserve the nuance"
  • "The PRD should feel like a conversation, not just a checklist"

Results:

ModelScore WITHOUT intent instructionScore WITH intent instructionDelta
GPT-5.2 ThinkingMid-80sMid-80s0
Opus 4.5Mid-80s99%+12 points

3.4 The 12-Point Gap

The Opus 4.5 PRD with intent instructions:

  • Captured every single mentioned requirement
  • Explained the rationale for each feature
  • Preserved the voice and feeling of the original
  • "Read like I'd written it myself, just organized"

This is not noise. This is signal.


Part 4: The Solution Framework

4.1 The Intent Preservation Protocol

┌─────────────────────────────────────────────────────────────────────────┐
│ INTENT PRESERVATION PROTOCOL │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ STEP 1: INTENT CAPTURE │
│ ──────────────────── │
│ • Record your vision (voice memo, document, conversation) │
│ • Include the WHY for every feature │
│ • Describe the FEELING you're going for │
│ • Specify what success LOOKS LIKE │
│ │
│ STEP 2: INTENT-AWARE PRD GENERATION │
│ ─────────────────────────────────── │
│ • Add explicit instruction: "Carry intent through" │
│ • Request: "Explain why each feature matters" │
│ • Specify: "Preserve nuance, not just features" │
│ • Require: "PRD should feel like conversation, not checklist" │
│ │
│ STEP 3: VERIFIED PLANNING (3-PASS) │
│ ────────────────────────────────── │
│ • Pass 1: Generate initial plan │
│ • Verify: Compare plan against PRD → Generate fallout list │
│ • Pass 2: Update plan with fallout items │
│ • Verify: Compare again → Generate fallout list #2 │
│ • Pass 3: Final refinement │
│ • Accept only when coverage ≥ 95% │
│ │
│ STEP 4: BUILD VERIFICATION │
│ ───────────────────────── │
│ • Compare build against plan │
│ • Compare build against original PRD │
│ • Compare build against original intent document │
│ │
└─────────────────────────────────────────────────────────────────────────┘

4.2 The Fallout List Technique

After each planning pass, execute this verification:

PROMPT TO AI PLANNER:
─────────────────────
"Compare the plan you've written against the original PRD.
Find everything in the PRD that's not in the plan.
Give me a fallout list of missing items.
Then update the plan to include those items."

Expected Results:

IterationMissing ItemsAction
First fallout list15-20 itemsUpdate plan
Second fallout list5-10 itemsUpdate plan
Third fallout list0-3 itemsAccept if items are genuinely ambiguous

4.3 Intent Document Structure

When capturing initial intent, structure your input to survive translation:

┌─────────────────────────────────────────────────────────────────────────┐
│ INTENT DOCUMENT TEMPLATE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. VISION STATEMENT │
│ What is this product at its core? What problem does it solve? │
│ Example: "Spotlight for words—instant access to language depth" │
│ │
│ 2. EXPERIENCE DESCRIPTION │
│ How should it FEEL to use this? What's the emotional outcome? │
│ Example: "Effortless, like having a linguistics expert on call" │
│ │
│ 3. FEATURE LIST WITH RATIONALE │
│ For each feature, explain WHY it matters: │
│ • Feature: Misspelling detection │
│ Why: Help users learn correct spelling, not just fix it │
│ Success: User sees what they typed wrong and remembers │
│ │
│ 4. NON-OBVIOUS REQUIREMENTS │
│ Things that might seem minor but matter: │
│ • Sound effects on lookup (feedback satisfaction) │
│ • Auto-dismiss behavior (workflow integration) │
│ • Word of the day (engagement, discovery) │
│ │
│ 5. ANTI-REQUIREMENTS │
│ What this explicitly IS NOT: │
│ • Not a full dictionary app (quick lookup only) │
│ • Not a learning management system │
│ │
│ 6. SUCCESS CRITERIA │
│ How will you know it's right? │
│ • Lookup feels instant (<200ms) │
│ • Never need to leave current context │
│ • Learn something new about words regularly │
│ │
└─────────────────────────────────────────────────────────────────────────┘

4.4 PRD Generation Prompt

Use this prompt structure when generating PRDs from intent documents:

SYSTEM INSTRUCTION:
───────────────────
You are creating a Product Requirements Document from the user's intent
document. Your job is not just to list features, but to PRESERVE INTENT.

CRITICAL REQUIREMENTS:
• Carry the intent through—explain WHY each feature matters
• Preserve nuance—the feeling and experience, not just functionality
• Write like a conversation, not a checklist
• Include rationale for every requirement
• Capture non-obvious requirements explicitly
• Document anti-requirements (what this is NOT)
• The person reading this PRD should understand the SOUL of the product

OUTPUT FORMAT:
• Each requirement includes: ID, Description, Rationale, Success Criteria
• Group by feature area but maintain narrative flow
• Include an "Intent Summary" at the start of each section
• End with "Intent Verification Checklist"

USER INTENT DOCUMENT:
[Insert intent document here]

Part 5: Common Mistakes

5.1 Mistake: Trusting Single-Pass Planning

Symptom: Accepting the first plan generated without verification

Reality: First-pass planning captures only 70-80% of requirements

Solution: Always run at least 2 verification passes with fallout lists

5.2 Mistake: Investing in Expensive Models for PRD Generation

Symptom: Using GPT-5 Pro or equivalent for PRD generation hoping for better results

Reality: Model intelligence shows no correlation with build quality when planning mode normalizes inputs

Solution: Use cost-effective models for PRD generation; invest saved budget in verification loops

5.3 Mistake: Writing PRDs as Feature Checklists

Symptom: PRD reads as bullet list of features without context

Reality: Checklist PRDs lose the "why" that helps AI make correct trade-off decisions

Solution: Structure PRDs as narratives with rationale for each requirement

5.4 Mistake: Assuming Clear Requirements Survive Translation

Symptom: Believing that because something is clearly stated, it will be implemented

Reality: Even crystal-clear requirements are dropped in planning (20-30% loss rate)

Solution: Verify at every stage; never assume survival

5.5 Mistake: Focusing on What Instead of Why

Symptom: Specifying features without explaining their purpose

Reality: Without "why," AI cannot make intelligent decisions when facing ambiguity

Solution: Every feature needs rationale: "We need X because Y, and success looks like Z"


Part 6: Quick Reference

6.1 The Numbers to Remember

MetricValueImplication
Planning loss rate20-30%Expect to lose 1/4 of requirements without verification
Recovery per pass~50%Each verification pass recovers half of remaining losses
Passes needed3Three passes typically achieve 95%+ coverage
Intent instruction impact+12 pointsExplicit intent preservation instructions dramatically improve capture
Model intelligence impact~0No measurable difference between cheap and expensive models

6.2 The Process Checklist

□ Intent document created with WHY for each feature
□ PRD generation prompt includes intent preservation instructions
□ PRD reviewed for rationale presence (not just features)
□ Planning Pass 1 complete
□ Fallout List 1 generated and reviewed
□ Planning Pass 2 complete
□ Fallout List 2 generated and reviewed
□ Planning Pass 3 complete (if needed)
□ Coverage verified at ≥95%
□ Build compared against original intent document

6.3 Red Flags in PRD Review

Your PRD likely has intent loss if:

Red FlagWhat It Means
No "because" statementsRationale stripped out
All requirements look similar lengthNuance compressed
Missing experience/feeling descriptionsSoul of product lost
No anti-requirements sectionBoundaries undefined
Acceptance criteria are genericSuccess undefined
Features listed without contextWhy unknown to implementer

6.4 The One-Sentence Summary

"Your intent is the actual you in all of this. The gap between your best idea and what gets built is about the silent losses at each handoff."


Part 7: Advanced Techniques

7.1 Intent Survival Metrics

Track these metrics across your development pipeline:

class IntentSurvivalDashboard:
"""
Metrics to track intent preservation through pipeline.
Target: ≥85% total survival rate.
"""

def calculate_survival_rates(self):
return {
"intent_to_prd": self.prd_items / self.intent_items, # Target: 95%
"prd_to_plan": self.plan_items / self.prd_items, # Target: 95%
"plan_to_build": self.build_items / self.plan_items, # Target: 90%
"total_survival": self.build_items / self.intent_items, # Target: 85%
}

def identify_leak_stage(self):
"""Find where most intent is being lost."""
rates = self.calculate_survival_rates()
worst_stage = min(rates, key=rates.get)
return f"Primary intent loss occurring at: {worst_stage}"

7.2 Automated Verification Prompts

Fallout Detection Prompt:

Compare these two documents:
1. SOURCE: [PRD or Intent Document]
2. TARGET: [Plan or Build Specification]

For each item in the SOURCE:
- Mark as ✓ PRESENT if adequately represented in TARGET
- Mark as ✗ MISSING if not found or inadequately represented
- Mark as ? PARTIAL if partially addressed

Output a structured fallout list of all MISSING and PARTIAL items.

Intent Preservation Check Prompt:

Review this PRD for intent preservation quality:

For each requirement, verify:
1. Is there a clear "WHY" explaining the rationale?
2. Is there a success criterion beyond "feature works"?
3. Does it capture the intended user experience?
4. Are edge cases and boundaries specified?

Score: [0-100] with breakdown by category.
Flag any requirements scoring below 70 for revision.

7.3 Team Process Integration

For Product Managers:

  • Create intent documents before PRD generation
  • Review PRDs for rationale presence, not just feature completeness
  • Own the verification loop sign-off

For Technical Leads:

  • Run fallout list generation after each planning pass
  • Block builds that haven't completed 3-pass verification
  • Track intent survival metrics in sprint reviews

For Developers:

  • When in doubt, reference original intent document
  • Flag features that lack rationale in PRD
  • Report "intent unclear" blockers early

Appendix A: Glossary

TermDefinition
Intent DocumentOriginal description of what you want to build and why
Intent PreservationMaintaining the "why" and "feeling" through translation stages
Fallout ListItems present in source document but missing from target
Planning FilterThe normalizing effect of AI planning modes
Silent LossRequirements dropped without notification or error
Verification LoopProcess of comparing output against source and iterating
Coverage RatePercentage of source requirements present in target
3-Pass VerificationStandard process: plan → verify → update → verify → finalize

Appendix B: Prompt Library

B.1 Intent Document Creation

Help me create an intent document for [PRODUCT].

I need to capture:
1. Core vision (what and why)
2. Desired experience (how it should feel)
3. Features with rationale (what and why for each)
4. Non-obvious requirements (things that matter but might be missed)
5. Anti-requirements (what this is NOT)
6. Success criteria (how I'll know it's right)

Start by asking me questions to extract this information.

B.2 PRD Generation with Intent Preservation

Create a PRD from this intent document.

CRITICAL: Preserve intent, not just features.
- Explain WHY each requirement matters
- Capture the experience, not just functionality
- Write as narrative, not checklist
- Include rationale for every item
- Document what this is NOT

[INTENT DOCUMENT]

B.3 Fallout List Generation

Compare these documents and identify gaps:

SOURCE (authoritative):
[PRD TEXT]

TARGET (to verify):
[PLAN TEXT]

For each item in SOURCE, determine if it's:
- ✓ PRESENT: Fully represented in TARGET
- ✗ MISSING: Not found in TARGET
- ? PARTIAL: Inadequately addressed

Output MISSING and PARTIAL items as a numbered fallout list.

B.4 Coverage Verification

Calculate coverage percentage:

SOURCE requirements: [LIST]
TARGET items: [LIST]

For each SOURCE requirement:
1. Find corresponding TARGET item(s)
2. Assess coverage quality (0-100%)
3. Note any gaps

Output:
- Overall coverage percentage
- Per-requirement scores
- Recommendations for items below 80%

Appendix C: Case Study Summary

The 9 Apps Experiment

Setup:

  • 1 application concept (dictionary/etymology tool)
  • 8 different AI models generating PRDs
  • 1 build system (Claude Code + Opus 4.5)
  • Same process for each build

Hypothesis: Smarter model → Better PRD → Better build

Result: No correlation between model intelligence and build quality

Discovery: Planning mode drops 20-30% of requirements regardless of PRD quality

Solution: 3-pass verification with fallout lists recovers 90%+ of lost requirements

Key Quote:

"The gap between your best idea and what gets built isn't about using GPT-5 Pro versus 5.2 instant. It's about the silent losses at each handoff."


Document Version: 1.0
Based on empirical research, January 2026
For use in AI-assisted development training and process design