(2024-12-01) Rachitsky Identify Your Bullseye Customer In One Day

Lenny Rachitsky: Identify your bullseye customer in one day. Today, my guest is Michael Margolis. Michael has been a UX researcher at Google Ventures for almost 15 years.

He helped develop the Design Sprint method, made famous by the book Sprint, and more recently wrote a book called Learn More Faster: How to Find Your Bullseye Customer and Their Perfect Product, which essentially helps you identify and refine your ideal customer profile in a single day.

I've said many times on this podcast that one of the biggest mistakes founders make and product teams make is not being very clear and very narrow with their initial target market segment, and I've been looking for a book and a guide to help people figure this out. This book is that.
And also, this book is completely free and available online as a PDF.

I've been doing this kind of product and UX work for over 30 years.

started out studying anthropology.

My first job was working in educational software as an editor, so it was kind of introduction to UX, my introduction to usability testing, and went from there to working at a boutique product design innovation studio, so basically consulting with big companies like Alcoa and DuPont and Ericsson, and so learning really deep ethnographic research techniques, very big, long, expensive consulting projects.

And then from there, I went to Walmart.com.

From there, I went to Google.
So I was embedded in the Gmail team early on, in 2006. And so what we did there was then combining these also at scale, doing this kind of innovation at speed. You can see this trend of getting faster and faster.

Google Ventures, when I joined in 2010.

So I was the first UX research partner in venture capital at the time.

How many companies/founders have you worked with at this point?

It's hundreds. So I've conducted, at this point, over 300 hands-on research sprints with them

What is a bullseye customer? And in particular, is there any difference from how most people think of the ICP, ideal customer profile?

a bullseye customer is the very specific subset of your target market who initially is most likely to adopt your product or service.

tends to be more specific even than they usually have gotten.

we've seen this as really key to accelerating teams.

To build to successfully, usually you have to be much more focused and much more specific.

it helps you prioritize, what are you building

it just gets everybody as a team much more aligned

And what especially love about your approach is you basically give people a plan for how to figure this out in a day, which sounds like a dream. What a dream come true. In a day, you can change the trajectory of your startup by getting very clear on who you're selling to and your bullseye customer.

So describe the sprint. So you have this Bullseye Customer Sprint that your book describes. And by the way, this book is freely available

The basic formula, the way I think about it, is five and three in one.
So it's five bullseye customers and three very simple prototypes, and then we conduct those interviews in one day while the whole team is watching and debriefing and thinking about what are the key big takeaways at the end of that, and so that's all as a team.

things that people may be surprised about, specifically, you don't need to talk to a ton of potential customers.

...Bullseye customer is that very specific subset of your target market who's initially most likely to adopt your product or service. So we want to recruit that group of people. And one of the reasons that we do that is if the whole team is in agreement, I have five people who match that, and everybody's like, "Yeah, yeah, those people

that way, after we do the interviews, depending on what the feedback is, they can't really dismiss it.

And it's fine if it didn't, if they didn't want it or they reacted in certain ways. That's what we wanted to learn

But upfront, we were able to identify and say, "Yes, yes. Those really we think are the right people." That's our hypothesis. So first is five bullseye customers.

The next part is about qualitative interviews.
So there are lots and lots of different kinds of research methods, but what I've found over doing this for many years is that the biggest bang for your buck is doing these kind of deep qualitative interviews where I can dig in and understand people's stories, understand their motivations, understand past experiences..."

Having the whole team watch that and understand and build that kind of empathy and understanding and hear those stories is very powerful.

Ideally, it's in that one day, so I bang out five one-hour interviews in one day while the whole team's watching.

At the end of the day, it's just really clear what were the big takeaways

just doing five of them, you hit what's called data saturation.
This is the thing in qualitative research where the common version of this is everybody, after four or five, is like, "Oh, for God's sakes, please don't let me sit through any more of these. I get it. I'm hearing the same things over and over. I understand.
Let's move on and do something different, change the customer, change the prototypes, whatever."

qualitative interviews in small clumps, and then we compare prototypes. And so this kind of comes from that time I had at Walmart where I sort of see the whole world as a shopping process

You don't look at just one thing. If I showed you just one thing

