I've run a lot of product sprints. Most of the ones that flopped didn't flop on ideas — they flopped on setup. Here's the checklist I lean on to make a sprint actually produce something.
Before the sprint
The real work happens before anyone walks in the room.
- Frame a sharp challenge: "improve onboarding" is useless. "Cut signup drop-off by 30%" is a target. Write it as a question: "How might we cut signup drop-off by 30%?"
- Get the right five people: a decider who can actually commit, a designer, an engineer, someone who knows the customer. Five is the number. Past seven, it stalls.
- Be honest about the output: a sprint doesn't ship production code. It produces a tested prototype and a real decision. Say so up front.
- Block the calendar and defend it: five days, same hours. Sprints die when people treat them as optional.
During the sprint
Keep the rhythm tight:
- Day 1 — Understand: map the problem, talk to stakeholders, set the metric. End knowing what you'll prototype.
- Day 2 — Diverge: generate, sketch, go wide. Don't converge yet.
- Day 3 — Decide: critique, pick one path, storyboard it. This is where teams stall. Push through.
- Day 4 — Prototype: build something testable. It doesn't need to be pretty, just real enough to get an honest reaction.
- Day 5 — Test: five users, one at a time. Watch. By the third, the pattern is usually obvious.
After the sprint
This is where most of the value leaks out. Don't let it:
- Write the decisions down within 24 hours: what you learned, what you'll build, what you're killing.
- Book the follow-up now. A sprint creates momentum; protect it with a two-week check.
- Share it loudly: the people who ran it know the most, so make them tell leadership, engineering, support. Don't bury it in a deck.
Run a sprint when you're stuck between options or alignment is broken. Don't run one when you already know the answer.
A good sprint doesn't only hand you a prototype. It hands you clarity. That's the part that lasts.