Skip to content

Working Backwards

VisionSpec implements Amazon's Working Backwards methodology as the foundation for specification development. This document explains the approach, why it matters for AI-assisted execution, and how to apply it effectively.

What is Working Backwards?

Working Backwards is a product development methodology pioneered at Amazon. Instead of starting with requirements and hoping they lead to a good customer experience, you start with the end state and work backwards:

  1. Write the Press Release first - Describe the product as if it's already shipped
  2. Challenge it with FAQs - Ask hard questions about scope, feasibility, and gaps
  3. Derive requirements - Only then write detailed requirements grounded in the vision

This inversion ensures that every requirement traces back to a specific customer outcome.

The VisionSpec Flow

The canonical home for this flow is aws-one-way-door (new, hard-to-reverse decisions) and aws-two-way-door (reversible ones). The Press Release is the human-authored founding artifact — not synthesized from anything — because a press release synthesized from research is "working forwards", the exact inversion this methodology exists to prevent:

Press Release (human-authored — write this first)
    │
    │  "How will we announce this to customers?"
    ↓
FAQ (synthesized from Press)
    │
    │  "What questions will stakeholders ask?"
    ↓
MRD or OpportunitySpec (optional deepening, synthesized from Press + FAQ)
    │
    │  "What market/discovery evidence validates the FAQ's business case?"
    ↓
PRD (synthesized from Press + FAQ + MRD/OpportunitySpec)
    │
    │  "What detailed requirements follow from this vision?"
    ↓
Narrative 6P (synthesized from Press + FAQ + PRD, for the decision meeting)
    │
    │  "Does leadership align on this vision?"
    ↓
UXD (human-authored)
    │
    │  "How will users interact with this?"
    ↓
TRD (synthesized from PRD + UXD + MRD, where present)
    │
    │  "How will we build this technically?"
    ↓
TPD, IRD (synthesized from PRD/TRD/UXD)
    │
    │  "How will we test, deploy, and operate this?"
    ↓
spec.md (reconciled from all approved specs)
    │
    │  "What should the AI agent execute?"
    ↓
AI-Assisted Execution

MRD (product-scale) and OpportunitySpec (feature-scale) are optional and mutually substitutable — a team picks whichever fits, and it grounds the PRD; the door (one-way vs. two-way) sets the ceremony, the scale picks the deepening tool.

Why This Matters for AI Execution

When an AI coding agent executes from specifications, it benefits from:

1. Vision Anchoring

The Press Release creates an unambiguous target state. When the agent encounters conflicting requirements or ambiguous instructions, it can ask: "Which interpretation better serves the announced customer experience?"

2. Early Gap Detection

The FAQ forces explicit consideration of edge cases, scope boundaries, and potential objections. Questions like "What happens when..." are answered before implementation, not discovered mid-coding.

3. Testable Requirements

PRD derived from Press + FAQ tends to produce concrete, testable requirements rather than abstract feature lists. "Users can export reports in PDF format" is more actionable than "the system should support exports."

4. Traceability Chain

Every technical decision can trace back through the chain:

IRD decision → TRD requirement → PRD feature → FAQ clarification → Press vision

This enables principled conflict resolution during reconciliation.

Synthesized Documents in Git

All synthesized documents (FAQ, PRD, TRD, IRD, Narratives) are committed to git and can be:

  • Reviewed by stakeholders before approval
  • Edited by humans to add nuance or correct errors
  • Refined collaboratively with AI assistants like Claude Code
  • Versioned alongside the codebase

The initial synthesis provides a strong starting point, but human judgment remains in the loop at every stage.

Where Narratives Fit

The 1-page and 6-page narratives serve as stakeholder alignment documents:

Document Purpose When to Use
1-Page Narrative Executive summary for quick alignment Leadership reviews, status updates
6-Page Narrative Deep-dive for thorough review Team meetings, architecture reviews

Synthesize narratives after PRD but before starting technical work:

# Generate narratives for review
visionspec synthesize narrative-1p
visionspec synthesize narrative-6p

# Share with stakeholders, gather feedback
# Edit narratives as needed based on feedback

# Then proceed to technical synthesis
visionspec synthesize trd

Human vs. Synthesized Documents

In aws-one-way-door/aws-two-way-door (the canonical Working Backwards profiles):

Document Default Source Can Be Synthesized? Typical Workflow
Press Human-authored No — deliberately not synthesizable Write the founding artifact first
FAQ Synthesized Yes Synthesize from Press, add questions
MRD / OpportunitySpec Synthesized (optional deepening) Yes Synthesize from Press + FAQ to validate
PRD Synthesized Yes Synthesize from Press + FAQ + deepening
UXD Human-authored No Designer creates
Narrative Synthesized Yes Synthesize for the decision meeting
TRD Synthesized Yes Synthesize, architect reviews
TPD, IRD Synthesized Yes Synthesize, reviewed by their owners

Press is intentionally not synthesizable here — a press release generated from other documents is "working forwards", the exact inversion this methodology prevents. (Outside these two profiles, e.g. enterprise, Press/FAQ don't exist at all; MRD is the human-authored root instead.)

For New Projects

# 1. Initialize project
visionspec init my-feature

# 2. Write MRD (human-authored)
# Define market problem, audience, business goals

# 3. Synthesize Working Backwards chain
visionspec synthesize press    # Vision document
visionspec synthesize faq      # Challenge assumptions
visionspec synthesize prd      # Detailed requirements

# 4. Generate narratives for stakeholder review
visionspec synthesize narrative-1p
visionspec synthesize narrative-6p

# 5. Review and refine all documents
# Edit in git, collaborate with AI, gather feedback

# 6. Write UXD (human-authored)
# Define user journeys and interactions

# 7. Synthesize technical specs
visionspec synthesize trd --eval
visionspec synthesize ird --eval

# 8. Approve all specs
visionspec approve mrd
visionspec approve prd
# ... approve all

# 9. Reconcile into execution spec
visionspec reconcile

# 10. Export to target system
visionspec export speckit

For Existing PRDs

If you already have a human-authored PRD, you can still use Working Backwards for validation:

# Synthesize Press from existing MRD + PRD
visionspec synthesize press

# Generate FAQ to challenge the PRD
visionspec synthesize faq

# Compare FAQ questions with PRD coverage
# Update PRD to address gaps

Configuration by Profile

Different organizational stages need different levels of ceremony:

Profile Working Backwards Documents
0-1 Just hypothesis (no full flow)
startup PRD only (minimal ceremony)
growth PRD, FAQ (validate scope)
aws-one-way-door / aws-two-way-door Full Working Backwards flow (Press → FAQ → PRD → Narrative → TRD → IRD)
enterprise Full spec suite (MRD → PRD → UXD → TRD → TPD → IRD → spec); no Press/FAQ

Press-first Working Backwards is owned by the aws-one-way-door (canonical) and aws-two-way-door profiles. As of v0.17.0, enterprise is the pure contract layer and no longer provides or requires Press, FAQ, or the six-pager narrative.

# Initialize with appropriate profile
visionspec init my-feature --profile growth

References

The Working Backwards methodology was developed at Amazon and is documented in:

The definitive guide by two former Amazon executives (Bryar was Jeff Bezos's "shadow" for two years; Carr launched Amazon Music and Prime Video). Covers the PR/FAQ process, single-threaded leadership, and other Amazon mechanisms.

Practical application of Working Backwards for small and medium businesses.

Amazon's official overview of the methodology.