So then I can compare and contrast across these different possibilities, these different distinct value propositions. And I'm not looking for a winner but this comparison.

The other big benefit of having multiple prototypes is it helps teams avoid getting too wed to one specific idea

this pushes teams to think of new, different possibilities

the other thing is making this a team sport. The watch parties are a key example of this. And I'm livestreaming it, so the whole team is all watching it these days. Typically, people are pretty distributed, so I'm doing it over Zoom and they're watching the livestream independently. And then one of my partners, so Kate Aronowitz or Vanessa Cho, got amazing design partners I get to work with, are often facilitating that back room (back-channel).

But the magic of all watching it and processing it and discussing it and debating it through the course of the day is that everybody is aligned. We've all seen it. I don't write a report.
I haven't written a report in 10 years.

the team has captured it. We do it through Google Form, it shows up in the spreadsheet, and we kind of discuss it.

sometimes the next thing is do this again and adjust so we can build more confidence.

Before we get into each step, when do you recommend people do this?
When in the stage of a journey? Can you do it many times? Any just context there before we dive in?

So it's usually before you build something, maybe if you're expanding into a new group of customers.

Another common time is when you're selling but something's not going quite as well as maybe you hoped it was going. You've already launched and you want to just kind of troubleshoot, like, "What's going on?
We have some traction, maybe, but it's not what we wanted,"

I believe there's six core steps to the process.
What's step one?

So step one is what I do is I plan about a 45-minute meeting with the team.
We ask "What keeps you up at night?"

Step two is, based on what you want to learn, now let's figure out who is the bullseye customer that we need to talk to to answer that question.

if the question is about, let's say, big questions about onboarding, well, if the questions are about onboarding flow, then you're going to want to talk to new customers

Whereas if you're talking about something that's a new feature that's already in your product, then you'd be talking to existing customers

And then based on that, what I do is run what I call a bullseye exercise. So it's, again, essentially another kind of interview. Get the team together, and I pepper them with a lot of questions to figure out exactly who is this bullseye customer that we've been talking about.

Lenny Rachitsky: And to follow that thread real quick, I imagine people's natural inclination is not to narrow it too much.

Andy Johns, on a newsletter post I wrote once, he described it as, "It should feel comically narrow."

And there are times that teams will just be like, "Oh, for God's sakes, Margolis, this is too much."
The reason that I do that is I'm pushing them to identify a person who they all would agree, "This person, if we present this value prop that we think we're going to build and this problem we think we're solving, we are all convinced... Or it's our best guess." It's fine if you're not sure, but, "We are pretty convinced that that's the person who will say, 'Yeah, I need this thing.'"

But we go through this, and by the time after we've done these interviews, the goal is to figure out, "Was this right or not? Or in what ways do we need to adjust?" That's a big piece of the outcome, is adjusting that definition of your bullseye customer.

I was working with a company that was developing a new delivery service for people who have specialty prescriptions, medications.
So these are the kinds of medications that are expensive and for very specialized chronic diseases. This is not the kind of thing you're getting at Rite Aid. And there's something very special about this company, and then I can mention that afterwards. But the fundamental thing for them to figure out was, before they can build out the logistics of this, they're trying to figure out, "Do we need to target something that is for delivery like ASAP?"

We want to know, what's really the fundamental issue or problem that we're solving here?

• What are examples of other products that somebody has used that would make them more likely? So a good example there is, have you had other things delivered? Food?
• So they've probably used Uber Eats or something like that, and they've been on the medication for a certain amount of time. So it's somebody who, this is kind of a chronic thing. It's not like a one-off acute situation.
• somebody who was responsible for their own medications.
• I don't want somebody who knows too much.

So we went through and did this and then generated these different prototypes to express a range of different recipes of value props and what this might be.

So the range is things from, it can be delivered in an hour or it can be delivered over a four-hour window, or it can be delivered, "We'll get it there as soon as we can get it there, but we're not quite sure when it'll be coming. You just have to be home and available," these kinds of things.

It turned out having that distinct window, a predictable, narrow window of when this was going to arrive was much, much important than ASAP.

