whiteport-design-studio 0.1.0

package/docs/learn-wds/module-03-alignment-signoff/lesson-02-creating-alignment-document.md

@@ -0,0 +1,289 @@
+# 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)
+

package/docs/learn-wds/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md

@@ -0,0 +1,115 @@
+# Lesson 3: Negotiation & Acceptance
+
+**Getting everyone on the same page**
+
+**Time:** 10 minutes
+
+---
+
+## The Negotiation Phase
+
+**After creating your alignment document:**
+- Share it with stakeholders
+- Gather their feedback
+- Make changes and iterate
+- Update until everyone is on board
+
+**This phase is collaborative** - negotiation and iteration are welcome and expected.
+
+---
+
+## Sharing with Stakeholders
+
+**Present your alignment document:**
+- Share `docs/1-project-brief/pitch.md`
+- Explain that this is a draft for discussion
+- Invite feedback and questions
+- Be open to changes
+
+**Different ways to share:**
+- Email the document
+- Present in a meeting
+- Share via collaboration tool
+- Walk through it together
+
+---
+
+## Gathering Feedback
+
+**Listen for:**
+- Concerns or questions
+- Requests for clarification
+- Suggestions for changes
+- Different perspectives
+- Budget or timeline concerns
+
+**Document feedback:**
+- Note what stakeholders are saying
+- Understand their concerns
+- Identify what needs to change
+
+---
+
+## Iterating the Document
+
+**Make changes based on feedback:**
+- Update sections that need clarification
+- Address concerns raised
+- Incorporate suggestions
+- Refine until everyone is satisfied
+
+**Saga can help you:**
+- Update the alignment document
+- Refine sections based on feedback
+- Ensure clarity and completeness
+
+---
+
+## Getting Acceptance
+
+**Once everyone agrees:**
+- ✅ Everyone understands the idea
+- ✅ Everyone agrees on why, what, how
+- ✅ Budget is understood and accepted
+- ✅ Commitment is clear
+- ✅ **You have alignment**
+
+**This is the goal** - getting everyone on the same page before starting work.
+
+---
+
+## When Acceptance Happens
+
+**Acceptance might come:**
+- After one round of feedback
+- After multiple iterations
+- After a meeting discussion
+- After formal review process
+
+**Variable time** - could be hours or days. The alignment document helps speed this up.
+
+---
+
+## Key Principles
+
+- **Be flexible** - Changes are normal and expected
+- **Listen actively** - Understand stakeholder concerns
+- **Iterate willingly** - Refine until everyone is satisfied
+- **Stay collaborative** - Work together toward alignment
+
+---
+
+## After Acceptance
+
+**Once stakeholders accept:**
+- Alignment is achieved
+- Everyone is on the same page
+- Ready to secure formal commitment
+- Proceed to signoff document generation
+
+---
+
+**Next:** [Lesson 4: Securing Commitment →](lesson-04-securing-commitment.md)
+
+[← Back to Module Overview](module-03-overview.md)
+

package/docs/learn-wds/module-03-alignment-signoff/lesson-04-external-contracts.md

