Five Customers, Three Prototypes, One Day: How to Find Your Bullseye Customer

Michael Margolis describes his process as the culmination of more than 30 years of product and UX work, recombined and adapted from many sources. He studied anthropology, and his first job — as an editor in educational software — was his introduction to usability testing. He then spent time at a boutique product design and innovation studio consulting for companies like Alcoa, DuPont and Ericsson, where he learned deep ethnographic research techniques through long, expensive consulting engagements.

Walmart.com taught him to compress those techniques and move fast, combining ethnographic discovery with usability work and getting lots of reps in a culture built on scale, everyday low cost and speed. At Google he was embedded in the Gmail team from 2006, running research through 'watch parties' — Google had invested early in video conferencing, streaming from the labs and one-way mirrors, so whole teams could watch sessions live. He brought that pattern to GV in 2010, when he became, by his account, the first UX research partner in venture capital.

Over 14 years at GV he has conducted more than 300 hands-on research sprints with portfolio companies, plus countless office hours, across biotech, healthcare, security, food and even farming. That volume is what lets him say which parts of the research toolkit pay off and which don't. The book that codifies the method, Learn More Faster: How to Find Your Bullseye Customer and Their Perfect Product, is available as a free PDF — he is not selling books or driving leads to GV.

A bullseye customer, he explains, is the very specific subset of your target market who initially is most likely to adopt your product or service — more specific than the ICP or personas most founders arrive with. Every ambitious founder wants to build for everybody, and as an investor GV wants those huge markets, but that is not where products start: Amazon sold only books, and Facebook was profiles for college students. Naming the narrow starting group streamlines everything — what you build first, whose feedback you prioritize, and how aligned the team is on what happens next.

The sprint follows a formula Margolis calls 'five and three in one': five bullseye customers, three very simple prototypes, and all the interviews conducted in a single day while the whole team watches and debriefs. The full plan, plus templates and resources, is downloadable free at learnmorefaster.com. The promise is not that one day answers every question, but that it changes a startup's trajectory by making the target customer concrete.

Recruiting is deliberately strict: the five participants must be people the entire team agrees match the bullseye definition, so that whatever the feedback turns out to be, nobody can dismiss it afterward. The method is qualitative — deep interviews about people's stories, motivations and past experiences, what they did, what worked and what didn't — rather than surveys. The sessions are clumped rather than spread across a week, ideally five one-hour interviews in one day, because batching makes patterns obvious and lets the team capture takeaways while the experience is fresh.

Five is also where qualitative research hits data saturation: somewhere around the fourth or fifth interview, everyone is hearing the same things again and is ready to change the prototypes or the customer. That is the signal that this group has taught what it can. Clumping the sessions also means the team leaves the day with clear answers to the few big questions they set out to answer, even if smaller questions remain open.

The three prototypes come from Margolis's time at Walmart, where he came to see the world as a shopping process. Show someone one couch and they will comment on the color and the cushions; show them three and they start comparing — this one has down cushions, that one delivers, the other takes away the old couch. Customers are not there to invent possibilities for you, so presenting three distinct value propositions lets them compare and contrast rather than pick a winner, and it keeps the team from over-committing to a single idea.

Margolis recommends running the sprint before the team has invested serious time, money and energy into building. It also fits specific transitions: expanding from one market to another (killing it in the UK and trying to enter the US), shifting from white-glove enterprise sales to a self-serve motion, or troubleshooting after launch when traction isn't what was hoped for. A particularly telling trigger is hearing polite, encouraging feedback that sounds good but is really a no.

Step one is a roughly 45-minute meeting with the core team to decide what they actually need to learn. He prompts with questions like 'what keeps you up at night?', 'what would have to be true for this to succeed?', 'what are your hypotheses and assumptions about the product and the customer?', and 'what are the nagging debates that keep coming up?' The output is a short list of the big questions the sprint is meant to answer.

Step two works backwards from those questions to the people who can answer them: questions about onboarding point to brand-new customers, while questions about a feature already shipped point to existing ones. Then comes what Margolis calls the bullseye exercise — another team session where he keeps asking 'what do you mean by that?' until the customer definition becomes uncomfortably specific. The exercise is clarifying in itself, because teams carry a shorthand about who their customers are and the interrogation surfaces debates they had never resolved.

