# Design & Discovery Sprint A Design & Discovery Sprint is a time-boxed, structured process to rapidly move from a problem space to a validated solution direction. Popularized by Google Ventures, this framework helps teams solve big problems, test new ideas, and reduce risk before building. ## When to Use This Sprint Use a Design & Discovery Sprint when you need to: - **Validate a new product idea** before significant development investment - **Solve a complex problem** that requires diverse perspectives - **Align stakeholders** on a solution direction - **Reduce months of debate** to days of focused work - **Test assumptions** with real users before committing resources ## Timeline Options Choose your timeline based on team availability, problem complexity, and urgency: ### Option 1: The 1-Week Sprint (5 Days) **Best for:** Simple problems, experienced teams, urgent decisions, single product features **Team commitment:** Full-time (9am-5pm daily) **Outcome:** Prototype + user validation in 5 business days ### Option 2: The 2-Week Sprint (10 Days) **Best for:** Complex problems, new teams, multiple solutions to test, strategic initiatives **Team commitment:** Full-time (9am-5pm daily) **Outcome:** Multiple prototypes + comprehensive user testing + detailed recommendations --- ## Team Composition Your sprint team should include: - **Decider** (1): Final decision maker (CEO, Product Lead) - **Facilitator** (1): Runs the sprint, keeps team on track - **Designer** (1-2): Creates prototypes and user flows - **Engineers** (1-2): Provide technical feasibility input - **Product/Marketing** (1-2): User insights and business context - **Subject Matter Experts** (optional): Domain knowledge **Ideal team size:** 5-7 people --- ## 1-Week Sprint Schedule ### Monday: Map & Define **Goal:** Understand the problem and choose a target **Activities:** - **9:00 AM** - Introduce sprint goals and structure - **9:30 AM** - Share long-term goals (What do we want to achieve?) - **10:30 AM** - Map the user journey (Create a visual map) - **12:00 PM** - Lunch break - **1:00 PM** - Ask the experts (Interview stakeholders) - **2:30 PM** - Define sprint questions (What must be true?) - **3:30 PM** - Pick a target (Choose critical moment to focus on) - **4:30 PM** - Day wrap-up **Deliverable:** Target problem area, sprint questions --- ### Tuesday: Sketch Solutions **Goal:** Generate diverse solution ideas **Activities:** - **9:00 AM** - Lightning demos (Review existing solutions) - **10:00 AM** - Four-step sketch (Individual ideation) - Step 1: Notes (20 min) - Step 2: Ideas (20 min) - Step 3: Crazy 8s (8 min) - Step 4: Solution sketch (30-60 min) - **12:00 PM** - Lunch break - **1:00 PM** - Continue solution sketches - **3:00 PM** - Recruit users for Friday testing - **4:00 PM** - Day wrap-up **Deliverable:** Multiple solution sketches from team members --- ### Wednesday: Decide **Goal:** Choose the best solution to prototype **Activities:** - **9:00 AM** - Art museum (Silent review of sketches) - **10:00 AM** - Heat map voting (Dot voting on interesting ideas) - **10:30 AM** - Speed critique (Discuss each solution - 3 min each) - **12:00 PM** - Lunch break - **1:00 PM** - Straw poll vote (Each person picks their favorite) - **1:30 PM** - Decider makes final decision - **2:00 PM** - Create storyboard (Step-by-step plan for prototype) - **4:30 PM** - Day wrap-up **Deliverable:** Storyboard for prototype --- ### Thursday: Prototype **Goal:** Build a realistic prototype for testing **Activities:** - **9:00 AM** - Prototype strategy meeting - **9:30 AM** - Divide and conquer (Assign roles) - **Makers:** Build prototype components - **Stitcher:** Combine everything - **Writer:** Create realistic copy - **Asset Collector:** Gather images, icons, content - **12:00 PM** - Lunch break - **1:00 PM** - Continue prototyping - **3:00 PM** - Trial run (Test the prototype internally) - **4:00 PM** - Finalize and polish - **4:30 PM** - Prepare interview script for Friday **Deliverable:** Realistic prototype ready for user testing --- ### Friday: Test & Learn **Goal:** Get feedback from real users **Activities:** - **9:00 AM** - First user interview (60 min) - **10:15 AM** - Debrief and capture notes (15 min) - **10:30 AM** - Second user interview (60 min) - **11:45 AM** - Debrief and capture notes (15 min) - **12:00 PM** - Lunch break - **1:00 PM** - Third user interview (60 min) - **2:15 PM** - Debrief and capture notes (15 min) - **2:30 PM** - Fourth user interview (60 min) - **3:45 PM** - Debrief and capture notes (15 min) - **4:00 PM** - Synthesize findings - **4:45 PM** - Decide on next steps **Deliverable:** User feedback report, validated learnings, next steps --- ## 2-Week Sprint Schedule The 2-week sprint follows a similar structure but with expanded time for each phase: ### Week 1: Diverge & Define **Days 1-2:** Extended problem mapping and stakeholder interviews - Additional time for competitive analysis - Deeper user research and persona development - More comprehensive journey mapping **Days 3-5:** Solution exploration - More time for individual sketching - Multiple rounds of Crazy 8s - Exploratory prototyping of different directions - Additional lightning demos from various industries ### Week 2: Converge & Validate **Days 6-7:** Decision and storyboarding - Multiple storyboards for different user scenarios - Risk assessment and technical feasibility deep-dive - Alignment sessions with broader stakeholders **Days 8-9:** Prototyping - Higher fidelity prototypes - Multiple prototype variations to test different hypotheses - More realistic content and data **Day 10:** Extended user testing - 6-8 user interviews instead of 4-5 - More diverse user segments - Longer synthesis and strategic planning session **Deliverable:** Comprehensive validation report with detailed recommendations --- ## Key Exercises & Tools ### Crazy 8s Rapidly sketch 8 variations of your idea in 8 minutes (1 minute per sketch). Forces quick thinking and prevents attachment to first ideas. ### How Might We (HMW) Questions Transform problems into opportunities: - ❌ Problem: "Users don't understand our pricing" - ✅ HMW: "How might we make pricing transparent and easy to compare?" ### Heat Map Voting Silent voting with dot stickers to identify the most interesting parts of solution sketches. Democratizes feedback and surfaces unexpected ideas. ### Solution Sketch A detailed, annotated sketch showing: - User flow through the solution - Key screens or moments - Explanatory notes - Catchy title --- ## Tools & Materials ### Physical Materials - Whiteboards or large paper - Sticky notes (multiple colors) - Sharpies and markers - Dot stickers for voting - Timer ### Digital Tools - **Prototyping:** Figma, Keynote, PowerPoint, or dedicated tools - **User Testing:** Zoom, Google Meet, or in-person - **Documentation:** Miro, Mural, or FigJam for collaborative boards - **Research:** Notion or Google Docs for notes --- ## Success Metrics Measure your sprint success by: - **Validated learning:** Did you answer your sprint questions? - **Team alignment:** Does everyone agree on next steps? - **User insights:** Did you learn something unexpected? - **De-risked decisions:** Can you invest confidently or pivot quickly? - **Actionable outcomes:** Do you know exactly what to build next? --- ## Common Pitfalls to Avoid ### ⚠️ Wrong Decider **Problem:** Person without authority to make final decisions **Solution:** Get exec commitment upfront or don't run the sprint ### ⚠️ Too Many People **Problem:** Team of 10+ makes decisions slow and sketching chaotic **Solution:** Keep core team to 7 or fewer, use experts as guest speakers ### ⚠️ Low-Fidelity Prototype **Problem:** Users can't provide realistic feedback on sketches **Solution:** Make prototype look real enough that users react naturally ### ⚠️ Skipping User Testing **Problem:** All sprint work is theoretical without user validation **Solution:** Protect Friday testing—it's the most important day ### ⚠️ Multitasking During Sprint **Problem:** Team members checking email, taking calls, attending other meetings **Solution:** Get full-time commitment, no laptops during workshops --- ## After the Sprint ### Immediate Next Steps (Week 1) Compile detailed findings report with user quotes and pain points Create prioritized list of insights by importance and feasibility Share results with broader team and stakeholders Schedule decision meeting with leadership ### Build or Iterate? (Week 2-3) **🟢 Strong validation → Build it** - Users understood the solution - Strong positive reactions (4-5 of 5 users excited) - Solves a real problem they're currently experiencing - → Move to MVP Build Sprint **🟡 Mixed results → Iterate** - Some aspects worked, others didn't - Users confused by parts of the experience - Solution is interesting but not essential - → Run another sprint with refined focus **🔴 Failed validation → Pivot** - Users didn't understand or value the solution - No clear problem-solution fit - Assumptions were wrong - → Revisit problem definition or explore different space --- ## Sprint Checklist ### 2 Weeks Before Recruit 5-7 core team members + 2-3 expert advisors Get decider commitment for full sprint duration Block calendars (9am-5pm daily, no conflicts) Reserve sprint room or virtual meeting space Prepare sprint supplies and tools ### 1 Week Before Share pre-sprint reading with team Recruit 5-6 users for Friday testing (incentivize appropriately) Create sprint brief (problem context, goals, constraints) Set up digital collaboration tools (Miro, Figma, etc.) Test prototyping setup and tools ### During Sprint Start and end on time every day Take photos of whiteboards and sketches daily Capture key decisions and "aha moments" Keep energy high (breaks, snacks, music) Protect the space from interruptions ### After Sprint Document all findings in shared location Thank users and send incentives Create executive summary with recommendations Archive all materials (sketches, prototypes, notes) Schedule retrospective with sprint team --- ## Example Timeline Visualizer Here's how to choose between 1-week and 2-week sprints: | Factor | 1-Week Sprint | 2-Week Sprint | |--------|--------------|---------------| | **Problem Complexity** | Single feature or flow | Platform or multi-feature | | **Team Experience** | Done sprints before | First time or new team | | **Prototype Fidelity** | Medium fidelity | High fidelity | | **User Segments** | 1-2 personas | 3+ personas | | **Solutions to Test** | 1-2 directions | 3-4 directions | | **Stakeholder Buy-in** | Already aligned | Need alignment | --- ## Real-World Examples ### 1-Week Sprint Success: Slack's File Sharing **Problem:** Users complained about sharing files in channels **Sprint Question:** Can we make file sharing feel more organized? **Outcome:** Prototype tested successfully, shipped 6 weeks later **Key Insight:** Users wanted threading, not folders ### 2-Week Sprint Success: Airbnb's Trust Experience **Problem:** Users hesitant to book with strangers **Sprint Questions:** What builds trust? How do we verify hosts? **Outcome:** Verified photos + review system prototype **Key Insight:** Professional photos increased bookings by 2-3x --- I'm planning a Design & Discovery Sprint for [describe your product/feature]. **Context:** - Problem we're solving: [problem description] - Target users: [user segment] - Current stage: [ideation / validating direction / improving existing feature] - Team size: [number] - Team's sprint experience: [first time / some experience / very experienced] **Constraints:** - Timeline preference: [1 week / 2 weeks / flexible] - Budget: [available for user recruitment, tools, etc.] - Remote/In-person: [all remote / hybrid / all in-person] Based on this information: 1. Should we do a 1-week or 2-week sprint, and why? 2. What should our sprint questions be? 3. Who should be on our core team? 4. What are the biggest risks we should plan for? 5. What prototyping tools would work best for our context? Help me create a customized sprint plan with daily schedules and key decisions. --- This structured approach has helped thousands of teams validate ideas in days instead of months. The key is committing fully to the process and truly listening to user feedback—even when it contradicts your assumptions.