@@ -0,0 +1,201 @@
+# Lesson 4: External Contracts
+
+**Formalizing alignment with external contracts**
+
+**Time:** 15 minutes
+
+---
+
+## When You Need External Contracts
+
+**External contracts are for:**
+- **Consultant → Client**: You're proposing a solution to a client
+- **Business Owner → Suppliers**: You're hiring consultants/suppliers to build software
+
+**These contracts:**
+- Formalize agreements between separate parties
+- Include legal protections (jurisdiction, governing law)
+- Cover payment terms, IP ownership, confidentiality
+- Protect both parties legally
+
+---
+
+## Two Types of External Contracts
+
+### 1. Project Contract
+**For:** Consultant → Client  
+**When:** You're a consultant proposing to a client  
+**Perspective:** You're the contractor/service provider
+
+**Key Focus:**
+- Protecting your work and payment
+- Clear scope boundaries
+- Fair payment terms (upfront payment for fixed-price)
+- IP ownership transfer upon payment
+
+### 2. Service Agreement
+**For:** Business Owner → Suppliers  
+**When:** You're hiring consultants/suppliers to build software  
+**Perspective:** You're the client/owner
+
+**Key Focus:**
+- Protecting your investment
+- Ensuring deliverables meet requirements
+- Clear payment terms and milestones
+- IP ownership of deliverables
+
+---
+
+## Business Models
+
+**Before building the contract, determine the business model:**
+
+### Fixed-Price Project
+- Set price for defined scope
+- Not-to-exceed clause applies
+- Upfront payment recommended (50-100%)
+- Clear deliverables and scope boundaries
+
+### Hourly/Time-Based
+- Pay for actual time worked
+- Hourly rate and time tracking
+- Optional not-to-exceed cap
+- Flexible scope
+
+### Retainer
+- Monthly commitment
+- Minimum hours per month
+- Availability expectations
+- Overage hourly rate
+- Hour rollover policies
+
+### Hybrid
+- Combination of models
+- Multiple payment structures
+
+---
+
+## Key Contract Sections
+
+**Saga will guide you through building:**
+
+### 1. Business Model
+- Explains selected payment structure
+- Sets foundation for all payment terms
+- Clarifies expectations upfront
+
+### 2. Scope of Work
+- **IN Scope**: What's explicitly included
+- **OUT of Scope**: What's explicitly NOT included
+- **Deliverables**: What will be delivered
+- **The Path Forward**: How work will be done
+
+**Critical for fixed-price contracts** - Clear scope prevents disputes.
+
+### 3. Payment Terms
+**Adapted to business model:**
+
+**Fixed-Price:**
+- Upfront payment recommended (50-100% is fair)
+- Milestone payments tied to deliverables
+- Payment on completion (risky, not recommended)
+
+**Hourly:**
+- Billing frequency (weekly, bi-weekly, monthly)
+- Payment terms (Net 15, Net 30)
+- Time tracking requirements
+
+**Retainer:**
+- Monthly retainer amount
+- Minimum hours included
+- Overage billing
+- Hour rollover policy
+
+### 4. Availability (Retainer Only)
+- Business hours
+- Response time expectations
+- Meeting availability
+- Urgent request policies
+
+### 5. Not-to-Exceed Clause
+**Conditional based on business model:**
+- **Fixed-Price**: Required (equals project price)
+- **Hourly**: Optional cap if desired
+- **Retainer**: Not applicable (monthly cap exists)
+
+**Purpose:**
+- Prevents scope creep
+- Protects budget
+- Requires change orders for additional work
+
+### 6. Confidentiality Clause
+- What information is protected
+- Duration of confidentiality (typically 2-5 years)
+- Exceptions (public info, required by law)
+- Mutual protection
+
+### 7. Legal Framework
+- **Governing Law/Jurisdiction**: Which laws apply
+- **Contract Language**: Language of the contract
+- **Work Initiation**: When work can begin
+- **Dispute Resolution**: How conflicts are handled
+
+### 8. Other Important Sections
+- **Change Orders**: How scope changes are handled
+- **Termination**: How to exit the contract
+- **Intellectual Property**: Who owns what
+- **Timeline**: Delivery dates and milestones
+
+---
+
+## Best Practices
+
+**Saga will provide guidance on:**
+
+### For Consultants/Service Providers
+- Request upfront deposits (50%+ for fixed-price)
+- Define scope extremely clearly
+- Include change order process
+- Set not-to-exceed cap
+- Specify IP ownership transfer
+
+### For Clients/Business Owners
+- Review scope thoroughly
+- Understand payment terms
+- Know what's included/excluded
+- Understand change order process
+- Clarify IP ownership
+
+### Common Pitfalls to Avoid
+- Unclear scope definitions
+- Unfair payment terms
+- No change order process
+- Unclear IP ownership
+- No not-to-exceed cap (for fixed-price)
+
+**Goal:** Simple, fair contracts that build long-term relationships.
+
+---
+
+## After Contract is Finalized
+
+**Once contract is signed:**
+- ✅ Alignment achieved
+- ✅ Commitment secured
+- ✅ Legal protection in place
+- ✅ Ready to proceed to Project Brief
+
+**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
+
+---
+
+## Key Takeaway
+
+**External contracts formalize** agreements between separate parties with legal protections. They ensure clarity, protect both parties, and secure commitment before starting work.
+
+---
+
+**Next:** [Lesson 5: Internal Signoff Documents →](lesson-05-internal-signoff.md)
+
+[← Back to Module Overview](module-03-overview.md)
+