Margolis pushes teams toward a definition so narrow it feels 'comically narrow' — a phrase Lenny recalls from Andy Johns — because the goal is a group everyone is convinced would say 'yes, I need this.' Narrowing is how he reduces variables: if participants vary too much, the day ends in mush and nobody can tell whether mixed feedback came from the product or from the audience. The definition is treated as a hypothesis, a best guess informed by the team's expertise, to be confirmed or corrected by the interviews.

He illustrates with a company building a delivery service for specialty prescription medications — expensive drugs for serious chronic conditions, not something you pick up at Rite Aid. The team needed to know whether urgency or predictability mattered more, and who exactly the early customer was. They built a list: people who had already had things delivered (say, Uber Eats), who had been on the medication long enough for it to be chronic rather than acute, whose housing density suited the delivery model, and who managed their own prescriptions rather than a spouse or a care setting. Pharmacists and healthcare workers were explicitly excluded — too much expert knowledge for five precious slots.

Three prototypes expressed different recipes — delivery within an hour, a four-hour window, or 'as soon as we can get there, just be home' — and the interviews surfaced something the team hadn't expected. A predictable, narrow arrival window mattered far more than speed, and it mattered most in specific scenarios: refrigerated medications that cannot sit on a stoop, cold chain concerns, theft risk, weather. That pointed to a much narrower bullseye — people with refrigerated medications who were dissatisfied with their current service and too busy to wait around — so the team re-recruited and ran the sprint again, and the match became obvious.

What a match looks like is qualitative and unmistakable: energy, enthusiasm, people asking 'wait, is this a thing? Can I sign up?' Margolis avoids the phrase product-market fit for this work, but the sensation is the same. He describes a founder who ran three rounds, killed a planned hardware-plus-software subscription product, and reported two benefits — saving enormous pain and, just as valuable, learning what 'no' looks like, since he could now recognize neutral, encouraging feedback for what it was. Failing to find the described people is itself a finding: either the definition went too narrow, or the customers being imagined may not exist.

The criteria for a bullseye definition fall into three groups — inclusion criteria, exclusion criteria and triggers — and they typically land at around seven attributes in total. Inclusion criteria are the easy part, because teams already know who they want in the room. Triggers are the group teams most often forget: specific events or situations that make someone ready for the solution.

Exclusion criteria are where Margolis spends the most time, because setting people aside does not come naturally to founders. He asks what would make someone a poor fit for now: too much expert knowledge, already locked into a competitor, or a personal history that distorts the picture — someone in bankruptcy or who has had their identity stolen is a real customer for a fintech product, but not the first place to start. Exclusion is what keeps the five slots precious.

Triggers move someone from 'I should do that someday' to 'this is on my to-do list.' A new CSO arriving and looking to rethink the security stack, something going sideways that demands a new solution, or — in an insurance-tech example — a millennial who has just had a baby or gotten married. The demographic was not the bullseye; the life event was.

The book offers a concrete checklist for narrowing: new or existing user, sector, organization size, competitive product use, disqualifying personal or professional experiences, title and role, geography, buyer versus end user, whether the team is distributed, budget and income, life and work settings, trigger events, and whether the customer is a VIP. That last one comes from a conversation about what makes one customer more valuable than another — a useful way to surface distinguishing characteristics a team has never articulated.

With criteria agreed, recruiting usually runs through a screener questionnaire built from those criteria. The craft is writing questions that don't reveal the right answers: offer $125 to any product manager who listens to Lenny's podcast and you get a flood of volunteers, but ask what podcasts someone listens to or where they get their most trusted information and you can pick out genuine matches. This is why the criteria must be concrete and measurable — 'active shopper' has to mean something like buying a specific kind of item three times a week before it can become a question.

Margolis relies heavily on userinterviews.com, and sometimes Respondent, to post screeners and get responses within three or four days; some studies pull 400 responses, which he downloads into a spreadsheet and sifts against the criteria. He notes that he used to recruit through Craigslist — including once meeting someone in a hotel room to test a robot — and that panel services are faster and more legitimate. A highly specialized search, such as a particular cohort of AI engineers, produces far fewer responses, which he treats as information about how hard those customers will be to reach.

For audiences that don't sit on panels, the approach changes: oncologists, for example, will not show up for a $125 incentive, so he looks for where they cluster online or in person — forums, conferences, professional associations — or uses snowball recruiting through a first contact's network, still filtering against the criteria. Being hard to find and hard to engage is itself a warning sign about the business, with the caveat that some genuinely valuable audiences simply require different techniques. Compensation has to be worth their time — roughly $125 an hour for consumers, and an attorney's hourly rate of about $400 in one recent study — and he vets responsiveness through NDAs and reminders rather than keeping backup participants.

