Five-Day Design Sprint Problem Brief
Structure intensive 5-day Google Ventures design sprints: map problems, sketch solutions, decide, prototype, and test.
Template Overview
Developing new product ideas through standard corporate cycles often takes months of meetings, extensive back-and-forth specifications, and expensive development—only to launch and discover the core hypothesis was flawed.
The Google Ventures 5-Day Design Sprint compresses months of debate into a single focused week: understanding the problem on Monday, sketching competing solutions on Tuesday, making hard decisions on Wednesday, building a realistic facade prototype on Thursday, and testing with five real users on Friday.
This template provides an end-to-end Design Sprint headquarters: sprint challenge framing, How Might We (HMW) queries, map target selection, storyboard decider votes, prototype specs, and Friday customer test findings.
Markdown Template Structure
Copy the block below or click Download .md File to add this template directly to your personal vault:
---
title: "Design Sprint: [Sprint Challenge / Question]"
date: [YYYY-MM-DD]
sprint_challenge: "How might we empower privacy-conscious professionals to record and structure meeting notes with zero cloud anxiety?"
decider: "[[CEO Robert Sterling]]"
facilitator: "[[Lead Design Sprint Facilitator]]"
sprint_team:
- "[[Lead Product Designer]]"
- "[[Chief Systems Architect]]"
- "[[Head of Customer Success]]"
- "[[Senior UX Researcher]]"
target_test_date: 2026-10-16
tags: [design-sprint, gv-sprint, innovation, prototyping, user-testing]
---
# Design Sprint: [Sprint Challenge / Question] — [YYYY-MM-DD]
## 1. The Big Sprint Challenge & Long-Term Goal
- **The Core Question:** Can we design a meeting recording interface so transparent and privacy-evident that corporate attorneys and healthcare professionals immediately trust it with confidential conversations?
- **2-Year Vision:** Sovereign on-device meeting recording becomes the undisputed enterprise gold standard for privacy-regulated industries.
## 2. Monday: Map & How Might We (HMW) Queries
### Top How Might We (HMW) Questions
- *HMW 1:* How might we visually prove that audio never leaves the user's Mac without overwhelming them with technical jargon?
- *HMW 2:* How might we make copying a Markdown template feel as instantaneous as taking a physical screenshot?
- *HMW 3:* How might we structure meeting summaries so they integrate seamlessly into existing Obsidian vaults?
- **Selected Target on Map:** The transition between ending an active video call and seeing the structured Markdown note appear on local disk.
## 3. Tuesday: Sketch & Competing Solution Concepts
- **Concept Alpha (Floating Security Pill):** A minimal menu bar widget showing real-time Apple Silicon Neural Engine status and verified 0-byte network egress.
- **Concept Beta (Vault Autopilot):** An automated background file watcher that silently deposits formatted Markdown notes into a designated folder.
## 4. Wednesday: Decide & The Storyboard
> [!IMPORTANT] The Decider's Choice
> [[CEO Robert Sterling]] selected **Concept Alpha (Floating Security Pill)** paired with one-click vault deposit.
> **Key Reason:** Establishing visible, verifiable privacy proof is our primary commercial moat.
## 5. Thursday: Prototype Specifications
- **Prototype Medium:** Interactive high-fidelity clickable prototype built with native macOS UI styling.
- **Prototype Scope:** 5-screen flow simulating a live Zoom call recording, menu bar security indicator, and instant Markdown note generation.
## 6. Friday: Five-User Customer Test Synthesis
| Participant | Background | Core Reaction | Would They Trust It? | Key Quote / Observation |
| :--- | :--- | :--- | :--- | :--- |
| User 1 | Trial Attorney | Visibly impressed by local hash verification | 🟢 Yes | "This solves my attorney-client privilege anxiety completely." |
| User 2 | Health Data Analyst | Loved the menu bar security status | 🟢 Yes | "If our IT team saw this zero-egress pill, they would approve it immediately." |
| User 3 | Engineering Lead | Looked for Markdown frontmatter customization | 🟡 Yes (with tweaks) | "I want to customize the YAML tags before saving." |
| User 4 | Executive Coach | Praised the distraction-free UI | 🟢 Yes | "No uninvited bot joining my calls is worth everything." |
| User 5 | Corporate Auditor | Demanded offline license proof | 🟢 Yes | "Verified offline execution is exactly what we need." |
## 7. Sprint Verdict & Immediate Product Next Steps
> [!IMPORTANT] Sprint Verdict: Green Light for Production
> 5 of 5 target users confirmed high willingness to trust and adopt the on-device recording interface. Validated our core architectural hypothesis.
- [ ] Transition prototype flows into formal Product Requirements Document ([[PRD-Desktop-Recorder]]).
- [ ] Begin engineering implementation in Sprint 26.
Filled Real-World Example
Here is a realistic example demonstrating how this template captures actual deliberations:
---
title: "Design Sprint: On-Device Security UI"
date: 2026-10-09
decider: "[[Robert Sterling]]"
target_test_date: 2026-10-16
tags: [design-sprint, prototyping]
---
# Design Sprint: On-Device Security UI — October 9, 2026
## 1. Challenge
Can we design a menu bar security pill that proves zero network egress during recording?
## 2. Test Result
5 of 5 legal/health testers validated concept. Proceeding with production build.
When to Use and When to Avoid
When to Use
- Use during intensive 5-day Google Ventures design sprints to answer high-stakes product questions.
- Use to rapidly prototype, validate, and test new software concepts before writing code.
- Use to align cross-functional teams around a shared challenge, decider vote, and user test.
When to Avoid
- Avoid using for routine incremental feature tweaks that don’t carry high strategic uncertainty.
- Avoid using for ongoing daily agile sprint planning.
On-Device AI Integration
Capture 5-day design sprint workshops with Oyma on macOS:
Analyze the design sprint workshop audio transcript:
1. Synthesize the framing sprint challenge, long-term vision, decider name, and sprint team members.
2. Outline Monday's How Might We (HMW) questions and map target selection.
3. Detail Tuesday's competing sketch concepts, Wednesday's decider vote, and Thursday's prototype specs.
4. Build Friday's customer test synthesis table recording participant feedback, trust verdicts, and quotes.
5. Record the final sprint verdict and immediate engineering next steps.
Output in structured, collaborative CommonMark format.
Your proprietary design sprint concepts and rapid user test findings stay safely on your Mac.
Frequently Asked Questions
What is the GV Five-Day Design Sprint?
Created by Jake Knapp at Google Ventures, it is a fast-paced 5-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
What happens on each of the 5 days?
Monday: Map problem. Tuesday: Sketch solutions. Wednesday: Decide on best approach. Thursday: Build realistic prototype. Friday: Test with 5 real users.
Why is having a designated 'Decider' crucial?
To prevent endless design debates from stalling progress, a designated executive decider makes the final choice on Wednesday.
Write five-day design sprint problem brief in plain Markdown.
Store notes in your local vault, transcribe meetings on-device, and retain 100% data sovereignty.