...that the scenarios where that was critical was things like, it's a refrigerated medication. This can't be sitting out on my stoop, right? It's cold chain. Or there's for some reason an issue where I'm especially worried about theft or something because of what the medication is or where I'm living or weather. So there are these very particular scenarios. So then going back to this idea of the bulls-eye customer, you realize, "Oh, wait, so it's a subset of customers who have refrigerated meds.

I avoid the phrase product-market fit with this stuff, and we can talk about that because I think that's kind of interesting.

I was recently speaking to a founder whom I'm doing another round of this with a new set of concepts. We had done a project a while ago and actually killed the project.

The other thing that he's mentioned to me was that through going through the process, he learned what No looked like.
So he could see, "Oh, I'm getting kind of this neutral, positive, encouraging feedback." And as we did this, he realized like, "Oh, they don't want this."

This is another reminder why it's so important to go so narrow, because if you can't find anyone that is thrilled this exists, you're in trouble. This is your chance to find the most thrilled people, the most specifically pained, and if you can't find that, that's a problem.

In the same way, we define this bullseye, and then when I go recruit and try to find them, if I can't find them, I usually take that as a sign of something also. I'm like, "I don't know if these people exist.... if, in fact, I just can't find these people, these people that you're imagining exist who want this thing, I'm not sure how you're going to sell to them."

The way I think about it is kind of in these three groups. So there are inclusion criteria, there are exclusion criteria, and then what we found very important are triggers.

Triggers are specific events or situations that somebody's been in that makes them particularly ready or ripe for the solution. So sometimes the way that looks, sometimes the examples of that can be you're selling a new cybersecurity platform for something and there's a new CSO has come in.

Or something's gone wrong, right? Somebody's in a situation where something's gone sideways and they need a new solution for that kind of thing.

an insurance tech company and they were targeting millennials

The trigger was, "Oh, you just had a baby?" or "You just got married?" And now people are like, "Oh, this is actually on my to-do list. I need to go get this done."

Once I have that set of criteria (~7 attributes) and the team is all aligned and agreed on what that is, they're like, "Yeah, yeah, those are our people," so then I start thinking about how I recruit them.
So to do that, for most people, unless I'm looking for something that's very, very specialized or hard to find, what I do is I create a screener questionnaire.
So I translate these criteria into, essentially, a set of questions that will help me filter out people, to know, if people respond to this questionnaire, who are the bullseyes in there?
And so part of the trick there is to write a questionnaire in a way that I'm not telegraphing the right answers.

one of the key things in those bullseye criteria are that they're very concrete and very measurable things. It's not just, "Oh, this person is an active shopper."

So then I'm writing this questionnaire. And typically, what I do is I rely pretty heavily actually on UserInterviews.com.

So the times I get like 400 responses, basically download it into a spreadsheet and just start sifting through.

The caveat there is there are times when you need to talk to somebody who's just very hard to find or hard... They're not going to be on UserInterviews. So I've done a lot of work in the past with oncologists, with Flatiron Health. Oncologists are not on UserInterviews. They don't care about my $125.
They're busy doing something more important. And so if I'm doing that, I need to find a different way to approach that.

If you're building a product for oncologists, you hopefully probably have some contacts with oncologists, and you can kind of work through their network, find one person, they can recommend another person.
You still want to filter them and make sure that they are matching your core criteria, but it requires different kinds of techniques to find those kinds of folks

Lenny: Linear.app, their focus was two to five-person startups using GitHub and Google Auth at a founder-driven product company.
Michael: See, what's interesting to me about those is that I would go even deeper and more specific.*

some of those, you want very concrete, measurable things to be able to tease apart like, "Well, how founder-led are... How are you behaving? What other products are you using in your stack that this fits or doesn't fit?" These kinds of things

you get more narrow to do this research, but that's not your actual ICP.

The bullseye customer is for research to help you identify a broader ICP, your business targets.

this is a learning exercise.

obviously, you can learn a ton from selling and pitching and meeting with companies and potential people who seem like maybe they are customers. But that mode is very, very different from what I'm describing

term that I love that Ed Schein coined, which is humble inquiry.

I encountered this over and over with heads of product and founders, is that if you're... They're very good at, and they're very used to, and they're required to just sell all the time.
And they're pitching their VCs, they're pitching their customers, but that's very different from learning and being... In humble inquiry, you basically have to be vulnerable.