One distinction underpins all of this: researching is not selling. Margolis points to Ed Schein's idea of 'humble inquiry' — the gentle art of asking instead of telling — and argues that founders are trained to pitch investors and customers, the opposite of the vulnerable, curious posture research requires. As an outsider he can say 'I don't know this space, explain it to me,' but founders find that hard because they don't want to appear ignorant. Separating learning mode from selling mode changes how the conversations go.

Prototype preparation means building three distinct recipes of features and variables rather than iterating on one design. Margolis's favorite shortcut is to use competitors' products as free prototypes — he is surprised more teams don't, and thinks a fear of 'cheating' or copying keeps them from watching how people respond to products that already exist. Where no competitor fits, he works out which variables to spread across the three versions.

In the medication example the variables included who delivers (a pharmacist, a courier, or a drone) and the size of the delivery window (a 15-minute slot two days out versus 'as soon as possible, just be home'). The artifacts themselves are flat PDFs that look like a product home page with no functionality — mostly a writing exercise articulating each distinct value proposition, brand promise and problem clearly and bluntly. They must stand alone, since he won't narrate or pitch them, and they should look visibly different so observers can track which one a participant means. Even with AI making functional prototypes cheap, he advises building only what's needed to answer the question and proofreading carefully, because typos undermine credibility.

Each one-hour interview has two halves. The first is a discovery interview about existing and past experience — how the person currently gets their medications, what worked, what didn't, a time it went sideways, a time it went perfectly. Halfway through, he shifts to presenting the three prototypes, asking people what they see, what they like and dislike, and then to compare and contrast. The goal is not a winner but the best Lego pieces from each, which can be assembled into the ideal version afterward.

Teams watching often want him to skip the discovery half and get to the prototypes, but that context is what makes the reactions legible: when someone distrusts a feature, the earlier story explains why. The interview is an arc — warm-up chit-chat about where they're dialing in from, rapport, then depth — designed to put people at ease in an inherently odd situation where they are paid to share personal details with a stranger. He smiles deliberately, even on the phone, watches for the participant smiling back, and stays genuinely curious, digging into answers that sound wrong instead of dismissing them. Interviewing is a skill that improves with practice, and he describes stepping into a 'listener character' before each session — a mode his own kids have noticed sounds nothing like Dad.

The watch party is where everything comes together. Margolis conducts each interview one-on-one on Zoom and livestreams it to the team, deliberately keeping the participant away from a gallery of observers. Design partners such as Kate Aronowitz or Vanessa Cho facilitate the back room, where the team takes collaborative notes by hand — no AI note-taking, so everyone leans in rather than checking Slack — in assigned turns, with a Slack channel running for questions and observations. A private chat with the facilitator lets the team pass him clarifying questions mid-interview, used judiciously because any new question can send the conversation somewhere unexpected.

Between interviews the team debriefs into a spreadsheet whose rows are the key questions the sprint set out to answer and whose columns are participants, building a high-level view across the day. The decider — the founder or product owner — leads each debrief and gathers input. At the end, everyone individually and quietly fills in a Google Form with their big takeaways, adjustments to the bullseye definition, and open questions, which the decider reviews for patterns. Consensus is usually remarkable, and the most common next step across all these studies is, ironically, more research — from teams who believed they already talked to customers all the time.

Before the watch party, Margolis asks everyone to predict specifically what they will learn. The predictions check that the interview guide matches what the team wants to know and, afterward, are compared with the actual takeaways to defeat hindsight bias — the near-universal feeling that 'we kind of knew that already.' Across hundreds of studies he has noticed recurring blind spots attributable to the curse of knowledge: expert teams overestimate how much customers know about the problem, how big the problem feels to them, how much they will pay, and how far along they are in being ready to buy.

The team needs to be there — 40 people have attended a single session, the record so far — but it matters most that the core product team is present for all of it, since they own the decisions and the work. When the process fails, the cause is almost always recruiting that wasn't picky enough: the bullseye bled, an expert or two slipped in, or the team insisted on customers they already knew, and the day ends mushy. Two other pitfalls: weight past behavior over people's predictions of what they'd do, and have the team police each other's confirmation bias during the watch party. Margolis is now adapting the method to biotech, where clinical trials, patient accrual and physician workflow are product problems that don't yet use product vocabulary.