Product Discovery Sprint Template

A GV design sprint focuses on prototyping and testing a single solution concept in five days. A discovery sprint spends more time understanding the problem before generating solutions. Days 1-2 are entirely focused on customer interviews and assumption mapping. This is better suited for situations where the team is not yet sure they are solving the right problem.

Yes. Use Miro or FigJam for collaborative mapping, Zoom for interviews, and a shared Notion doc for the daily outputs. The critical requirement is that the team works synchronously during the morning and afternoon blocks. Async discovery sprints do not produce the same momentum or quality of insight.

Three is the minimum. Interview each person twice: once during problem exploration (Day 1-2) and once during validation (Day 5). You lose the diversity of perspectives that 5-8 users provide, but you still get usable signal. If you cannot find 3 users, postpone the sprint. Running discovery without users is just brainstorming.

Frame it in terms of risk and cost. "We are about to commit 3 engineers for 6 weeks to build [feature]. That is $X in salaries. A 1-week discovery sprint costs $Y and tells us whether we are building the right thing before we spend $X." The [RICE framework](/frameworks/rice-framework) can help you quantify the impact and confidence of the proposed feature to strengthen your case.

The sprint summary goes to the sponsor immediately. If the decision is "Go," the storyboard and interview recordings feed directly into user story writing. If it is "Kill" or "Pivot," write a one-page memo explaining what you learned and archive it in your team's research repository. Learnings from killed ideas prevent the next PM from re-investigating the same dead end. See the [decision log template](/templates/decision-log-template) for capturing the rationale. ---