BMAD-METHOD/docs/learn-wds/module-03-alignment-signoff/lesson-02-creating-alignmen...

10 KiB

Lesson 2: Creating Your Alignment Document

The 10 sections that ensure everyone understands and agrees - AFTER you've done discovery

Time: 20 minutes


Before You Create: The Discovery Phase

You are NOT ready to create an alignment document until you've completed discovery.

Remember:

  • The carpenter measures twice before cutting once
  • The doctor diagnoses before writing a prescription
  • You understand deeply before creating your pitch

Have you:

  • Had a discovery conversation with your stakeholder?
  • Asked questions until you found the real pain point?
  • Confirmed that pain point actually exists?
  • Taken notes on what success looks like for THEM?
  • Said "Let me think about this and come back"?

If NO to any of these: Go back and complete discovery first. Don't guess what they need.

If YES: Now you're ready to create a compelling alignment document based on real understanding.


What is an Alignment Document?

An alignment document (also called a "pitch") is a clear, brief document that:

  • Reflects back what you learned in discovery
  • Makes the case for why the project matters (in their words)
  • Presents your solution based on understanding their needs
  • Gets stakeholder buy-in before starting detailed work
  • Can be read in 2-3 minutes
  • Allows for negotiation and iteration

Key principle: You're not making this up or guessing. You're synthesizing what they told you they need into a clear, compelling document.


The 10 Sections

Work through these sections in whatever order makes sense for your thinking:

1. The Realization

What we've realized needs attention

  • What observation have you made?
  • What challenge are you seeing?
  • What evidence supports this realization?

2. Why It Matters

Why this matters and who we help

  • Why does this matter?
  • Who are we helping?
  • What are their pain points?
  • What impact will this have?
  • How does this add value to specific people?

3. How We See It Working

Brief overview of the solution approach

  • How do you envision this working?
  • What's the general approach?
  • How does it address the realization?
  • What's the core concept?

4. Paths We Explored

2-3 solution options we considered

  • What alternatives did you consider?
  • Why did you explore these paths?
  • What are the trade-offs?

Preferred approach and why

  • Which solution do you recommend?
  • Why this solution over others?
  • What makes it the best choice?

6. The Path Forward

How the work will be done

  • Which WDS phases are included?
  • What's the practical approach?
  • How will the work be executed?

7. The Value We'll Create

What happens if we DO build this

Frame as positive assumption with success metrics:

  • Our Ambition: What we're confidently striving to accomplish (enthusiastic, positive)
  • Success Metrics: How we'll measure success (specific, measurable)
  • What Success Looks Like: Clear outcomes (tangible results)
  • Monitoring Approach: How we'll track these metrics (brief)

Key principle: "We're confident this will work, and here's how we'll measure our success"

8. Cost of Inaction

What happens if we DON'T build this

  • What are the consequences of not acting?
  • What opportunities are lost?
  • What problems continue or worsen?

9. Our Commitment

Resources needed and potential risks

  • What's the budget?
  • How much time is needed?
  • What team/resources are required?
  • What potential risks or challenges should we consider?

10. Summary

Summary of key points

  • Recap the key points
  • Let readers draw their own conclusion

Best Practices: Identifying and Confirming the Realization

The foundation of a compelling alignment document is a well-articulated realization that stakeholders recognize and agree needs attention.

Step 1: Identify the Realization or Challenge

Start by clearly articulating:

  • What have you realized needs attention?
  • What observation or challenge are you seeing?
  • What opportunity is being missed?

Be specific - Vague realizations lead to vague solutions. Instead of "users are frustrated," say "we've realized that users abandon the checkout process 40% of the time because it requires 12 form fields."

Step 2: Confirm It's Real

Don't assume - Verify that this realization is grounded in reality:

  • Ask stakeholders directly
  • Observe behavior
  • Review existing data
  • Check if others have noticed this too

A real realization has:

  • Clear evidence supporting it
  • Measurable indicators
  • Stakeholders who recognize it
  • Impact that matters

Step 3: Present Evidence

Evidence makes your realization credible. Use both soft and hard evidence:

Soft Evidence (Indications, Testimonials, Complaints)

What it is: Qualitative indicators that support the realization

