294 lines
10 KiB
Markdown
294 lines
10 KiB
Markdown
# Module 03: Alignment & Signoff
|
|
|
|
## 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?
|
|
|
|
### 5. Recommended Solution
|
|
**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 →](lesson-03-negotiation-acceptance.md)
|
|
|
|
[← Back to Module Overview](module-03-overview.md)
|
|
|
|
|
|
*Part of Module 03: Alignment & Signoff*
|