I'm not the founder, and I've always present myself as like, "I don't know the space. I'm an idiot. Can you explain it to me?"
But asking questions and being vulnerable and giving the person you're asking the higher status is a difficult thing to do as a founder when you're selling, because you don't want to be vulnerable and express that you don't know.

You have to make sure they show up, make sure you're compensating them sufficiently. This is something where I'm not giving $20 Starbucks cards, because somebody's going to blow you off. When I have those five sessions and the whole team queued up to watch, I want people to show up.

I'm paying for most typical kind of consumer things, like 125 bucks an hour for them to show up and do this, so it's worth spending the money. Recently did something where I was talking to attorneys. I was paying their hourly rate.
I was paying like 400 bucks an hour for them to show up, but I need them to show up.

So then the next step is to figure out your prototypes. And so what I want to do with those is I want to create, again, these three distinct examples, three distinct recipes of the possible features and distinct variables that we want to present in these interviews.

ideally, I can find a competitor's products and use those as free prototypes. I love doing that

So there are certain features and then certain variables across, that I kind of imagine spread across these different things

So we're developing this range and then creating these prototypes that are very simple. They're just PDFs, really. Very flat, there's no functionality. A lot of it is really a writing exercise to articulate, what's the distinct value prop and what's the brand promise and the problem you're solving for each of these prototypes?
So you want to make it look as real as possible, so it looks like a home page for the product, right?

But they need to stand alone.
I'm not going to pitch them or narrate to them, and just create those so that I can present those three distinct recipes.

And these calls are usually over Zoom

Rachitsky: Sweet. More and more on this podcast, people are sharing ways how AI is making prototypes, actual product prototypes so much easier to create, so I imagine people are going to move to functional prototypes more and more.

Michael: Yeah, they may. I think the thing that's important is to not get distracted by that

..about the value prop, it's about making sure that they understand what it is. It's not this kind of marketing speak where you're like, "Wait, what?" You just have to be super blunt. "This is what it is and why this is awesome and why this one is awesome," and then they're shopping.

And I design them enough that they look different from each other.

So the green one versus the blue one versus the red one, right? So then when the observers can keep track.

you have to draft your interview guide

Each interview is a two-part interview.
So the first part of the interview is this discovery interview where I'm asking people about their existing and past experiences and attitudes and opinions about whatever this part of their life is. "How did you previously get your medications delivered? What worked? What didn't work? Tell me about a time when it totally went sideways. Tell me about a time it worked perfectly." So we go through that and have that. About halfway through that interview, I shift to comparing and contrasting these prototypes.

By doing the first half where I've had the discovery conversation, it gives me a huge amount of context to understand their feedback about the prototypes, because there will be times when they'll say things or tell us something, and because we heard the first part... They'll tell us something about the prototype, and because of what we heard in the first part, we'll understand why.

it's enough for them to then sort of step back and not pick a winner, but be able to say, "Oh, I like this aspect of this one.
I like the fact that this one's being delivered by a pharmacist, but I really prefer that this other one is a 15-minute window,"

I want to grab the best bits and pieces, the best Lego pieces, so I can then go construct the ideal version next

the next step is the final step, which is the watch party where you actually do this.

I'm conducting the interview. I'm off on Zoom, one-on-one conducting these interviews. In the watch party, Vanessa Cho, Kate Aronowitz, my amazing design partners, often are facilitating the group there. And so what they're having the team do is take notes and go through these debrief sessions in between each interview.

I have it set up so it's livestreaming to them. So they're not in my Zoom.
It's not like 20 of us with a bunch of heads watching the person. It's really important to me that it's just me and the customer that I'm talking to directly. So they're all livestreaming it. They're taking notes, so they're in a Google Doc.

people are assigned roles, so take turns taking notes, because it's pretty intense

And then there's also a Slack channel, usually, in the background, because there's a lot of other chatter, like, "Wait, what did they say? They're talking about this.

Vanessa or Kate also monitors that, so that's the way that somebody can pass me notes to ask specific other questions. I can't do the interview and track the notes and Slack. My brain can't handle that.
So they're in there, and then I have a chat window open just with Kate or Vanessa, and so they'll pop me questions as they come up.

