Identify your bullseye customer in one day | Michael Margolis (UX Research Partner at Google Ventures)
Guests: Michael Margolis
Full transcript · Read the full conversation in order, with its original context.
§01Transcript · 00:00–34:29
You have done 30 years of work and iteration and refinement.
You're here just to tell us, "Here's the most important thing you need to know and here's how to do it, based on all that time I've spent."
Help us understand, what is a bullseye customer?
Every ambitious founder wants to build a product for everybody, but it doesn't start there.
Amazon started just selling books, or Facebook was just profiles for college students.
So a bullseye customer is the very specific subset of your target market who initially is most likely to adopt your product or service.
Why this of all the things that you can focus on of a startup journey?
It helps you get really deep in understanding who are those people and understanding what they need.
It helps you prioritize the feedback you're getting, and it just gets everybody as a team much more aligned on, "What are we doing, and what are we doing first?"
You have this Bullseye Customer Sprint that your book describes.
You basically give people a plan for how to figure this out in a day, which sounds like a dream.
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 kind of thinking about what are the key big takeaways at the end of that.
Where do you start?
So step one is...
Today, my guest is Michael Margolis.
Michael has been a UX researcher at Google Ventures for almost 15 years, where he's worked with over 300 companies to help them get unstuck, move faster and build something that people want.
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, 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.
Michael is not looking to sell books or drive leads to Google Ventures.
He genuinely simply wants people to avoid pain and avoid wasting time building something that nobody needs.
In this episode, we go step-by-step for how to identify your bullseye customer, how to interview people, how to recruit people, and how to refine your idea to build something that people actually want.
This episode is both for founders and also for product teams at larger companies who want to avoid building something that nobody cares about.
If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube.
It's the best way to avoid missing feature episodes, and it helps the podcast tremendously.
With that, I bring you Michael Margolis.
Michael, thank you so much for being here and welcome to the podcast.
Thank you so much.
I'm thrilled to be here.
So we're going to be going really, really deep on how to very clearly and also just very quickly identify your bullseye customer, which some people refer to as ideal customer profile or ICP.
There's differences there.
We're going to touch on that.
But you wrote a whole book about this very specific topic.
I have it right here.
It's called Learn More Faster, and the subtitle is important, How to Find Your Bullseye Customer and Find Their Perfect Product.
And interestingly, this topic has actually come up a bunch on recent podcast episodes, so I've been telling guests, "Hey, we're going to have a whole podcast episode about this very specific topic, which I'm very excited about."
So Michael, again, thank you for being here.
Thank you a ton.
This episode is brought to you by Eppo.
Eppo is a next-generation A/B testing and feature management platform built by alums of Airbnb and Snowflake for modern growth teams.
Companies like Twitch, Miro, ClickUp and DraftKings rely on Eppo to power their experiments.
Experimentation is increasingly essential for driving growth and for understanding the performance of new features, and Eppo helps you increase experimentation velocity while unlocking rigorous, deep analysis in a way that no other commercial tool does.
When I was at Airbnb, one of the things that I loved most was our experimentation platform where I could set up experiments easily, troubleshoot issues, and analyze performance all on my own.
Eppo does all that and more, with advanced statistical methods that can help you shave weeks off experiment time and accessible UI for diving deeper into performance and out-of-the-box reporting that helps you avoid annoying, prolonged analytic cycles.
Eppo also makes it easy for you to share experiment insight with your team, sparking new ideas for the A/B testing flywheel.
Eppo powers experimentation across every use case, including product, growth, machine learning, monetization, and email marketing.
Check out Eppo at geteppo.com/lenny and 10x your experiment velocity.
That's get E-P-P-O .com/lenny.
This episode is brought to you by Paragon, the developer platform for building native customer-facing integrations with third-party apps.
Are native integrations on your product roadmap?
Whether it's to ingest context from your users' external data and documents or to sync data and automate tasks across your users' other apps, integrations are mission-critical for B2B software products today.
But building these integrations in-house costs an average of three months of engineering, according to the 2024 State of Integrations survey, which results in difficult roadmap tradeoffs.
This is why engineering teams at Copy.ai, AI21 and over 100 other B2B SaaS companies use Paragon, so they can focus their efforts on core product features, not integrations.
The result?
They've shipped integrations seven times faster, all while avoiding the never-ending maintenance that comes with rolling your own integrations.
Visit useparagon.com/lenny to see how Paragon can help you accelerate your product's integration roadmap today, and get $1,000 in credit on their Pro and Enterprise plans.
That's use P-A-R-A-G-O-N .com.
I want to start with giving you a chance to just share the work that you have done over your career that this framework and process is rooted in, because it's based on a lot of hands-on work with startups and founders.
So just talk about the work that you have done that has led you to this process and framework.
Yeah, so I've been doing this kind of product and UX work for over 30 years.
So the work that I'm going to describe here is kind of the culmination or the synthesis of about 30-plus years of that.
There are a lot of different pieces that I've picked up along the way and recombined and adapted for this.
So 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.
So going from there to Walmart.com was really learning to take those techniques and compress them and accelerate them.
Walmart is really all about execution, about scale, about everyday low cost and speed, and so I had to really compress those techniques and make them much, much faster and learn to combine deep ethnographic discovery work with usability work, and getting lots and lots of reps.
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.
One of the things we did a lot there was, the way I would do the research is with watch parties, so teams would be able to see it.
Google had invested in lots of video conferencing, streaming from the labs, one-way mirrors, a lot of things early on, so the teams were involved and they were seeing and watching this stuff.
So a lot of those techniques I brought then to GV, to Google Ventures, when I joined in 2010.
So I was the first UX research partner in venture capital at the time.
Still, I think maybe there was one other person in this role.
And so took a lot of those techniques and recombined them and have adapted them and experimented over the last 14 years, working with hundreds of different kinds of startups.
We have a very broad variety of founders and product people that we're working with.
So over the past 14 years, we've really gotten to experiment and gotten to work with them and be kind of a small piece of the journey that they're on to learn and answer these fundamental questions that they have about their products and their people.
How many companies/founders have you worked with at this point, just to give people a sense of the scale?
It's hundreds.
So I've conducted, at this point, over 300 hands-on research sprints with them.
We also work with many, many others where we're just doing tons of office hours.
Just to give you a sense, it's anything from biotech to healthcare to security, food.
I've worked with farmers.
It's really all over the place.
What I love about this podcast and guests like you is you have done 30 years of work and iteration and refinement, and then you're here just to tell us, "Here's the most important thing you need to know, and here's how to do it, based on all that time I've spent."
Perfect.
What ROI we're providing here.
Okay, so your book and your process is about finding a bullseye customer.
Help us understand, what is a bullseye customer?
And in particular, is there any difference from how most people think of the ICP, ideal customer profile?
So a bullseye customer is the very specific subset of your target market who initially is most likely to adopt your product or service.
And so compared to when we talk to founders about their ICP or the personas that they come with, this tends to be more specific even than they usually have gotten.
And the reason that this concept of bullseye customer has become so important to us is we've seen this as really key to accelerating teams.
Every ambitious founder wants to build a product for everybody, and we're investors.
So at GV, we want them to be successful and to have these huge markets, but it doesn't start there.
To build to successfully, usually you have to be much more focused and much more specific.
So you can look at lots of companies, right?
Amazon started just selling books or Facebook was just profiles for college students, et cetera, et cetera.
So helping founders be very specific about who are you going to start with, who is that very distinct group that is most likely initially to adopt, helps streamline a huge number of things.
So it helps you prioritize, what are you building?
It helps you get really deep in understanding who are those people and understanding what they need.
It helps you prioritize the feedback you're getting.
You're often getting just a ton of input from investors, from friends and family if you're talking to them, from lots of people who kind of seem like they're in your target market, but it helps you kind of win away some of that stuff and be like, "Which parts of this are important?
We'll get to you.
It's not that we're not going to eventually serve you, but initially, here's where we're going to focus."
And it just gets everybody as a team much more aligned on, "What are we doing, and what are we doing first?"
I love that the incentives, as you just referred to, of a VC like Google Ventures are so aligned with, help figure out what most will help a startup.
I love that this is a good filter for, what have you seen most cause trouble for an early-stage startup?
And it's interesting that this is where you ended up going.
Let's spend a little more time here in just why the bullseye customer/ICP is so important.
Why is this the thing, of all the things that you guys have seen along the early stage of a startup journey, you have decided, "This is where we need to focus and help people"?
Having them focus on the bullseye customer is a way to help them focus and prioritize what they're thinking about building, what the questions are that they're asking, and who it is that they need to target and build for.
And so all of those things, once we can help them narrow that down and decide, "Who are we really focused on and who are we setting aside until later?"
it helps them prioritize their roadmap, it helps them prioritize the feedback that they're getting and gets the whole team aligned and moving together much faster.
Yeah, it makes sense.
Basically, everything trickles down from who the heck are you selling to, because it's the pains you're selling for them.
How do you find them?
So I love that, and I totally agree.
And again, this has come up a bunch on recent podcast episodes, just how essential this is and how underappreciated this often is.
The other thing I love about what you're describing is you're focused on speed.
I love that as you move through your career, it's like, "How do we do this faster and faster?"
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.
Awesome.
Let's start getting into it.
So describe the sprint.
So you have this Bullseye Customer Sprint that your book describes.
And by the way, this book is freely available.
You can download the PDF.
We're not trying to sell books here.
This is just like, use this.
You'll be better off.
Yeah.
There's learnmorefaster.com, there's the book, there's all kinds of resources and templates.
Yeah.
Please, grab it.
Okay, cool.
So describe the sprint, high level, how it's laid out and the core pieces of it.
Yeah.
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.
And you mentioned a few of these key ingredients, and I think things that people may be surprised about, specifically, you don't need to talk to a ton of potential customers.
You build a number of prototypes, which is interesting, versus iterating on a single prototype.
And there's a few other elements.
So can you just share some of the key insights, the key unique ingredients to the sprint market experience?
Yeah.
So one is bullseye customer.
We talked about that, right?
Again, 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, those are the ones that if they saw this, we're pretty sure they'd be into this.
They'd want this.
We agree."
And so that way, after we do the interviews, depending on what the feedback is, they can't really dismiss it.
They're like, "Well, we all thought that..." 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, "Why did you do this in the past?
What have you done in the past?
What's worked?
What hasn't worked?"
Having the whole team watch that and understand and build that kind of empathy and understanding and hear those stories is very powerful.
But then we do those in small batches.
So rather than do an interview on Monday and then one on Wednesday and then a couple on Friday, we clump them.
Ideally, it's in that one day, so I bang out five one-hour interviews in one day while the whole team's watching.
Sometimes we do it across two days, depending on time zones and things like that, but the idea is that they're clumped together.
The reason for that is if you do them in a clump like that, then the patterns are just much more obvious.
At the end of the day, it's just really clear what were the big takeaways.
It's not going to answer every question that you ever had about your product or your customers.
But the big things that you set out to answer, it's pretty clear, like did it work?
Did it not work?
Which parts were good or bad?
All these kinds of things.
And the whole team has watched it, and so they have that sense.
And that idea of 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."
So 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.
And so there's something very valuable, just the way any of you have shopped for anything, right?
You don't look at just one thing.
If I showed you just one thing, you'd have some feedback and you'd have an opinion about it, like, "Let's shop for a couch.
I like the color.
The cushions are uncomfortable.
I like the fabric," or not.
And that's helpful and that's interesting to hear, but as you start looking at two or three, then you start having this different reference points.
And when you're testing with customers, it's not up to them to come up with these different possibilities of what could be, and so if I'm presenting those, they're like, "Oh, that's interesting.
I like the way this one has cushions that are made out of down, but this other one is really interesting because they deliver it.
Oh, but I like this because it's a style that I like and they actually take away my old couch."
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.
So you can get a little over-committed.
There's a risk that you get over-committed to one idea, you're polishing that, you're working on it, you're too committed to that.
And this pushes teams to think of new, different possibilities, and you can be a little bit more neutral and a little bit more objective if you're not all so bought into one thing.
So comparing prototypes becomes very powerful.
And then 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.
And so what they're doing is they're helping the team... We have a structured process for taking notes, and then in between each interview, they're debriefing.
So I have this spreadsheet that I use that's like, "These are the key things we wanted to get out of this."
And so they're going through and just capturing that, like, "What just happened in this interview?
Let's make sure we have the high level."
And at the end of the day, we have a way to all capture, like, "What were our big takeaways?
What happened?"
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, I don't know, 10 years, because at the end, when we capture those big takeaways, the team has captured it.
We do it through Google Form, it shows up in the spreadsheet, and we kind of discuss it.
And then everybody's just raring to go do the next thing.
Everybody's aligned, and there's this incredible amount of momentum from the team after that.
They're like, "Let's go do the next thing."
It's clear what we need to do and what we learned.
And sometimes the next thing is do this again and adjust so we can build more confidence.
But the make it a team sport has been this very powerful tool for building consensus, building alignment.
Especially as teams are growing and people are going to start up running in different directions, it's like a chance to come together and make sure, like, "Oh, where are we?
What are we doing?"
Awesome.
That was really helpful.
So just to summarize the key elements of this approach, there's a bullseye customer concept of just a very narrow people wedge, almost, of who would most want this thing, and we'll talk more about that, making it qualitative versus surveys or things like that, comparing prototypes, and making it a team sport.
Okay.
So we're going to actually go into more detail of each of these steps just so folks can... Basically, what I'm hoping to do is they... Folks listening to this can do this tomorrow or next week.
There's a little prep time.
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?
You can do it many times.
The key times to do it is... At a high level, it's before, hopefully, you've invested a lot of time into building something, a lot of energy and the team's energy and money that goes into the building.
So it's usually before you build something, maybe if you're expanding into a new group of customers, so you were killing it in the UK and now you're trying to get into the US market and that's different, or you worry it's different or you're not sure, it's a good time to check.
Or maybe you were selling to enterprise, you're doing very white-glove, high-touch sales to enterprise, and now you're going to shift down to maybe a different tier of customers and you're trying to set up some more of a self-serve kind of a sales motion.
You need to understand that.
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," or "We're getting that very polite, encouraging feedback, which sounds good, but it's really no.
Let's go dive in and find out."
So those are the big key things of the times of when to do it.
Okay, let's actually get into the steps. I believe there's six core steps to the process.
Okay.
Yeah.
Okay, cool.
Where do you start?
What's step one?
Yeah.
So step one is what I do is I plan about a 45-minute meeting with the team.
Again, it's really important to have that core team together and have this conversation about what are the key questions, basically, "What do you wish you would know about your product, about your customers?
What's getting in the way?"
One of the most common ways that we ask this is, basically, "What keeps you up at night?"
because founders and product people have... There's a bazillion things that they're kind of bubbling in their head, that they're worrying about.
But that often gets them to step back and be like, "Oh, what I'm really unsure is this.
What's going to happen?
How will people respond to this fundamental concept or this idea or how will they use it?"
I have a set of questions that I'll go through with them to help prompt and elicit, "What are those big things that you wish you knew?
What would have to be true for this to succeed?
What are your hypotheses and what are your assumptions about the product, about the customer?
Who do you think this is or not, and why?
What are those nagging debates on the team, those kinds of things that keep coming up over and over and you're like, 'Oh, for God's sakes, let's go get some information and answer the question'?"
It's some of these things.
So we have that initial meeting to kind of detail, what do we need to answer?
Awesome.
And this informs other... I imagine, all the things you do next.
And so in the PDF [inaudible 00:23:55] too, in the show notes, you can see all these questions and run through them yourself.
Okay, cool.
So that's step one.
What's step two?
So 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.
It all starts with those key questions that you have, because 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, somebody who's fresh to this to see, how do they get through or how do they understand what this is?
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.
So that's an example where if I understand what the questions are, I can kind of work backwards to understand, who do I need to talk to?
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.
And the reason I love doing this as a team is that what happens invariably is having that conversation before we've even gotten to any interviews is super clarifying for a team, because they tend to get a shorthand about who their customers are.
And this is a way... And I just keep asking questions, like, "Well, what do you mean by that?
So when you say you're building a delivery service for people who get specialty medications delivered, specialty prescription medications, who exactly is that?
It's not everybody."
And so we start narrowing it down.
So they start having those conversations, debates, arguments about who it is, and just having that is really clarifying for the team.
Like, "Oh, well, I hadn't thought about that.
Yeah, I guess it's true.
Maybe it's not everybody who has that.
It's only people who have this kind of condition or this set of conditions or these needs."
And to follow that thread real quick, I imagine people's natural inclination is not to narrow it too much, because there's always like, "Why would we exclude this big market opportunity?
Why would it have to be so narrow?"
Can you just speak a little bit to just why it's so important to get very, very narrow?
Andy Johns, on a newsletter post I wrote once, he described it as, "It should feel comically narrow."
Does that resonate?
I love that.
Yeah, I hadn't heard that phrase, but I love that.
Yeah, comically narrow is exactly what it is.
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.'"
I'm kind of running an experiment, right?
It's a way to reduce variables for me and then to get that specific, and then I recruit a bunch of the people who match that very particular set of characteristics.
And they're people, so there's still some variation, but it's a way for us to test that.
If there's too much variation, then what happens?
At the end of the day, you're like, "That was kind of a mush.
I'm not really sure what we learned.
Was it because it was just people had mixed feelings or was it because there was just not enough consistency?
We had too many variables in there.
I don't know what we learned here."
So I think what's nice about this is this initial list you're making of bullseye potential customers and attributes is not exactly going to be who you go after.
Once you figure this out, you want to be very confident these group will absolutely love what you're presenting, because you're trying to learn as much as you can from the people that most love it.
And then from that, you can get a little less narrow to actually pitch your product.
Right.
And most often what happens is we do this, we define it our best, right?
It's our hypothesis.
It's our best guess.
The team is always very expert.
I'm not.
I'm always showing up as the noob in whatever this business is.
The team is expert, and so this is very informed.
It's not like we're guessing.
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.
And often what happens is through the course of that Bullseye Customer Sprint, you learn, "Oh, it turns out there's actually this other distinguishing characteristic we didn't realize, or maybe it validates what we knew."
But often, "We didn't quite realize that.
This other thing is popping up where we're seeing heat from people.
Oh, wow, that's interesting.
Let's dive in a little more."
I mean, I can walk through an example if you want.
Yeah, that'd be awesome.
Then-
[inaudible 00:29:03].
Yeah, yeah.
And I think even just like, what are some examples of attributes?
What's the list of attributes you should be thinking about?
Let me just give you an example.
I think a lot of this stuff we're talking about, it starts to get a little abstract.
So 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?"
These are really important medications for very serious diseases.
Is it like, "Oh, my gosh, I need the next pill.
Get it to me as fast as you can"?
Or is it like, "Well, I can wait till a day or two, but I need it between 2:00 and 2:15 PM," like if I knew that?
And then who exactly is this bullseye customer?
We want to know, what's really the fundamental issue or problem that we're solving here?
And so they wanted to answer those questions.
And so we go through this process, and so those are the key questions.
And then the customers that they're after, I know, okay, well, it's not going to be everybody with specialty medications.
And so as we start teasing through that and thinking about it, I want to think about, 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?
Have you gone through this kind of process before where you've used like Uber Eats?
Because if you have never had anything delivered like that before, that's going to be too many humps to get over to get the person to accept their medications coming by delivery.
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.
They needed to find people who had a certain kind of density, so how rural were they living, how urban was it, because of the way they were going to do the deliveries, somebody who was responsible for their own medications.
So we don't want somebody who's in some kind of a healthcare setting where somebody else is taking care of it, or maybe their spouse or partner is managing their prescriptions.
These are the kinds of things that we're starting to look for.
And another typical exclusion criteria is I don't want somebody who knows too much.
Your core bullseye customer, I want somebody who's pretty typical.
So in this case, if I were to find out that somebody was a pharmacist or worked in healthcare, they're like, "Oh, yeah, that's probably not a typical customer.
If I just have these five precious interview slots, I probably don't want that, so I'm going to exclude those people."
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.
So went through this exercise, and what rose to the surface as we were doing these is that there were certain customers for whom this was a much, much bigger issue, for whom they needed to be there and know when this thing was showing up.
It turned out having that distinct window, a predictable, narrow window of when this was going to arrive was much, much important than ASAP.
These are important medications.
They're not waiting until the last pill is gone.
That's not what's happening here.
But knowing when it was arriving... And it turned out 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.
That seems like a much higher value problem that we're solving here."
And so we ended up running this again.
So I re-recruited with people who had that subset of kinds of medications and issues and also were dissatisfied with the status quo of their existing service and were not available to just kind of be around.
So they were busy and whatever, and they needed this window.
So we ran it again.
We were like, "Oh, yeah, there it is."
So that second group of people, you just start building this confidence in the match between what you're building, what the problem is you're solving, and who exactly you're building it for.
And in that case, you could see, "Oh, yeah, that is the right bullseye.
That's why there's this very narrow, specific group who's much more likely to adopt this than everybody who has specialty medications, because the need is just much more acute."
I love this example.
Intuitively, it all just makes sense as you describe what you landed on.
§02Transcript · 34:29–1:04:29
And this is what people call product-market fit, what you're describing, where somebody has a pain that you are solving and they need it badly.
What does it look like when you find that group of... What do you notice qualitatively, just like this tells you this is it, this is the pole that people talk about when you say product-market fit?
I avoid the phrase product-market fit with this stuff, and we can talk about that because I think that's kind of interesting.
When you find this match, what happens in the qualitative interviews is that you can sense the energy and the excitement and the enthusiasm.
It comes across.
Especially as you do a bunch of these, you can tell.
There's a difference.
And so that's what you're looking for, is people who are then like, "Wait, is this available?
Is this a thing?
Can I sign up for this?"
It's that kind of thing, or they're really leaning into it and you qualitatively can just see it.
One of the things I thought was very interesting was 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.
So through going through Bullseye Customer Sprint with something that he was doing, we did three rounds of it, and finally, he was like, "Yeah, this is not... I'm going to focus on the other part of my business."
And he said, "We killed the project."
And what he told me was two things that were really interesting to me.
One was, "This saved me a huge amount of pain."
We ran through this, we had to do some work to the Bullseye Customer Sprint, but the product that he was going to build, it was hardware, it was software, it was this whole subscription model.
It was going to be a big, complicated thing to build.
We had mocked up a bunch of prototypes and I'd used some free prototypes when we interviewed.
It killed the project.
That was super valuable to him.
He saved a huge amount of time and effort.
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."
Right.
It's not that big of a deal to them.
It's not that.
And it was by doing this, and you see it enough times, and he felt like that was one of the most valuable outcomes for him, is like, "Now I know what no looks like."
That makes so much sense.
It feels like that's almost... You could almost argue that's the biggest value of this, is just avoid wasting time building something nobody wants.
Totally.
And as a researcher and as a VC, if I can save a company and a founder and a product team from going down some path or too far down a path, that's huge for everybody.
They have so much energy to go do the other thing.
And again, 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.
Yeah.
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."
And it could be... Sometimes they're like, "Well, we went too narrow."
I'm like, "Okay, well, let's go back and we'll see which of these are flexible.
How do we soften some of these requirements?
But 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."
Not that I'm the final arbiter of whether these people exist, but it's something you should go check.
Yeah.
Okay.
So to give people a little bit of a framework of how to help them identify these narrow set of attributes, share some of a list attributes to think about to help them narrow.
And how many narrowing attributes would you recommend?
Is it roughly, heuristically, is it like three?
Is it five?
Is it seven?
It probably gets down to... Yeah, it's more like seven.
I mean, that's roughly.
It depends.
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.
So by inclusion criteria, this is usually pretty easy because the team is like, "Yeah, these are the people we want in the group.
It's people who are taking specialty medications for these particular conditions.
We can build that out."
The exclusion criteria I find is a place to dwell and help a company really think that through a bit more, to brainstorm that, because as we talked about, it's harder for teams to set people aside, right?
And so it's thinking about, what are reasons why somebody maybe is not the best customer here, not yet?
And that could be things that we talked about was maybe they have too much expert knowledge here.
They're not really a typical person.
That's not who I want to talk to.
Maybe they're using a competitive product and they're already locked into that.
I don't need to talk to them.
Or they've had some other personal past experience that's going to just make them not a good candidate, like I'm working on FinTech and this person is in bankruptcy or has had identity stolen.
I want to help them, but that's not our first place to start.
So these exclusion criteria are critical, and then these 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.
There's a new sheriff in town, and they're looking to revamp things and rethink, and so it's a time when somebody's open to considering new options.
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.
Or we were working for an insurance tech company and they were targeting millennials.
So the idea was the people who were in this particular demographic, in this time of life, they would be buying life insurance.
And what we found was everybody was saying, "Well, we should buy life... Yeah, it's one of those things.
I should take care of that.
Yeah, I should take care of that.
Oh, yeah, I really need to get life insurance."
But people who had... 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."
And so I'm in a completely different mindset, that's the person who now is your bullseye.
It's an example of a trigger that somebody's like, "Oh, yeah, now I need to go do this thing."
Awesome.
I know in the jobs-to-be-done framework, there's a term for that that's like it kicks off the vector to get them to do something.
I forget, there's term in that framework.
So I have your book up in my hands right now, and I'm looking at the list of attributes and questions that you ask to help narrow down.
So let me just read this, because I think it might be helpful just people to hear, like if I'm trying to narrow, how do I narrow them?
So it's like, are they new or an existing user of your product?
What sector or industry are they in?
What's the size of their organization?
Have they used a competitive product?
Is there disqualifying personal experiences, as you described?
Is there disqualifying professional experiences?
What's their title, role and responsibility?
What's their geography?
Are they the buyer or the end user?
Are they distributed?
How is their team organized?
Their budget and income, their life and work settings, trigger events, as you described.
Are they a VIP?
What is that one, real quick?
Yeah.
So I was having this conversation yesterday with a company.
Oh, cool.
I met with them, and so what I asked them was, "What makes one customer or another more valuable to you?"
Oh, okay.
Yep.
Got it.
So it's like, are they especially important?
Yeah.
Is there something about... For them, it was this really interesting, again, way to start thinking about distinguishing characteristics.
Like, "Yeah, what is a valuable customer to us?"
They're at an early stage and they were attracting a lot of people and different kinds of personas, and they're trying to figure out, what's the pattern here?
Who matters more to you or not?
Awesome. So basically, you answer all these questions, you see which of the seven-ish attributes seem to be most right, and that's your bullseye customer that you start with.
Right.
Awesome.
Okay.
Should we move on to the next step?
Sure.
Let's do it.
What comes next?
So once I have that set of criteria 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, and so that I kind of am in the control seat so I can pick out and identify the people.
What I mean by that is if I were to say, "I will pay $125 to anybody who is a product manager who listens to Lenny's podcast," and all of a sudden, I'm going to get a bazillion people who are just like, "I will take that $125."
I'm like, "Well, I don't know, do you actually listen to the podcast?
I don't know.
Hopefully you do.
Everybody does."
But if I can ask the question in a different way in terms of, "What are some of the podcasts you listen to?
What are the kinds of people you follow?"
these kinds of things, and then see, where does that show up?
Or even ask it as an open-ended question, like, "Where do you get your most trusted information as a product manager?"
and start to see and then be able to pick those people out, because what I've wanted to do, 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."
That's not very helpful to me, because I need to translate it into this questionnaire.
So I need to know, what is active shopper?
That means somebody who is purchasing certain kind of item, whatever we define, three times a week.
Yeah, that's active, right?
So we have some very particular, very measurable, concrete things.
So then I'm writing this questionnaire.
And typically, what I do is I rely pretty heavily actually on User Interviews.
Respondent is another one of these kinds of services.
So I can post that questionnaire and get responses, depending on what I'm looking for, pretty fast.
So I can recruit in a matter of three, four days, typically, depending on what I'm looking for.
And I've been able to get surprisingly specific people that way.
And so that is a huge shortcut for me to be able to recruit that way.
This episode is brought to you by Enterpret.
Enterpret unifies all your customer interactions, from Gong calls to Zendesk tickets to Twitter threads to App Store reviews, and makes it available for analysis.
It's trusted by leading product orgs like Canva, Notion, Loom, Linear, Monday.com, and Strava to bring the voice of the customer into the product development process, helping you build best-in-class products faster.
What makes Enterpret special is its ability to build and update customer-specific AI models that provide the most granular and accurate insights into your business, connect customer insights to revenue and operational data in your CRM or data warehouse to map the business impact of each customer need and prioritize confidently, and empower your entire team to easily take action on use cases like win-loss analysis, critical bug detection, and identifying drivers of churn with Enterpret's AI assistant wisdom.
Looking to automate your feedback loops and prioritize your roadmap with confidence, like Notion, Canva, and Linear?
Visit E-N-T-R-P-R-E-T .com/lenny to connect with the team and to get two free months when you sign up for an annual plan.
This is a limited-time offer.
That's enterpret.com/lenny.
Where do you find these people?
How do you contact them?
Where are they?
So through User Interviews, they work with the panel and they basically-
Userinterviews.com?
Yeah, userinterviews.com.
Oh, amazing.
That's very easy.
Yeah, it's super easy.
So it's not like LinkedIn cold email, cold pings, not [inaudible 00:47:24] DMs, things like that.
No.
I mean, in previous days, I used to use Craigslist, and I did a lot of some pretty crazy shit recruiting people through Craigslist.
I had people once meeting me at a hotel room to test a robot through Craigslist.
But no, User Interviews is much more legit and very fast.
And there are other services like this now, but it's been one of the big changes that speeds a lot of this stuff up.
That's way too easy.
And how many people do you reach out to to go through a screener, roughly, to get to five?
So it will depend on what I post and how much response I get.
It has been somewhat hard for me to predict.
There are times I do it and the responses just start rolling in.
So the times I get like 400 responses, basically download it into a spreadsheet and just start sifting through.
As a reference, I have my criteria, and then I'm just trying to find who matches, who doesn't.
Okay, so it goes to hundreds.
It can be hundreds sometimes if I'm looking... I did one recently, I was looking for a very particular group of AI engineers.
That did not get 400 responses.
That was a very hard one to find.
That was an example where there was this very particular group that we were looking for, and I was like, "Do these exist?
This thing that you're solving for, I don't know... This is pretty hard to find these people.
I'm not sure they're existing."
Yeah.
And to your point, that's a sign.
I think there's a nuance here of, if this group is not only hard to find but hard to reach and get them to talk to you at all, that's already going to make your life hard building this company.
Right.
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 User Interviews.
So I've done a lot of work in the past with oncologists, with Flatiron Health.
Oncologists are not on User Interviews.
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.
So then I'm thinking about, where do these people kind of cluster online or in person, that I might be able to target them?
There's certain forums or certain conferences, these kinds of things.
Or I'm doing snowball recruiting.
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.
Professional associations.
I almost want to go down that track because I feel like there's a lot to learn there, but I'm going to stay focused and keep going through our steps.
But let me take a quick tangent.
So as you were talking, I actually wrote a post in the past on how to identify your ICP, and I put together a table of the very first ICP for some of the biggest B2B SaaS companies that I pulled up here.
So let me just give a few examples of how narrow some of these companies were when they went out to sell their product.
Let me do a few.
So Gong, which is one of the biggest B2B SaaS companies, their first bullseye customer, as they described it, was... Look how narrow this is.
Their ideal customers were software company selling in English, selling via video conferencing, selling software that cost $1,000 to $100,000.
Linear, their focus was two to five-person startups using GitHub and Google Auth at a founder-driven product company.
Let's see one more.
Augusta was really funny.
Companies with less than five employees in California who have no contractors.
See, what's interesting to me about those is that I would go even deeper and more specific, because some of those things are... And that's fine.
I don't know internally how they actually describe the details of it, but 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.
Yeah.
So it's interesting because when people saw this, initially, they were like, "That's crazy how narrow they're getting."
And I love that you're like, "That is not narrow at all.
You should go so much more narrow."
Because if I had to recruit those people-
Yeah, it's too broad.
And I think that's an important point here is this exercise, you get more narrow to do this research, but that's not your actual ICP, as you described.
Okay, so I understand what you're saying now, more and more of the difference between bullseye customer and ICP.
The bullseye customer is for research to help you identify a broader ICP, your business targets.
Yeah.
And I think this actually touches on another important point, which is that this is a learning exercise.
So that's what I'm describing, is how do we learn more faster?
And this is different from selling, right?
So what I hear a lot is people are like, "I'm on customer calls.
We're selling all the time."
And 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, which is to learn, to run these experiments as fast as you can.
And there's something, just even a mindset in how you approach the conversations, that's fundamentally different.
So there's this term that I love that Ed Schein coined, which is humble inquiry.
And so he frames it as humble inquiry is the gentle art of asking instead of telling.
To me, that's this fundamental way that I think about even just conducting these interviews.
So if you're in a selling mode, and 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.
And I can always do it because 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.
And people I come across, they're very nervous about that.
So there's something that's very distinct here about a learning mode versus a selling mode, selling and telling versus this idea of humble inquiry.
So I think that's actually an important distinction here.
I love that.
And I think it helps that you're finding randos on User Interviews that you don't have to worry as much about versus finding great intros through VCs that you do worry about.
Right.
Awesome.
Okay, so we've been talking about the step of recruiting your bullseye customers.
So you find these folks, you filter the screeners, you pick five, and you schedule them for the same day.
Is there anything else in that step that is important to cover?
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.
So I'm making sure I'm reminding people, I'm making sure that they're responsive to me when I'm asking them to e-sign an NDA ahead of time.
Am I hearing back from them?
And 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.
Yeah.
Good point, good point.
And I love that it's 125, not 100.
Is there like you've seen a difference there, that it's something more than 100?
I think that that's based on whatever the policy is at Alphabet that somebody set.
Oh, okay. I see.
So that's the standard that I'm-
I see.
... I'm going with.
Funny.
Okay.
And it also has just seemed to work.
People are showing up for that.
So if people weren't, then I would adjust.
And do you do backup people just in case someone doesn't show up?
Or it's just like, "All right, I guess we have four," whenever it does happen?
I actually don't.
So User Interviews, by working with them and by doing some of these other things along the way where I am making sure people are responding to me during the course of the week leading up to it, "Did you sign my NDA?"
I send a reminder, "Are you responding?"
I can tell if they're engaged.
If somebody's essentially ghosting me, I'm getting nothing, I'll just swap them out.
But I don't use alternates and I have very, very high follow-through.
Great.
Okay, what's the next step?
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.
As I said before, ideally, I can find a competitor's products and use those as free prototypes.
I love doing that.
It's surprising to me that often people don't do more of this, and I think that there's sometimes a sense that it's cheating or they're worried they're going to copy it or something.
I'm like, "Well, whatever."
If you haven't studied your competitor's products, and not just gone through it but seen how people respond to them, you're just missing something, right?
So what we do is work out the details of the variables that we're going to spread across these prototypes.
So there are certain features and then certain variables across, that I kind of imagine spread across these different things.
For example, we were talking about delivery of specialty medications.
So imagine one of the attributes is, who's delivering it?
Maybe one version is a pharmacist is going to come, one is it's just a delivery courier guy, and then another one, in this case, actually, it was a drone company, so a drone is dropping this thing off.
We could talk more about what it was like to test that, but there are different variables here.
The other option is, say, the size of the delivery window.
So it'll come in two days, but you can narrow down in a 15-minute window.
This one is as soon as possible.
You'll just have to be home to wait, this kind of thing.
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?
It's the box around this thing.
So you don't have to build anything, you're just describing it and putting whatever you need to illustrate and convey that.
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, in your experience, at this point?
Cool.
So these are kind of just like in Figma or exported just images you're showing people?
Exactly right.
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.
Yeah, they may.
I think the thing that's important is to not get distracted by that.
So here, the benefit to keeping it simple is that you're not too wed and too committed to anything.
Build only as much as you actually need to answer the question you're trying to answer.
That's a great point.
So it's like, even if you can create an awesome prototype, don't do that, probably.
Just keep it flat design.
Awesome means very crisply describing the distinct value proposition and problem you're solving in a way that people get it.
They're like, "Oh, I understand what this one is, and then I can compare it to these other ones.
And I understand what the features are, and I can have that conversation."
It's 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.
I love that.
So basically, as you've said, it's a writing exercise.
It's like the headline, the positioning seems to be the most important part to nail versus the design of it.
Right.
Awesome.
And I design them enough that they look different from each other.
So it's not version A, version B, version C, because in the course of the conversation, with all the observers, I want it to be clear which prototype somebody is talking about.
Awesome.
So the green one versus the blue one versus the red one, right?
So then when the observers can keep track... Otherwise, you're like, "Wait, what?
Which one are they talking about?
I don't know what's happening."
Awesome.
Okay.
Anything else that is important to note on the prototype step?
Proofread it carefully.
People get stuck on errors, and then it undermines the validity and the credibility of the prototype.
So proofread it and make sure, because otherwise people are like, "Uh, that's not right."
That's such a good tip.
So just have someone else read it, like someone else that hasn't been working on [inaudible 01:01:09]-
Just check them carefully.
... anything wrong.
Cool.
Okay, so what's the next step?
So you have these prototypes, you've got the schedules interviewed-
Right, so you have people coming.
You're scheduled, so people are showing up on Thursday.
We're going to start doing interviews, so you have to draft your interview guide.
What these interviews are going to look like, in the course of that watch party, it's five one-hour interviews.
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.
So the comparing and contrasting is I'm presenting each prototype and people are responding to that and telling me what they see, what this is, and then the responding to what each of these prototypes is, what they like, what they don't like, what's important, what's not important.
Some parts that they don't comment on is fine.
If that just doesn't even register, that's good to know.
And then I'm having them compare and contrast.
So by having three different prototypes, 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," for example.
And so they're kind of teasing out, what are the best pieces of each of these?
And that's really what I'm looking for through the course of this conversation, is I want to grab the best bits and pieces, the best Lego pieces, so I can then go construct the ideal version next, because none of these... Again, I'm not going to build probably any one of those.
I'm looking for the best pieces.
And through the arc of that conversation, 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.
Like, "Oh, it's because they had that other experience in the past where that thing went totally haywire, when something like that happened, and they don't have trust in that.
Now I know why that's the situation."
And it's very, very, very common that when teams are watching this, they're always like, "For Christ's sake, Margolis, would you just get to the prototypes?
Why are you just talking to them about all this other stuff?
And you're just chit-chatting with them.
Ugh.
Show them prototypes."
And so we always have to remind people, "No, no, this is really important."
Partly, you're also just learning a lot.
You hear those stories, which is what you want to get, but it provides a lot of context for understanding their reaction to the prototypes.
I love all that context that you shared.
This is the step I think where everyone gets kind of scared or afraid or thinking they're doing this wrong, they're biasing people.
So in the book that we'll link to, you give them a guide for how to write out this whole interview guide.
I have the book here, and I'm just looking at an example where it's like there's the warmup, there's the introduction, and then it's like your current experience with this problem, cost, depends on the problem space.
But I love in the warmup, big smile.
§03Transcript · 1:04:29–1:29:35
"Hi, thanks for helping me with this.
Thanks for signing the NDA.
I'm dialing in from Seattle.
Where have I reached you?"
And then it's like, "How's the weather where you are?"
So it's all these nice little questions you can ask to keep it light, and then just a few examples of questions you ask in this example where it's about the medication.
It's like, "Do you currently have prescription medication that you have to order and refill?
How many?
If I may ask, what are they?
When was the last time you filled a prescription?"
and on and on.
So it's kind of this whole set of questions just to help understand their worldview around this problem and the context around it.
And the way that I think about it is that I'm building an arc in that conversation.
And so it starts, like you said, it's just chit-chat about the weather and where you are and whatever.
Do I care what the weather... I don't care what the weather is like, but what I'm trying to do is build some rapport fast with somebody.
Again, it gets back to this idea of humble inquiry where I'm trying to build a connection with the person.
I'm trying to make them feel comfortable, because they usually are showing up, they want to make you happy, but they don't really understand... It's awkward.
It's super weird.
Like, "I'm going to talk to this weird dude.
He's paying me to tell him what turns out to be a bunch of personal stuff, and we're never going to talk again.
But am I doing a good job?"
It's odd.
And so I'm trying to put them at ease and I'm trying to encourage them and make it clear they're the expert in this situation, but they don't really know what's going to happen.
And so I'm building this arc slowly, hopefully not too slowly, to get them talking.
So one of the most important things is when you're doing that interview, smile.
You have to start with the big smile.
Even if you're on the phone, it totally changes the way your voice sounds.
And what I'm often looking for in those first few minutes is, are they smiling back?
Can I get the person to smile back at me?
And then I'm like, "Okay, we're good.
I'm getting them responsive and getting them talking."
I love that tip.
And again, I think a lot of people that aren't researches are just going to, "Oh, I don't know.
This feels weird."
Something that should be reassuring is mostly, you're just asking questions.
It's on them.
You're just asking questions and your job is not to say anything, almost, just keep asking questions.
Yeah, and to be really genuinely curious.
I think that's really... Again, it's to this mindset, this difference between selling... I have to genuinely want to understand and see the world and my product through their eyes.
And you're going to hear stuff that is wrong, you know doesn't make sense, or you're like, "That's weird.
What is that?"
And you just have to, not dismiss that, but dig in and try to understand, like, "Why do you think that?
What gives you that impression?"
That's what you're trying to learn, right?
And just smile, genuine curiosity, and focus on that person in front of you will get you pretty far.
Any other tips on this step for folks that are like, "Okay, I'm going to try this myself.
I'm going to start interviewing folks"?
Any other tips, anything else important you think is worth mentioning?
Yeah.
Practice, it makes a difference.
It's a hard skill.
It seems like, oh, everybody talks to everybody, but it's different.
When I do these, and I've interviewed thousands of people at this point, I have a different character mode that I put my head in.
And so I literally, before I start an interview, I stop, I take a deep breath, and I kind of put on that smile and I put on my listener character where I am embodying these things, this extreme curiosity, this focus on the person, this engagement, which is quite different from my normal, more cynical, skeptical personality, to the point where if my kids have overheard, like, "Who is that dude?
Because that does not sound like Dad, whoever is talking to that person."
But it's a different mode in my head where I'm in interviewer mode.
Maybe that's just me, but you might develop kind of that other character, especially if you're a founder used to pitching, you can have your listener character.
Okay.
That was an awesome tip.
Okay, and so I think then the next step is the final step, which is the watch party where you actually do this.
Yeah.
This is awesome.
So this is like our magic hack for banging all this stuff together.
Everything is coming together in this watch party.
So in this watch party, we have... Again, 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.
And so we have a very particular way that we structure all of that, and it's very important that the team is all in there and watching and doing this together.
So I'm in Zoom, 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, or Notion or Doc or whatever you want, collaboratively doing that.
And so people are assigned roles, so take turns taking notes, because it's pretty intense.
We have people manually taking notes and not using AI to take notes.
The reason for this is, what we've found is we want people to lean in to this experience.
We want you to focus and engage and pay a lot of attention, and if you know somebody else is taking notes, it tends to maybe make you lean out a little bit, or maybe you check your Slack or you're looking at email or something.
And so it's about keeping you really engaged and working.
So it's a working watch party.
So we take turns, we've assigned roles so people know, "Okay, interview two, Lenny and Margolis are going to be taking notes.
That's fine."
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.
They mentioned that product.
Has anybody heard of that?"
So that's really important kind of going in the background.
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.
We usually ask teams to be pretty judicious about that, because if I get a question like that, it could go a certain way, as you know, right?
You ask a question, you don't know where it's going to go.
And so if it's really important or you see something where clearly I've misunderstood something, clarify it.
So they're taking notes.
This debrief is in a spreadsheet that I've set up so that there are key things that we wanted to learn, and so those are specified in that spreadsheet for each study that I'm doing.
I'm like, "These were the key things."
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.
So then you can imagine you have... That first column is that set of questions, so those are the rows of the questions, and then each participant is another column.
So we're doing participant one, we're capturing it after the second one.
So we end up with the detailed notes.
We have the recording of my interview.
Those are the thickest, deepest levels of this.
Then we're distilling it down into this debrief sheet for each one, and so then you have a spreadsheet that's like the high level steps.
You can look across it at the end of the day.
At the very last thing, at the end of the day, after the final debrief, we do a big takeaways form.
So I create a Google Form, and it just is basically like, "How many interviews did you watch?"
just to check, and then, "What's your first big takeaway, second, third?
How would you adjust your definition of the bullseye customer here?
What do you think are the next steps or what are your big questions, open questions and concerns?"
And so each person then takes 5, 10 minutes independently, separately, individually, quietly, and just everybody mutes their video and fills that out.
And it's a way to grab a snapshot from the whole team of like, "What did we really learn?
This was the important things that we had set out to do.
What did we learn?"
And it captures that.
So then again, that fills out a big spreadsheet and we then review that.
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."
One of the other things I want to mention is we do this thing before the watch party where we get everybody predict what they think they're going to learn.
Oh, I love that.
And this is really valuable for a bunch of different reasons.
So it's a way to capture a snapshot before we do the interviews of, what do you actually think is going to happen?
And 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?
People will prefer ASAP delivery of their medications, and whatever.
What is your hypothesis of what's going to happen here?
And that helps me do a couple things.
One is it helps me make sure that I'm tailoring the interview guide and everything the right way, because it's another check, like am I understanding what you want to get out of this?
It's a snapshot of what we wanted to learn.
And then what happens is 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?"
because there's this... Any researchers out there listening to this will be familiar with this idea.
There's this hindsight bias that happens, which is as you've gone through the process, it's very difficult to remember that you didn't already know this.
And so after you've gone through a research study, very often, people are like, "Well, that seems obvious.
We kind of knew that that was going to happen."
You're like, "No, no.
Let's look back at a day ago, what we all thought.
And we actually have learned a lot, which is awesome.
That's the goal.
We've learned it an enormous amount."
And it's not to catch anybody out, but it's really valuable to have this snapshot and to, quite frankly, just help show the value of the research, like, "We learned things.
Or maybe we didn't.
Maybe you were all right, which is awesome.
And now we know, and we can move forward twice as fast."
The point you made about how most people after this are like, "Wow, this is not what I expected and I want to do this more," I know that feeling so well.
Every time you're like, "No, I don't need to talk to customers.
I understand what we need to build," and then you do, you're like, "Holy shit, why aren't we doing this all the time?
What are we doing?"
That's such a powerful feeling.
Yeah.
There's this other thing that I think is worth mentioning that I've come across, which, when we do this set of predictions, so again, it's across all different kinds of businesses, all different kinds of domains, there's certain patterns that I've noticed that show up over and over about mispredictions.
There's a pattern of the kinds of things that show up over and over that I think of as these common blind spots, and I think it's attributed... 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.
I'm not.
I'm always showing up as the noob, like, "Okay, what is your business?
What are we doing?"
But they have deep expertise.
And when somebody has deep expertise, it's very difficult to imagine that other people don't know what you know.
It's very hard to put yourself in their shoes, right?
And you just think, "Well, doesn't everybody know this?"
And so what that leads to is these key blind spots that are very common, which is 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.
Like, "Oh, wait, they're not ready yet?
Wait."
Right?
They're not there yet, or we haven't figured out who the right people are who are the bullseye, but people overestimate those kinds of things.
And it's really common blind spots that we find over and over across a lot of businesses with expert teams.
That makes sense.
Most startups realize what they're trying to build, nobody really cares about.
So I get why that happens often.
Okay.
Is there anything else in this step of the interview that you think is really important to mention?
Otherwise, I want to hear what you find are some common pitfalls and mistakes people make.
A couple things, I guess, about the watch party, that I would make sure... The team needs to be there, and they need to show up for all of it.
And this is the whole team, like all the engineers, designers?
Well, yeah.
I mean, so the way I like to... What we found... because sometimes we do this, and 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.
But it can make some of these other aspects of the process a little unwieldy.
So what becomes important is to define, who's the core product team?
Everybody's welcome, but there's a core product team who's probably taking notes.
And also, for us as the outsiders, we know those are the opinions... That's who's really building this thing, who's making the decisions and is going to have to own this and have to build it or actually do all the work.
So distinguishing about who is that core product team, they need to really be there for all of it.
Other people, if there's some other engineer on another project and they want to come in and see one or two, awesome.
Love it.
But everybody else, the core team, you need to be there for all of it.
Where do you find people often make a big mistake, waste time, have blind spots, maybe, along this process?
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.
So if you up with a combination of people who was a little mushy, like you let the bullseye bleed a little too much, in the end, you're like, "Yeah, I'm not sure what the conclusions are to draw here.
It just feels mushy."
And so whenever that happens, I always kick myself.
I'm like, "Ugh.
The team took control of the recruiting because it was their customers, and I just wasn't picky enough or we didn't narrow it enough, or they included some people who were experts that they already know and they talk to all the time.
Ugh, it didn't get what we wanted."
And that can be frustrating.
So you just have to really be disciplined and picky about having the right people in there.
Which comes back to where we started, just seven attributes.
I really like that, just giving people a heuristic.
There's like seven-ish narrowing attributes of who you're recruiting to get it really specific.
Yeah.
And ideally, you get... 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.
"Oh, it's people on specialty medications that are refrigerated cold chain.
All the other stuff, maybe not as important."
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."
There's some rubric or some couple questions or characteristics that are really the key ones.
This reminds me of, actually, with Linear, 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.
That's brilliant.
Yeah.
So there's a lot of overlap with this exercise and then, hey, you actually launch.
Any other blind spots or pitfalls, anything else that you think people often run into other than not getting narrow enough?
Put more weight on past experiences than on people's predictions of what they would do.
Classic.
Classic user researcher advice.
Yeah.
Say more.
I described, 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.
We're all terrible at this, predicting what we're going to do, and so I just put much more weight in what has this person shown and demonstrated in the past as their behavior and their attitudes and opinions.
And so I really try to get teams to anchor more on that.
I love that.
I think everyone always hears this and then they still fall for this, because it's like, "Oh, great, they're going to use this.
Awesome.
Let's build it.
They told us they would use this immediately."
So what I think back to is your advice of like, look for extreme excitement.
That's more of a signal that maybe they actually will.
And the other thing that you alluded to is confirmation bias, right?
And we encourage people in the watch party... We give people rules about how to listen, and we encourage people to make it okay to kind of police each other a little bit and jokingly like, "Oh, it sounds like you're confirming your own bias about people would do this thing that you thought they would do."
Try to keep each other honest about what you're actually hearing and try to be as neutral and objective about what you're hearing.
I love that.
To the signal that they're excited, it reminds me someone's quote once was, "Look for their pupils to dilate to sense how excited they are about something."
You can just see it.
You do a bunch of this and you'll know.
And if you don't know, you're like, "It's probably a no."
Which is how everyone always describes what product-market fit feels like.
You just know it.
If it's not obvious, then you don't have it.
Okay.
Michael, we did a lot of good work here.
We've gone through the entire process, solved everyone's problems.
I'm going to skip the lighting round just to keep this episode shorter.
Is there anything else that you want to leave listeners with before we wrap up?
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.
So a big piece of the GV portfolio is in biotech, developing new therapies, new treatments.
That's a very different-looking kind of business than a lot of digital enterprise, consumer kind of products that I work with.
What I think is really interesting is as I work more with those people... And so those are years, right?
And they're doing science, so 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?
How do we encourage more people to accrue onto a clinical trial?
How do we think about a clinical trial as a product and streamline that and make sure we're targeting the right people and increasing the number of people who are getting on there?"
So what's been interesting is as I work with teams... I mean, talk about expert teams.
As 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.
But they come from this other place, and so it's really... And they talk about TPPs, target product profiles.
It's like this different language and this different world to me, but it's the same things, the same methods and the same stuff.
So the idea of bringing some of these methods there, as I've been getting to do more recently, is really exciting to me because it feels like there's a... Partly, it feels a little greenfield, and partly, it just feels like the impact there is huge for some of those things.
So that's something that I've just been thinking a lot about recently, is just kind of excited about those kind of opportunities.
And also just kind of curious, I don't know, to hear from some of your listeners if they're doing some of this in those spaces.
This is a good segue to two final questions that I ask everyone, so perfect.
One is just share where people can find your book if they want to go deeper, if they want to practice it themselves.
And also, do they reach out if they want to work with you on this sort of thing?
So just share what folks can do if they want to learn more.
And then, coming back to what you just said, how can listeners be useful to you, maybe share cool biotech stuff?
So learnmorefaster.com, you can go grab a free copy of the book.
There's all kinds of demo videos of me doing interviews.
There's all kinds of worksheets and resources.
They're using a really nerdy researcher playlist there.
So please just go grab stuff.
It's all free.
Again, I'm not selling anything.
I'm just really eager to get people to try this and use it.
And please tell me, in terms of how you could help me, tell me your stories.
Try it, let me know what works, how you adapt it, how it applies even to places that aren't early-stage startups.
I assume some of this is relevant there, so please let me know.
Ways you can reach me to let me know is michael@learnmorefaster.com, you can just directly send me a note there.
I can't guarantee I'll reply to everybody, but I'll read it all.
And I'm on LinkedIn, is probably a really great place to reach me.
And it sounds like you also answered that last question, how can folks be helpful?
It's just like, share their experience with... Awesome.
Yeah, totally.
Just tell me your stories.
How did you use this?
What did you use it on?
What worked?
What didn't?
How should we fix it?
I'm excited that we were able to opensource this, that GV was able to do that, and so part of that is, help me update it and fix it.
Awesome.
And just to clarify, if folks want to go really deep, do you work with companies just ad hoc?
Or how does that work, just so people know?
I work with GV portfolio companies, so-
Okay, okay, got it.
So go work with GV.
Okay, there we go.
Great.
Yeah, my full-time job is UX research partner at GV.
Awesome.
Michael, thank you so much for being here.
Thank you a ton.
I've loved this.
This has been super fun.
Awesome.
I love to hear that.
Bye, everyone.
Thank you so much for listening.
If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app.
Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast.
You can find all past episodes or learn more about the show at lennyspodcast.com.
See you in the next episode.