Identify Your Bullseye Customer in One Day with Michael Margolis
- Aisha Washington
- 1 hour ago
- 7 min read
Startups often describe their market broadly: small businesses, healthcare providers, working parents, or anyone who wants to save time. Michael Margolis, UX Research Partner at GV, argues that these categories are rarely precise enough to guide early product decisions. Teams learn faster when they identify the narrow group most likely to feel the problem intensely and adopt the solution first.
In his conversation on Lenny’s Podcast, Margolis presents the bullseye customer sprint: a concentrated research process built around five carefully selected customers, three lightweight prototypes, and one day of interviews. The method is intended to help founders and product teams test assumptions before committing substantial time, money, or engineering effort.
Why the Bullseye Customer Is Narrower Than an ICP
An ideal customer profile, or ICP, may identify a promising industry, company size, job title, or demographic. A bullseye customer goes further. Margolis defines this customer as a highly specific subset of the wider market with an unusually strong reason to adopt the product early.
The distinction matters because broad customer definitions introduce too many variables. If five interview participants have different problems, levels of urgency, purchasing authority, and prior experiences, their reactions may be impossible to interpret. One person’s enthusiasm and another’s indifference might reflect differences between the participants rather than strengths or weaknesses in the product.
A bullseye definition reduces that ambiguity. It gives the team a common answer to several practical questions: Whose pain should shape the roadmap? Which feedback deserves priority? Where should recruiting and sales efforts begin? What must the product do exceptionally well?
Margolis points to companies such as Amazon and Facebook as examples of businesses that began with constrained audiences before expanding. The lesson is not that a company must remain confined to its first segment. Rather, focus can provide the initial traction and clarity required for broader growth.
The “Five and Three in One” Sprint
Margolis summarizes the sprint with a compact formula: five customers, three prototypes, one day.
The five participants should closely match the team’s current bullseye hypothesis. Each interview is typically about an hour, with sessions grouped into a single day when practical. A two-day schedule can work when time zones or availability make one day unrealistic, but keeping the sessions close together helps the team recognize recurring themes.
Five interviews may sound insufficient to teams accustomed to large surveys. Margolis is describing qualitative research, however, not an attempt to estimate population-wide preferences. The objective is to investigate stories, motivations, behaviors, and reactions in depth. With a tightly defined participant group, repeated patterns can begin to emerge quickly.
The three prototypes are deliberately simple. They might be sketches, mock-ups, landing pages, or other low-cost representations of distinct solutions. Their purpose is not to demonstrate production quality. Each should express a meaningfully different value proposition, workflow, or product direction.
Comparing alternatives changes the quality of the conversation. When shown only one concept, participants may offer superficial approval or suggest minor improvements. Multiple options give them reference points. They can explain why one promise feels more relevant, which tradeoff they prefer, and what none of the concepts gets right.
The comparison also protects the product team from becoming overly attached to one idea. Instead of treating a favored design as the default answer, the team can examine several hypotheses with greater neutrality.
When the Sprint Is Most Valuable
Margolis recommends running the process before a major commitment, particularly when uncertainty about the customer could make an investment difficult to reverse. It can be useful before building a new product, entering another geographic market, or adapting an enterprise offering for a self-service audience.
The sprint can also diagnose disappointing traction after launch. Weak sales, lukewarm engagement, or consistently polite feedback may indicate that the team is speaking to the wrong customers, solving a low-priority problem, or presenting the value in an unconvincing way.
This is not necessarily a one-time exercise. A company can repeat the sprint as its product, market, or customer hypothesis changes. Each round should address a consequential uncertainty rather than serve as routine validation theater.
Step 1: Agree on What the Team Needs to Learn
Margolis begins with a 45-minute discussion among the core team. The aim is to surface the questions that matter most before anyone writes an interview guide or recruits participants.
He suggests asking what keeps the founders or product leaders awake at night. What must be true for the idea to succeed? Which assumptions are carrying the most risk? What debates keep resurfacing without resolution?
These questions convert vague anxiety into research goals. A team might need to learn whether customers consider the problem urgent, whether a proposed workflow fits existing behavior, or whether a buyer would trust a new provider with sensitive information.
This meeting also prevents stakeholders from redefining success after hearing the interviews. When the team agrees on its uncertainties in advance, it has a clearer basis for interpreting what participants say.
Step 2: Define the Bullseye Customer
The right participant depends on the question. A team investigating onboarding should probably speak with recent customers. A team evaluating a feature for a mature product may need experienced users. A business exploring a new market should recruit people who represent the proposed entry segment, not its established audience.
Margolis describes the definition process as a team exercise that may involve substantial debate. That disagreement is productive: it exposes assumptions that might otherwise remain hidden.
He recommends making the initial definition almost uncomfortably narrow. The target should describe someone the team has strong reason to believe will recognize the problem and value the proposed solution. This is a research hypothesis, not a permanent boundary around the company’s market.
A useful profile can combine three types of criteria:
Inclusion attributes: characteristics or circumstances participants must have.
Exclusion criteria: conditions that make someone atypical or unsuitable for this round.
Triggers: recent events that make the need more immediate and increase readiness to act.
Triggers are especially important. A leadership change can create demand for new business software, while marriage or the arrival of a child can prompt someone to reconsider life insurance. The underlying need may have existed for years, but a specific event turns passive interest into action.
How a Medication-Delivery Team Found a Sharper Problem
Margolis illustrates the method with a company considering a delivery service for specialty prescription drugs. Before investing in complicated logistics, the team needed to understand what kind of delivery customers actually valued.
Its initial questions included whether medication had to arrive immediately, whether customers could wait a day or two, and which delivery windows would be acceptable. The team considered participants’ experience with delivery services, how long they had taken the medication, and whether they personally managed their prescriptions.
It also used exclusions. Pharmacists and healthcare workers, for example, might understand the system too well to represent an ordinary customer. People whose partners handled their medication would not reflect the intended behavior either.
The team then compared prototypes offering different delivery arrangements, including rapid delivery and scheduled windows. The research revealed that speed was not always the decisive benefit. For some customers, a narrow and reliable delivery window mattered more.
That preference was connected to concrete circumstances. Certain medications required refrigeration and could not safely remain outside. Other customers worried about theft or lived in places where unattended delivery was impractical. These conditions defined a smaller group with a more urgent, higher-value problem.
The company recruited again around those attributes and found stronger interest. Margolis describes genuine bullseye reactions as noticeably energetic: participants move beyond abstract praise and begin asking whether the service is available or how they can sign up.
Make Customer Research a Team Sport
The interviewer is not the only person who should encounter the evidence. Margolis advocates watch parties in which the broader team observes the sessions, records structured notes, and debriefs between interviews.
A facilitator can help the observers capture major takeaways in a spreadsheet or form. Short discussions after each session allow the team to compare interpretations while the conversation is still fresh. By the end of the day, recurring patterns are visible to everyone who must act on them.
This shared exposure reduces the need for a lengthy research report. More importantly, it limits the distortion that occurs when one researcher condenses hours of customer conversations for colleagues who were not present. Engineers, designers, founders, and commercial leaders hear the same stories and can build a common understanding of what customers need.
The process should still be disciplined. Observers need to distinguish direct evidence from interpretation, avoid treating a memorable comment as a universal truth, and look for patterns across participants rather than voting for their favorite prototype.
A Negative Result Can Be the Most Valuable Outcome
The sprint is not designed to guarantee approval. Margolis recounts a case in which research led a company to abandon a complex hardware-and-software product with a subscription component. Discovering the lack of demand early prevented a far more expensive failure after development.
A weak response may mean the proposed value is insufficient, the bullseye criteria are wrong, or the imagined customer is too rare to support a business. The team can revise its attributes, relax an unnecessary condition, test a different value proposition, or stop the project.
The critical signal is not generic positivity. Teams should look for evidence that the problem matters, that the concept fits the customer’s circumstances, and that the person wants to take a meaningful next step.
Margolis’s broader argument is that speed in product development does not come only from building faster. It also comes from resolving the right uncertainty before building. One focused day cannot answer every market question, but it can replace internal speculation with direct evidence—and reveal whether the team has found a customer worth building for.