This debrief is in a spreadsheet that I've set up so that there are key things that we wanted to learn.
Those are not the questions that I'm asking in the interview, but they're the things, again, these key questions that we wanted to learn, which is different from what I'm asking. And so we're just capturing in that half hour, the decider, whoever owns the product or the founder is leading that because they're the decider.
And they're leading, getting input from everybody and filling in and answering those questions

first column is that set of questions, so those are the rows of the questions, and then each participant is another column. So

The decider kind of goes through it and talks about, "What are the key patterns? What are the things that we've learned here as a team?" And there's this remarkable amount, usually, of consensus, of alignment about, "What is this? What do we need to do next?".... What I love seeing is that, quite frankly, one of the most common things across all of these businesses, all these sites, all these studies, is that one of the things that people say we need to do next is more research.
Even though these are all teams who've said, "We talk to our customers all the time," we go through this and they're always like, "Oh, yeah, this looks really different than what we were doing. We didn't know this stuff."

we do this thing before the watch party where we get everybody predict what they think they're going to learn.

we have to push people to be specific. It's not, "Oh, we'll find out what they think of our concept."
Yeah, yeah, I know we're going to learn that, but what do you actually think is going to be the outcome

after we go through the big takeaways at the end of the whole study, it's very valuable to go back and say, "How does what we learned compare to what you thought?"

There's certain patterns that I've noticed that show up over and over about mispredictions

I can attribute it to this, there's this concept of the curse of knowledge. So I'm working with lots of teams who are deep experts in their space.

when somebody has deep expertise, it's very difficult to imagine that other people don't know what you know.

there's an overestimation of how much your customer knows about the thing, maybe how big a problem they even perceive it to be, how much they're willing to pay for it, which is connected, and where they are on their journey to be ready to buy this thing.

the watch party, that I would make sure... The team needs to be there, and they need to show up for all of it.

whole team, like all the engineers, designers?

at a maximum, we had 40 people show up. That's still our record, which is awesome. The more, the merrier.
I want the whole team to see this, because part of the shortcut of the watch party is I'm not doing a report. I don't need to go persuade or explain people what happened. You all saw it and we went through it together, and everybody's aligned and gets what's happened.

The time that it doesn't work as well. There are times I get through, and you're just like, "Ugh, that just didn't work well." It's because, for one reason or another, we did not select specifically, we didn't recruit specifically enough and weren't picky enough about bullseye customers.

Which comes back to where we started, just seven attributes

Through going through this process, what I want to do is get to a point where a team can narrow down to a point where, actually, there's one or two attributes that you realize later, that's the thing.

You figure out that's the distinguishing characteristic, and so now if I have some giant funnel or a set of leads or all these things I need to prioritize, I can streamline all this other sales motion or something else that I'm doing.
I'm like, "We'll expand it, but for now, that's how I'm going to prioritize people.

This reminds me of, actually, with Linear.app, something smart they did is they had a wait list when they first launched, and the wait list was their questionnaire. What do you call it? The screener. So basically, the wait list was a screener survey. It's like, "What do you use for auth? What do you use for hosting your code?" And then they pick those people that most match what they actually can do that day.

I do these two part interviews. So that first part is having people describe and explain past experiences, what they've done, what's important to them, et cetera.
I put much more weight in that as building the trajectory of, what will this person accept or value or avoid, what do they think are barriers, to then showing a prototype. They're like, "Oh, I would totally do this."
And you're like, "That does not sound at all consistent with what you just described to me, so I'm going to be somewhat skeptical of your prediction of what you would do or what you think might happen." It's not about the customer.

You do a bunch of this and you'll know. And if you don't know, you're like, "It's probably a no."

One thing I've been thinking about and recently getting to experiment with, which I'm pretty excited about, is how to apply these methods in biotech.

nobody's calling me when they're doing science. They don't need that help.
They get to a point where there is some productization of it. You need to figure out like, "Oh, actually, how is this going to fit into a physician's workflow? How will patients react to this relative to some other possible treatment or other things that are out there?

I talk to people who come from that tradition, I don't know what else to describe it, is they're doing similar work, but they don't seem to describe themselves as product managers. They have other kinds of titles.
They come from like patient education, they have these other titles, but they're doing similar kinds of work