Examples:

  • Testimonials: "Our customers tell us they struggle with..."
  • Complaints: "Support tickets show users complaining about..."
  • Indications: "We've noticed that users often..."
  • Anecdotes: "In our user interviews, three people mentioned..."
  • Observations: "When we watch users, they consistently..."

How to use it:

  • Quote specific feedback or complaints
  • Reference user interviews or conversations
  • Mention patterns you've observed
  • Include stakeholder concerns you've heard

Example:

"Our customer support team reports that 60% of support tickets are about users unable to find the settings menu. One customer wrote: 'I've been using this for 6 months and still can't figure out where the settings are.'"

Hard Evidence (Statistics, Log Analysis, Survey Tests)

What it is: Quantitative data that supports the realization

Examples:

  • Statistics: "40% of users drop off at checkout"
  • Log analysis: "Server logs show 500 errors occur 3x per day"
  • Survey results: "85% of survey respondents rated this feature as 'difficult to use'"
  • Analytics: "Bounce rate increased 25% after the redesign"
  • A/B test results: "Version A had 30% higher completion rate"
  • Performance metrics: "Page load time averages 8 seconds"

How to use it:

  • Include specific numbers and percentages
  • Reference time periods ("in the last quarter")
  • Compare to benchmarks or previous performance
  • Show trends over time

Example:

"Analytics show that 45% of users abandon the checkout process, with an average of 8 minutes spent before leaving. This represents a 20% increase from last quarter. Server logs indicate that 15% of these abandonments occur during payment processing, suggesting technical issues."

Combining Soft and Hard Evidence

Best practice: Use both types together for maximum impact:

Example:

"Our customers consistently report frustration with the checkout process (soft evidence: testimonials). Analytics confirm this: 45% abandon checkout, and those who complete it take an average of 12 minutes - 3x longer than industry standard (hard evidence: statistics). Support tickets show 60% of complaints are about checkout complexity (soft evidence: complaints), and our recent survey found 78% of users rated checkout as 'difficult' (hard evidence: survey)."

Why Evidence Matters

Without evidence:

  • Stakeholders may not believe the realization is real
  • You might address the wrong thing
  • Budget approval is harder to get
  • The case for action is weak

With evidence:

  • Stakeholders recognize the realization
  • The urgency is clear
  • Budget approval is easier
  • The case for action is compelling

Where to Find Evidence

Look for evidence in:

  • Customer support tickets and feedback
  • User interviews and surveys
  • Analytics and usage data
  • Server logs and error reports
  • Sales conversations and objections
  • Competitive analysis
  • Industry reports and benchmarks
  • Internal team observations

If you don't have evidence yet:

  • Acknowledge this in your alignment document
  • Propose gathering evidence as part of the project
  • Use stakeholder conversations as initial evidence
  • Reference similar realizations in the industry

Flexible Exploration

You can start anywhere:

  • Start with something you've realized needs attention (from discovery)
  • Start with a solution you have in mind (based on understanding their needs)
  • Start with why it matters (using what they told you)

Saga will guide you through all sections in whatever order makes sense for your thinking. But everything should be grounded in what you learned during discovery.

If you realize you don't actually know something: Don't guess. That's a signal you need to go back and ask more discovery questions. Saga will help you identify what's missing.


Extracting Information (Optional)

If you have existing communications or documents:

  • Share emails, chats, or documents with stakeholders
  • Share notes from your discovery meeting
  • Saga will extract key information:
    • Realizations or observations mentioned
    • Requirements discussed
    • Concerns raised
    • What success looks like for them
    • Context and background
    • Timeline or urgency
    • Budget or constraints

This helps inform your alignment document sections with real evidence from your conversations.


Synthesizing the Document

After exploring all sections:

  • Saga will help you synthesize into a clear, compelling document
  • Review together: "Does this capture your idea?"
  • Make adjustments until it's right
  • Create: docs/1-project-brief/pitch.md

Key Principles

  • Discovery first - Understand before you create the document
  • Collaborative - You and Saga build it together
  • Grounded in their needs - Based on what they told you matters
  • Iterative - You can refine and improve
  • Clear - Readable in 2-3 minutes
  • Compelling - Makes the case for the project using their language

Remember: When you genuinely understand what they need and can clearly specify their desired outcomes, writing the pitch becomes 10x easier. You're not guessing or convincing - you're articulating back to them what they said they need with a clear path forward.


Next: Lesson 3: Negotiation & Acceptance →

← Back to Module Overview