# 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*