Run a Product Discovery Sprint
Product & Design · 1 week · Intermediate
The job
Compress product discovery into a 1-week sprint that produces a testable prototype and clear next steps.
What the sponsor gets
Each canvas and map from this playbook — Jobs-To-Be-Done Canvas, Persona Canvas, Assumption Map, Experiment Canvas, Journey map — exports as a PDF, or as PowerPoint on Pro, straight from the session, and the whole run exports as one PowerPoint for the sponsor. Nothing is redrawn.
The method
Day 1: Frame the problem
Create a JTBD canvas to align the team on the customer problem you are solving. Use existing research, support tickets, and user interviews to ground the discussion in evidence, not opinion.
Tip: If the team cannot agree on the job to be done in the first morning, the sprint will produce a solution to the wrong problem — resolve this before moving on.
Day 1: Define who you are solving for
Create a Persona canvas for the primary user. Keep it tight — one persona, grounded in research. The sprint needs a specific target, not a vague "our users".
Tip: Pin the persona to the wall for the rest of the week — every design decision should pass the test of "would this person actually do this?"
Day 2: Map and prioritise assumptions
List every assumption the team is making about the problem, the user, and the proposed solution. Plot them by importance and certainty. The top-right quadrant defines what the prototype must test.
Tip: Limit to 3 assumptions to test — the prototype cannot validate everything, so pick the ones that would kill the idea if wrong.
Day 3: Sketch and decide
Run a structured sketching session where each team member produces solution concepts independently, then the group critiques and selects the strongest ideas. Avoid design-by-committee — use dot-voting to converge.
Tip: Give everyone 30 minutes of silent sketching before any discussion — the best ideas come from individual thinking, not group brainstorming.
Day 3: Storyboard the user flow
Create a journey map showing how the user discovers, engages with, and gets value from the proposed solution. This becomes the prototype script and the test plan.
Tip: Start the storyboard before the user opens your product — the moments before and after usage reveal whether the solution fits into their real life.
Day 4: Build the prototype
Build a realistic-looking prototype that tests the critical assumptions. It does not need to work — it needs to look real enough that users react honestly. Assign roles: maker, writer, asset collector.
Tip: A Figma prototype with real copy beats a coded MVP with lorem ipsum — users respond to words more than wireframes.
Day 5: Test and synthesise
Test the prototype with 5 users. Create an Experiment Canvas documenting the hypothesis, what you observed, and the verdict for each assumption. End the sprint with a clear go/pivot/kill decision.
Tip: Five users reveal 85% of usability issues — do not delay testing to find more participants.
The canvases and maps
- Jobs-To-Be-Done Canvas
- Functional, emotional and social jobs sit apart from pain points and desired outcomes, so the team describes the progress people want rather than the features it plans.
- Persona Canvas
- Goals, frustrations, behaviours, motivations and needs side by side, so the person you are designing for is specific enough to disagree about.
- Assumption Map
- Assumptions plotted by importance and certainty, so the leaps of faith that need testing first stand apart from the safe bets.
- Experiment Canvas
- Hypothesis, design, metrics and success criteria come before results and the decision, so the goalposts are written down before anyone sees the data.
- Journey map
- Stages run across and lanes run beneath them, so the experience reads in the order people live it and each low point lines up with what causes it.
What it doesn't do
It doesn't run the room for you or decide for the client. The steps, canvases and duration are a starting point you adapt; the judgement stays yours.