The Bullseye Customer Sprint (5 + 3 in 1)
Interview five hand-picked customers against three prototypes in one team-watched day to learn who to build for
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 95%
A one-day research sprint that de-risks what a team is about to build by testing it against the narrowest, most-likely-to-adopt customer segment. The formula is five bullseye customers, three simple prototypes, conducted in one clumped day while the whole team watches. It replaces months of building-then-hoping with a fast, aligned read on whether the right people actually want the thing.
Origin
Developed by Michael Margolis over 30+ years of UX/product research — anthropology roots, a Doblin-style innovation consultancy, Walmart.com, the early Gmail team, and 15 years as GV's first UX research partner across 300+ hands-on sprints. Synthesizes and compresses deep ethnographic technique into startup speed. Published free at learnmorefaster.com. Related design-sprint lineage to the book 'Sprint'.
Core principles
- 01Every ambitious founder wants to build for everybody, but successful products start narrow (Amazon books, Facebook college profiles)
- 02Clumping interviews into one day surfaces patterns that spaced-out interviews hide
- 03Five interviews reach 'data saturation' — you hear the same things repeatedly and it's enough
- 04This is a learning exercise, not selling — run it before you sink energy and money into building
- 05The whole team watching removes the need for a report and creates instant alignment and momentum
How to run it
- 1
Run a 45-minute key-questions meeting with the core team
Gather the core team and ask what keeps you up at night about the product and customers — what would have to be true to succeed, what are the nagging team debates, what are your hypotheses and assumptions about product and customer.
Pro tip Ask 'what keeps you up at night' to surface the real fears founders are bubbling on.
- 2
Define the bullseye customer via a team bullseye exercise
Work backwards from the key questions to define the specific subset most likely to adopt. Pepper the team with 'what do you mean by that' questions until the definition is concrete and measurable across ~seven attributes.
Pro tip The definition should feel 'comically narrow' (a phrase Margolis endorses from Andy Johns) — you're reducing variables like an experiment, not sizing a market.
Watch out Teams resist narrowing because they don't want to exclude big markets; push through it — too much variation makes the end-of-day result feel 'mushy' and unlearnable.
- 3
Recruit five matches with a non-telegraphing screener
Translate the criteria into a screener questionnaire worded so it doesn't reveal the right answers, post it on services like userinterviews.com or respondent, and sift responses (sometimes hundreds) to pick five true bullseyes.
Pro tip Ask indirectly ('what podcasts do you listen to?') rather than 'do you listen to X?' so respondents can't game the incentive; keep criteria concrete and measurable (e.g. 'active shopper = buys 3x/week').
Watch out If you genuinely can't find these people, treat it as a signal the segment may not exist or will be too hard to sell to — don't just loosen criteria reflexively.
- 4
Build three distinct comparison prototypes
Create three flat PDF/image mockups expressing different recipes of value proposition — no functionality. Make them visually distinct (green/blue/red, not A/B/C) so observers can track which one a participant discusses. Competitors' live products count as free prototypes.
Pro tip It's mostly a writing exercise: crisply articulate the distinct value prop and brand promise so people instantly get it; proofread carefully because errors undermine credibility.
Watch out Don't over-invest in polished or functional prototypes — keeping them simple prevents the team from getting over-committed to one idea, and you build only enough to answer the question.
- 5
Draft a two-part interview guide
Structure each one-hour interview as a discovery half (past and current experiences, what worked, what went sideways) then a compare-and-contrast half where the participant reacts to all three prototypes and cherry-picks the best 'Lego pieces'.
Pro tip The discovery half gives crucial context that explains the prototype reactions — resist the team's urge to 'just show them the prototypes'.
Watch out Don't pitch or narrate the prototypes; let them stand alone so reactions are genuine.
- 6
Run the watch party and capture big takeaways
Live-stream five clumped interviews to the whole team, who take manual notes and debrief between each session. Do a pre-interview prediction round, then end the day with an individual 'big takeaways' form and a team review to realign the bullseye definition and next steps.
Pro tip Compare end-of-day takeaways to the pre-interview predictions to defeat hindsight bias and show how much was actually learned.
Watch out The core product team must attend all of it; drop-in observers are fine but decisions need the people who will own and build the thing.
In the wild
A company building delivery for expensive chronic-disease medications first defined its bullseye broadly (anyone on specialty meds who had used Uber Eats, self-managed their meds, right density). Testing three delivery-window prototypes revealed that a predictable narrow window mattered far more than ASAP — and only for a subset with refrigerated/cold-chain meds or theft concerns. They re-recruited that narrower subset and ran it again.
→ Confidence built in the match between problem, product and a much narrower bullseye (cold-chain patients), because their need was far more acute than the general specialty-meds population.
A founder ran the Bullseye Customer Sprint three times on a complex hardware/software/subscription product using cheap prototypes. The feedback was consistently neutral-positive rather than enthusiastic. He recognized what 'no' looks like and chose to focus on another part of his business.
→ Killed the project before building it — saving enormous time and money — and gained a durable ability to recognize polite-but-fake demand.
Common mistakes
Letting the bullseye 'bleed' during recruiting
When the team takes over recruiting and isn't picky enough — including experts they already know or loosely-matching people — the day produces a mushy result where you can't tell if reactions were mixed feelings or just inconsistent participants.
Trusting stated intent over demonstrated behavior
Participants who say 'I would totally use this' are unreliable predictors; weight what they've actually done in the past far more heavily, and be skeptical when a prototype reaction contradicts their described behavior.
Over-building the prototypes
Polished or functional prototypes make the team over-committed to one idea and waste effort; flat PDFs that nail the value-prop wording answer the question without the attachment.
Is it for you?
Best for
Early-stage founders and product teams about to invest heavily in building, entering a new market/segment, or troubleshooting weak traction and polite-but-flat feedback
Not ideal for
Pure science/R&D phases with no productization yet, or when you're in active selling mode rather than genuine learning mode
From the transcript
“so it's five Bullseye customers and three very simple prototypes and then we conduct those interviews in one day um while the whole team is…”
“a bullseye customer is the very specific subset of your target market who initially is most likely to adopt your product or service”
“you hit what's called Data sat auration”
“I don't write a report I haven't written a report in I don't know 10 years”
From the episode
Identify your bullseye customer in one day
Michael Margolis (UX Research Partner at Google Ventures)