Michael Margolis, UX Research Partner at Google Ventures, breaks down the Bullseye Customer Sprint methodology and how it helps startups quickly identify what to build and who to target. Learn how to use the “5 and 3 in 1 formula”—five bullseye customers, three prototypes, in one day—to accelerate learning and de-risk product decision-making.
Michael Margolis, UX Research Partner at Google Ventures, breaks down the Bullseye Customer Sprint methodology and how it helps startups quickly identify what to build and who to target. Learn how to use the “5 and 3 in 1 formula”—five bullseye customers, three prototypes, in one day—to accelerate learning and de-risk product decision-making.
Gain practical strategies for streamlining customer discovery so you can build the right products, faster. Michael shares how to define your bullseye customers, prioritize the key questions to focus on, and avoid common pitfalls in early product development.
About Michael:
Michael Margolis joined Google Ventures in 2010 as the venture industry’s first UX research partner. With over 30 years of experience, he's conducted 300 research sprints with GV portfolio companies across diverse sectors. His work has helped hundreds of companies boost conversions, test new concepts, streamline workflows, and define bullseye customers.
Michael joined Google as a staff user experience researcher, where he conducted research for Gmail, led the UX research team for Google Apps, and managed Google’s UX team in Seattle. Before Google, he spearheaded user research at Walmart.com and produced educational software at Electronic Arts. Michael earned his bachelor’s and master’s degrees in anthropology from Stanford University and is the author of Learn More Faster.
Connect with Michael:
You can follow Michael on LinkedIn or check out his articles on Medium.
Resources:
Follow Maze on Social Media:
To get notified when new episodes air, subscribe at maze.co/podcast.
See you next time!
Michael Margolis:
Starting with focus and building for a specific group in a specific product just accelerates your progress. You just can prioritize who you're serving, what are the problems they have that you're solving, what do they need, what input and feedback should you pay attention to and prioritize. So it just helps them move much faster when they can focus.
Ash Oliver:
Today on The Optimal Path, we're uncovering the methodology behind Google Ventures' Bullseye Customer Sprints from the book, Learn More Faster. We'll explore how to find focus and build the right thing for customers fast.
I am Ash Oliver, and this is The Optimal Path, a podcast about user research and product decision-making, brought to you by Maze.
Our guest is Michael Margolis. As a UX researcher with over 30 years of experience, Michael has boosted conversion, tested new concepts, streamlined workflows, and defined bullseye customers for hundreds of companies. Michael joined Google Ventures in 2010 as the venture industry's first UX research partner. He's conducted 300 research sprints with GV portfolio companies across security, healthcare, biotech, developer tools, transportation, e-commerce and more. His approach to research sprints was featured in the New York Times bestselling book, Sprint. As Michael says, "Running a startup is a learning journey. My goal is to help companies accelerate that learning and de-risk their decisions as they grow."
I'm excited to have you on, Michael. Thanks for joining me.
Michael Margolis:
Yeah, thank you so much for having me.
Ash Oliver:
I've been really looking forward to getting into this topic. You recently published the Google Ventures Playbook on accelerating learning and customer discovery in early-stage startups entitled Learn More Faster, and I think it's an excellent, clearly battle-tested guide to running what you call bullseye customer sprints.
So we're going to get into the principles from this, but I thought we could start with maybe some of the backstory since you've really got a very unique role given your position as a research partner at GV. So could you walk through maybe what your experience has been up to this point and what inspired you to develop the bullseye customer sprint methodology?
Michael Margolis:
So I joined Google Ventures in 2010 as the first and only UX researcher in venture capital and GV is Alphabet's venture capital team, so basically work with a lot of early-stage startups. But to explain how I got here with this, I started out in the early '90s working with package software companies doing educational software. So there, it was really about just the waterfall process and how do we build software and how do we put it in a box and ship it. I was an editor writing documents and learning how to do usability testing, that kind of thing.
Then went to a small boutique kind of product strategy and innovation firm in Palo Alto and there, what I learned how to do was these big, very expensive deep ethnographic-style research projects for giant companies like Alcoa and DuPont and Maytag, Ericsson, these kinds of things. I got to work with amazing researchers, and so that was a place where I learned how to do that sort of research and then also learned how to be very client-centric. Who are we serving? What do they need? How do we deliver that?
Went from there to walmart.com, which was an interesting transition. Walmart is all about execution, all about speed, all about low cost, and so it was a place where I got lots and lots of reps, and it was a place where I basically was studying how people shop, so you're doing a lot of comparison. It was where I picked up this idea of comparing a lot of different things. Look at this website, let's look at Amazon, let's look at all these different things and have people kind of go through those. So that's where I picked that up.
Then I went from there to Google. I joined Google in 2006, and Google is about innovation at speed. There I was embedded initially with the Gmail team, and so what I was doing there was again combining these things like, oh, so we're doing this innovation, so I'm doing some of this discovery kind of work like we were doing before, big open-ended kind of thing, and also usability, but squishing those together. How do you combine those into one kind of interview? Then also we were doing watch parties. So I would do these interviews with customers and have the team watching that, and we saw that that was really powerful. Initially, they were behind one-way mirrors, and then we're doing stuff more remotely, but again, picked up that piece.
So then when I got to Google Ventures in 2010, it was pretty interesting to start taking these different pieces and combining them. It wasn't that I was doing it so consciously. It was just the things that I had picked up along the way. It was just this very practical approach to research that I'd kind of accumulated and developed and so working with founders who really already know pretty much what they want to build. They have some problem they're solving or something that they're really committed to. And in that context, speed again was super, super important for them, right? The velocity is really critical, and when working with startups, what's interesting was, unlike some of these bigger companies, they're able to learn and digest the information and adapt really fast, right? So if you can inject some new discovery, some new insights to them, they can respond super quickly.
So over 14 years at GV, we experimented and combined these different elements into an approach that's turned into kind of a cheat code for answering these really big existential questions that early stage startups have, right? So we've taken these pieces, this in-depth qualitative interviews, combining open-ended discovery interviews with testing some kind of prototype or looking at things, this idea of watch parties and having the team participate and that team see all of the interviews, over time, we've kind of developed and refined and built this playbook into this approach that we call a bullseye customer sprint.
Ash Oliver:
I love how the journey and this culmination of these different experiences across these different contexts have shaped this approach. I want to get into the methodology itself. So before we get into the specifics of what the bullseye customer sprint is, what problem specifically does it address, and what impact do you see it having?
Michael Margolis:
These early-stage startups are under a lot of pressure to answer these questions like exactly who is our customer and what are we building? And that happens in a couple different circumstances.
One is they're building something brand new, and so it's expensive. You're investing a lot of time and effort into building that thing, and so you want to make sure you're building the right thing. Sometimes you've already built it and maybe you're doing great and you're selling in one market and you're going to expand or shift into a different market. So you're selling great in the EU, and now you want to get into the American market, and so you need to understand that, you need to adapt to a new group, a new set of customers so there are a bunch of questions there. Or you're shifting sometimes, your sales process works is shifting. So let's say maybe you're doing very high-touch sales for enterprise customers, and then what you want to do is augment that or shift that a little bit to a different tier where it's a little more DIY, a little more self-serve. Or you're selling, like it's already out, it's launched, you're selling, but it's not doing quite the way you want it, so you're trying to troubleshoot like what's going on.
So these are really common problems and situations that these early-stage startups run into, and as I said, they're just trying to figure out very quickly, what do we do? How do we resolve this? How do we answer these big questions?
And these teams are customer-obsessed, right? They're not afraid to talk to their customers. That's what everybody's telling them to do all the time, go talk to your customers, and they do a ton of it. So they'll tell us, "Oh, we talked to 30 customers last week," or "Last month I talked to 80 customers." These are the kinds of things we hear all the time, and they're talking to lots and lots of people, they're talking to friends and family, getting feedback that way, and there's just lots of people who don't really fit their ideal customer.
So what happens, what we see is that that process of doing that kind of product discovery, that customer discovery work, in the end, it can just be very inefficient. It can be kind of scattershot. Sometimes you do that and you talk to somebody who feels like, "Oh, that's a perfect match actually. This is exactly the kind of customer we want. They get it," and it feels like you've hit the jackpot, but doing customer discovery shouldn't really feel like you're playing the slot machine.
That's kind of the problem that this is solving is we've found a method that just predictively works really well. So this playbook, Learn More Faster, it's kind of like a cookbook. So if you go through this process of five bullseye customers, three prototypes in one day, it just kind of works as a predictable, manageable process that is fast and that people can just do.
Ash Oliver:
Yeah, it is something that I hear a lot from early-stage startups that they're talking to customers, but it's oftentimes within their own network, which can be deceiving. I want to get into the specifics when you talk about the five-and-three-in-one formula. What is this structure in detail, and how have you seen that be effective?
Michael Margolis:
For the bullseye customer sprint, the formula we talk about is five-and-three-in-one, so that's five bullseye customers, three different prototypes of value props in one day. What we do is very carefully select people who represent the bullseye customer, and so that bullseye customer is that very specific subset of your target market who's initially most likely to adopt your product.
So a big key to this is being willing to be very, very specific and set aside the other people for now who are outside of that bullseye, and you just want to target like really your most, most ideal initial customers and focus on getting feedback from them, focus on building for them. It helps streamline priorities, it streamlines your roadmap, all of those things. It just brings a lot of focus. And you have to be pretty picky and narrow down and get those so those five bullseye customers are key.
Then what we do is with three prototypes that are representing a variety of different value props of possibilities of what this product could be, these different options of the features and the benefits. Sometimes those are things that we can just learn from existing competitors' products, so you can just use different websites or different things that are out there and just learn a huge amount. You don't have to do a lot of work to build those concepts up.
So Having three of those is really helpful because if I just have one concept or one idea that I'm built out, there's this risk that a team sort of falls in love with that one thing and spends too much time over-investing and polishing that one thing. And it's pretty standard design practice, good practice to have multiple ideas that you're developing. Partly so you can... pushes you to think about some different possibilities, and partly so you don't fall in love with it, you can be a little more objective.
So then in the context of an interview, if I can present a few different ones, what I'm doing is getting people to compare those. So it gives me some breadth that I can show to that bullseye customer and they can not just pick a winner, but think about the pros and cons of those, and pick out the different tidbits and the features of the options that are across recipes that they want. So we can kind of think about like, oh, okay, now I see these are the best parts or the most important parts to you and understand why those are the most important parts. So having those three is enough for us to have some breadth of a variety of different things for them to choose from and compare, but not too much that they're overloaded in the course of, say, a one-hour interview.
Then by doing it all in one day, it's kind of this great hack for us because it saves a huge amount of time and effort. So what we typically do is make this a team sport. So I'm conducting these interviews, so that's five one-hour interviews in the course of one day. The whole team is watching in a watch party. They're debriefing. They're taking notes as we're going through. I do an interview, debrief, interview, debrief.
Then at the end of the day, because it's all in one day, the patterns and the lessons just become really obvious to everybody. We've all seen it, we've all observed what's happened, we know the stories, we have this shared understanding, we've had the debates and hashed it out all day, and then it's just really obvious what the big takeaways are at the end of that day.
It won't answer every question that you possibly could have had about your customers or your products, but the big ones that you are worried about, if you've structured it correctly around your core questions, you know what to do next, and the whole team can see that.
So this structure of five bullseye customers, three prototypes in one day, it works partly because it fits into a day. I can do five interviews, so logistically it works. Also after you do five interviews, you kind of hit this saturation point where even if people say like, "Well, it's only five, that doesn't seem like enough," at the end of the day, the team always is like, "I get it. I want to adjust who we're talking to or adjust the prototype, change something and do a little bit different. We're essentially running another experiment." So that five-and-three-in-one is this very compact effective formula that works for speed and for time to insight into next steps.
Ash Oliver:
Yeah, it's super reminiscent of the design sprint, same kind of formulaic type of approach, and you get so much out of a short period of time. I think it's so impactful for early-stage companies in achieving that velocity and kind of breaking a lot of ground in a short period of time. I was going to ask you, actually, about if there were any scenarios in which you find there's pushback or objection around the volume of customers that are being interviewed, saying how do you substantiate that if it's just a small number of customer interviews? But I think you've answered that with hitting that confidence or saturation point. Is there anything you wanted to add to that?
Michael Margolis:
One aspect of that idea of having just five bullseye customers is that it's one day, and we can get it done.
The other thing is this isn't the only batch of five that we can talk to, so we can certainly do more. It's not that you could only do five, but I think one of the keys to this is doing it in a batch. So do five, see what you've learned, what you want to adjust, and then if you still feel like we're not confident enough or we haven't quite learned what we want, repeat it.
So it's not a limitation that you're only allowed to talk to five. It's just the unit that we're working in. So we do it in a batch, learn a bunch, and then repeat and learn more, and so it gives you the opportunity to steer, change where you're going.
Ash Oliver:
Yeah. Another point that you made this kind of early definition part of the process, I can imagine there's some hesitancy or reluctance to narrow down that target customer who's in the bullseye and who's not. Can you talk a little bit about maybe some of the common pitfalls that teams might face when they're defining this bullseye and maybe how they can avoid some of those pitfalls?
Michael Margolis:
When we go through this exercise to help a team define who their bullseye customers are, and a lot of times it's your best guess at who that bullseye customer is. I mean, it's very well-informed because the team is a bunch of experts in their space, but it's still your best guess.
The kinds of things that we see that we have to kind of coach against is that people can be, a very ambitious founder can be reluctant to set aside potential markets. So they want the product to be for as big an audience as possible.
One way that we address that is because we're GV and we're helping them, we're also investors so that here's nothing I want more than for them to be wildly successful and to have the whole world using their product. So we're on the same team, and we're aligned in that way with their goals, but the starting point needs to be more focused.
We've seen just over and over and over, we've done those hundreds of times, worked with so many companies that, starting with focus and building for a specific group and a specific product just accelerates your progress. You just can prioritize who you're serving, what are the problems they have that you're solving, what do they need, what input and feedback should you pay attention to and prioritize so it just helps them move much faster when they can focus.
Again, if there are multiple bullseye groups, we can do this more than once. We're pushing them to prioritize and sequence who maybe is that next rung or that next group, but we want to push them to pick a group to start with that's initially most likely to adopt.
What we always have to do is just encourage them to be very specific, more specific than they're usually used to. We see a lot of examples of personas or ideal customer profiles. They're just not as specific as we tend to get, or maybe they over-emphasize demographics, more than experiences and behaviors, which we find is often more indicative. What other products have these people used, depending on if it's a consumer product or a B2B kind of product? Are there other products that they've used? If there's certain settings that they're in that's going to affect how they would use this, whether they're, if it's a consumer thing, or maybe whether they're living in a house or living in an apartment or they're living with other people or not living with other people? Or if it's enterprise, whether it's a distributed team or they're together or how big the company is, what else does their tech stack look like? They're just all these things that we find that helps narrow it down that's not really about demographics.
Often what we're doing is encouraging them to come up with the brainstorm, the criteria for excluding people, like what would make somebody not a typical customer upfront? Like we're developing a new delivery service for medications. If this person has never even used any other kind of delivery service for food even, they're probably not going to start with a delivery service for their medications. Then once they start recruiting, one of the things we see is people just aren't picky enough, and they're like, "Well, that person's close enough. They'll be fine. We'll just kind of fill the slot for the interview. Or maybe we'll just talk to our friends or somebody who we know, we've already talked to, an expert in the area," and that just isn't as helpful, quite frankly. So really being very picky and very specific about who is your bullseye customer and then really making sure that you're filling those five slots. If you only have five slots, you want to make sure that you're talking to people who are very good representative bullseye customers.
Ash Oliver:
It seems like to narrow and get crisp around the inclusion criteria, the exclusion criteria, moving past the typical baseline demographics and looking at some of these behavioral types of characteristics, it seems like a really important part of the process, like Foundation Level 1 in order to get right.
How do you then prioritize the key questions to focus on during a sprint, and what factors should teams consider? Do you also have a criteria, or is it something that is specific and unique to each sprint?
Michael Margolis:
What we do is we start by meeting with the founder, the head of product, the core product team, to essentially interview them about what's keeping you up at night, what are the fundamental things that you really need to know that are most pressing to know? So we have that conversation as a group. Again, we're making this a team sport so people can hash that out and hash out those priorities together. Just build a list of what are the things that you wish you knew? What's keeping you up at night? What are those nagging debates that come up every meeting over and over? At first we're just trying to make a list, just get it all down, get it written down so it's not just floating around out there.
Once we have that, then we can go back through that and help the team prioritize those. So the way that we do that, usually once it's all written down, it becomes pretty clear, at least at a gross level, which things really matter, but the kinds of lens that we turn on it to figure out what is most important, some key questions like, what are you going to do with the results of that, right?
So we want to make sure that we're focused on things that are really a top priority, something that's pressing, something that you need to make a business decision, a product decision about soon, some sense of urgency. We look for whether it's a project that actually has some kind of resources assigned to it. If it's something where they're like, "Oh, yeah, but we don't have any engineers available to work on that," like, okay, well, maybe that's not actually your highest priority. That's a good clue for us.
We also look to see is it something that could be fixed later? I mean, Amazon uses this language of one-way doors versus two-way doors. Is this going to inform a decision that you can't go back on, or is it something where, "Well, whatever, it won't matter that much, right? We can just kind of figure this out later."
As an example, I was helping a company that was developing a delivery service for specialty medications. So one of the big questions there was, do we optimize our logistics for delivering something really, like as fast as we can get it to you as soon as possible? Or is it more important that we can be specific and precise and like I can deliver it to you within a 30-minute window, but maybe it couldn't be there till tomorrow or later?
So that's a very fundamental question that's going to really affect how you build out your logistics and how you optimize a lot of different things so that's kind of a one-way door. You want to know that soon before you invest a lot of time and money. So that would make that a very high priority kind of question.
Some of the questions also, we look at them and try to vet them to figure out whether it's something where the answer might already exist somewhere. I guess I've done this long enough, I can see there is a pattern to certain kinds of questions where I just know somebody out there has studied this already more rigorously than we're going to.
For example, if there's some question about how do teenagers use TikTok to shop? What are teen shopping behaviors? I'm pretty sure that there's enough money in that. A lot of people out there have studied that, and we could probably find some kind of industry reports. There's market research that's been done somewhere. It's probably quicker and easier and better data that we can just get from somebody else who's already done it.
So those are some of the filters that we put through this, and so that helps us prioritize and bubble up the things that are top priority, most pressing, connected to our roadmap that we're ready to staff and put people on to work on those things that we're not going to be able to change later, really highest priority for now, and that's the step that we want to work on.
Ash Oliver:
Do you have a situation where the sprint really only focuses on one question? Or is it scenario-dependent, and sometimes multiple questions can kind of be grouped together, and you could tackle more than one question in a sprint?
Michael Margolis:
We definitely tackle more than one question. They're usually pretty related or connected. If they're completely different things, then we have to be careful.
As an example, let's imagine you're building a marketplace, and there are questions that come up about the different sides of the marketplace, who's selling and who's buying. But to answer the questions about the buyers, I want to talk to buyers probably, and I want to be careful about whom I'm including as the bullseye customer for that. If I have questions about who's selling, then I need to probably do a different study on the people who are selling.
So we need to make sure for the questions that we have, that they're all relevant to the same bullseye customer and that they're all high priority.
Ash Oliver:
Another part that you emphasize a lot in the book is the importance of qualitative interviews, so it's the five moderated interviews that's really making up the crux of the sprint. That might seem a little intimidating for some teams, and there's a lot of question around how to be able to do that effectively. How have you seen teams ensure that they can extract the most valuable insights from these sessions?
Michael Margolis:
Yeah. There's kind of the structure of it, and then there's also just how do you approach it as an interviewer, so there are two pieces.
So the structure, the way that I like to do these is as two-part interviews. Typically, it's a one-hour interview, and that first half of the interview is this more open-ended qualitative interview where I'm talking to somebody about their past experience, very concrete kind of things that they've tried, that they've done, what they've liked, haven't liked, what's behind that, what's their motivation, what are their goals. So we're just kind of digging into those things.
That second half of the interview is where we start looking at prototypes. So I make a transition roughly halfway through where like, "I have some different ideas. Would you take a look at these with me? How useful do these seem for your specific situation for you? If you're shopping for a new solution, how well do these work or not? Let's go through those, and then look at the pros and cons." So part of it is that structure of open-ended conversation plus some very concrete things I'm trying to get their reactions to and input on.
So that structure helps give people a sense of like, how do I approach this, how I break up the interview itself. In the Learn More Faster, there's some pretty clear examples of also how you build up from just getting some background and building rapport and building an arc out of that conversation so that it doesn't feel like you're just intercepting somebody at a shopping center or something, right? It should feel conversational. So there's that structure.
Then in terms of how to do the interview, what we see is it's sometimes hard for founders to shift out of their selling mindset. If they're successful founders, they're pretty practiced at pitching their idea. They've pitched it to GV, they've pitched it to lots of other VC firms, they've pitched it to friends and family, they've pitched it to customers. So they're very used to trying to convince somebody of what this is and explaining it and showing them why it's awesome. That's fine if you're trying to sell it, but if you're trying to learn, it's the wrong orientation so you have to be in more of in a listening mode. It's a different character that you're playing to try to learn and so it has to be a conscious switch.
For myself, I have to put myself in my listening character. So before I start an interview, I take a breath and, I literally, will shift into like, "Oh, now I'm listening," and I'm going to smile, which is one of the most important things, and I'm going to listen and ask questions. I'm going to be in this mode where I'm genuinely curious about this person who's in front of me and trying to understand how do they see the world, how do they see my product, why do they look at it that way, right? I'm not trying to convince them of anything. I'm just trying to learn and listen and be really curious, like why is that? How can I see the world through their eyes?
And then just building that rapport and making it really conversational and being very sensitive to how comfortable do they seem, how open do they seem, and trying to pay attention to that and adjust myself to make them more comfortable.
In terms of building rapport and managing that status, I think of it sometimes as do they feel like I'm in charge, like I'm higher status, which I don't want, because I want them to be the expert and to share with me.
So if I'm doing interviews in person, I, literally, would, just as an example, like sometimes I'll, literally, lower my chair below them so that I'm looking up at them or something like that. It's a little trickier on Zoom when I'm doing a lot of interviews, but you can see whether somebody's comfortable, right? The body language, they're not looking at you, and so just doing whatever I can to encourage them. "This is great. You're so helpful.” These kinds of things, just kind of building them up a little bit and making sure that they feel listened to, and that my curiosity and my interest is really coming across. Then the biggest thing is I just have to shut up and listen.
Ash Oliver:
Yeah, I mean I think the psychological tactics are definitely an important factor, but no more important than that mindset switch. Especially if you've, as you mentioned, been in this role of pitching, that'll definitely skew the results of these interviews if you're not consciously kind of moving into listening modes.
I'd like to talk a little bit about the prototypes themselves. It's really interesting to have this one-hour interview and to first be more focused around the discovery, the problems, the experiences, their background, and then transitioning into the prototypes.
What can you tell me about the prototypes themselves? Are there any creative ways that you've seen to create these designs? Are they typically really low fidelity, high fidelity? Is it really situational? What are you really trying to aim for in the prototype comparison part of the interview?
Michael Margolis:
My goal for those prototypes is to choose and be able to share with the customer a breadth of different value props, so different features, benefits, ways of messaging, and talking about what problem is it solving and exactly how is it solving it? So to be able to present a variety of those that they can compare and think about, sometimes those exist. So if I can grab competitors' websites and use those, those are free prototypes, those are great because it takes no effort whatsoever.
Sometimes there's situations where there's not something that quite fits, doesn't exist already, and so we need to make something. The goal there is to do as little work as we can when we build that.
What we're trying to do is mock up something very simple so the thing that we usually use is something that looks like a homepage or a piece of a website because it's very familiar to people. They are used to shopping and comparing and thinking about options for things that way, a very common familiar way to show a menu of features and different kinds of things with more context, so that the actual artifacts themselves you can create in Figma, you can create in Google Slides, whatever you want. It's just a very plain-looking thing. There's nothing clickable usually on it. It looks real, so it's realistic-looking, but it's just a screenshot of it or JPEG of it.
Then what we see is that the challenge to it is actually in the writing. So how are you describing what is this thing? What actually is the benefit? What is the value prop of the thing that we're thinking about making? What we find is that that exercise of just creating these prototypes very simply and doing the writing and having to agree as a team, like, "Well, actually, yeah, I think that's what it is." Or, "Is that what it is?" Or, "Is that what we were talking about? I thought you meant we were going to make this thing." I don't know, but just having to write it down and, again, be specific. We've seen many, many times just that process of making the prototypes and agreeing on what's in it as a team is very, very valuable. So they learn a ton and they get aligned to like, "Oh, actually this is what it is," or "It's not what it is. This is what we're building."
One of the steps that we have people go through when they're trying to map out what are the value props or the benefits that we do want to show is if you just make a simple chart, which is what are the features down the side and then across the rows are essentially what are the options? What are those variables? What's the possibility?
Let's say you're creating a new burrito shop as described in the book, right? So maybe the different value propositions are one's really about quality and one is about fast delivery and one is about authentic recipes. So you can imagine for each of those, like for delivery, that would be the feature, and then the different options might be grab-and-go, or I can deliver it to your house in less than 30 minutes, or you just kind of order it and I'll serve it to you hot, right? So those are three options. Across those different recipes of value props, of prototypes, each one might include a different variable, a different way that the delivery would work.
So that way when people are looking at these and comparing like, "Oh, I really like the idea of this authentic recipes, but I love the way that this other prototype has grab-and-go, that's really important to me." So again, you're picking apart those pieces when you're doing the interview, but ahead of time I'm speccing out what are those different variables that we want to build into each recipe for these three prototypes.
Ash Oliver:
Yeah, I think that's a really important distinction when talking about comparing prototypes. I don't think that most people would think to focus so much on the writing and the value propositions, as more so of the layout or the design of the thing so I think that's a really important component.
I really love how this whole exercise from defining the bullseye customers to getting to the prototypes is really an exercise of extreme focus, which I think has such immense value overall as you described.
I wanted to circle back to something that you made mention of earlier, though, and it comes at maybe the Founder's syndrome, being really close to the problem and maybe having some of these conversations in kind of pitch or selling mode. What advice would you give to the team to avoid the natural pitfall of bias when maybe falling in love with some of those early ideas or prototypes?
Michael Margolis:
Yeah. To avoid the bias that they have, there are a few things that we try to do. One is essentially pushing teams to develop more than one idea. You should require your team to develop more than one idea and more designs. It's good practice. It pushes you to come up with new ideas, and it helps you avoid investing a little too much and getting too in love with something. Once you have multiple things, you can be a little bit more objective about them, so that helps avoid that bias.
The most powerful way to counter bias is to put it in front of bullseye customers, and seeing it through your customer's eyes is the fastest way to shift your own perspective. I work with a lot of teams that they're really deep experts in their space, but they have a certain view of the world, and they all have that shared view often, and so it can be a little bit of an echo chamber. So it's not until they see somebody else... It's the quickest way to break through that bias and to break out of their own view of the world.
But part of the trick to that is it's back to the bullseye customer idea. So before I've shown it to people and everybody's watching me do this, we've all agreed, yes, this is our definition of the bullseye customer. Like we believe as a team we're all in agreement that those people initially should be most likely to want this. So then when we're doing the interviews and they're starting to see this through their customer's eyes and whether the customers love it or don't love it, it's hard to say, like "Well, that's not really the right customer. We're going to dismiss this or ignore them. They don't know what they're talking about." Because we went through this step where we all agreed those are the people and we can decide actually those aren't the right people, and that was our discovery, is that there's something different we want to change or adjust about who is in our bullseye customer, that's fine, but it makes it hard to dismiss.
One of the other great things about the way we do this is doing it as a team, as a team sport, it makes it hard to hide from the reality of the feedback. So when the whole team is watching this and seeing some idea, maybe it was the founder's idea, or somebody else who's a high-status person had this idea they put in there that they loved, and we all see that nobody wants that or that's problematic for these reasons, it's hard to hide from that, right? Maybe that person who loved the idea is still biased about it, but we've all seen it, and we all know it's not going to work, and here are the other things that work better. Here's what we learned.
There are certain biases that we've seen over and over as patterns across a lot of these companies. One that's really common is teams just will overestimate how much customers know and where they are on their adoption curve. They're so deep in whatever the content areas, whatever they're building, and they're like, "Well, customers will get that. They know this." Then we talk to customers and it's customers busy with the rest of their lives and they're not paying much attention to this, and they're like, "What are you talking about?" Or they know some about it, but not as much, so they overestimate how much customers know.
A lot of times they underestimate how much risk-averse consumers and businesses might be. So they're just big costs and risks of switching, and a lot of times they don't want to take that on. It's not clear, like, "Why should I do that?"
The other big one is price sensitivity. A lot of times we see people will just underestimate that price sensitivity, probably linked to how valuable does somebody see this thing is, they don't see it as valuable maybe as the team thinks it was. Those are a few, not all of them, but those are a few things that we see over and over.
Ash Oliver:
Before we transition to the last segment of the episode where I can ask you some personal questions, I'm just wondering if there's misconceptions or beliefs about user research in the startup ecosystem that you come across that you would like to change. How do you see maybe some of these old beliefs impacting the way that companies approach product development and how that might change in the future?
Michael Margolis:
I think, for me, the biggest one is that it can be fast, and it can be efficient. There is a process for doing it that's very predictable so I can orchestrate a bunch of insights and a bunch of learning in a very just predictable way.
Because I think that some of the resistance I see when we call it research is that it's going to take a long time, or it's going to slow me down. One of the big limiting factors was recruiting would slow us down, but now we have great services, online services that make it pretty easy to be very picky and to get very targeted. So, yeah, speed. That's the thing I want people to know. It can be fast.
Ash Oliver:
Michael, this has been awesome. It's really exciting to walk through the core principles of the book. If you want to just shout out where people can find it, I think that'd be great.
Michael Margolis:
So we're pretty excited we make it available for free to everybody. You can just download digital copies, as well as all the templates and worksheets, and there's example videos I made. There's even a geeky research-themed playlist there, so everything you need is at learnmorefaster.com.
Ash Oliver:
We'll make sure to link that in the show notes as well.
All right, so for my last series of questions here, these are our hat trick questions that we ask every guest just to get to know them a little bit more. So my first question for you is, what's one thing that you've done in your career that's helped you succeed that you think few other people do?
Michael Margolis:
For me, a really important thing has been to be client-focused. So what I mean by that is just to spend a lot of my effort as a researcher, turning my research skills onto the stakeholders to figure out what do they really need, so that I can make sure that I'm delivering the right thing at the right time. I will start any project by doing a little bit of research, a little bit of studying of those stakeholders to understand what are their priorities? What are the risks and assumptions that are built into whatever they're building and that they need to validate? What are the questions they need to answer? What are the deadlines?
I have this framework that I've described in the past called Start at the End captures this client-centric approach. So if I can identify those priorities, risks and assumptions, questions and deadlines that the stakeholder has, then I can move very quickly to figure out like what would you need for me to give you that would answer those questions or would address that. If I know what that end result is, what that deliverable is or what the information is, then I can figure out, like what data would I need to collect to create that, to provide that to you? And if I know what data it is, then I can figure out like what method, what kind of an interview, or is this a survey or what do I need to do? Then from that I can figure out who do I need to talk to, what's the sample? So once I'm starting with a clear understanding of what the client needs and when, then I can do the other part really fast. So that's helped me a ton.
Ash Oliver:
I think a lot of the researchers might resonate with them, but it really is applicable to anyone, so that's great. My next question is, what is the industry-related book that you've given or recommended the most, and why?
Michael Margolis:
For me, when I'm talking to new researchers, I love giving them, pointing to Research Practice by Gregg Bernstein. It's less of a how-to, it's not about how to do research or how to conduct interviews. It's more about how to be a researcher, how to work with teams, how to work in an organization, how to work with stakeholders. It's the stuff that usually takes a long time and takes some experience to learn as you're working as a researcher, but it's like having this whole community of really excellent researchers from around the industry in your back pocket. So that's a favorite of mine.
Ash Oliver:
Yeah, Gregg's great. Okay. My last question for you is what is an unusual habit or an absurd thing that you love?
Michael Margolis:
I love musicals, so I subscribe to theaters here. Last year I subscribed to two different theaters, which was a lot of musicals. My wife told me it was maybe too many musicals. The thing that I like doing is going to them... I listen to the music ahead of time, but I tend to not learn too much about them or look them up or watch videos of them ahead of time because I love to go and then see the staging and it's like the... Even if I know the music, when you see it performed live, then it's like this big reveal. I'm like, "Oh, now I understand."
The music doesn't make as much sense without knowing what's going on on the stage, and so it's kind of this goofy thing because I could always look into it or know what I'm going to see. But if it's something I haven't seen before, I love that kind of big reveal and that experience of seeing live musicals performed, seeing that for the first time.
Ash Oliver:
That's fun. Michael, thank you again so much. I think there's a lot more that people can get from the book as well. This has been a great snapshot of that, so thank you so much for being here.
Michael Margolis:
Thank you for doing this. Really appreciate it.
Ash Oliver:
Thanks for listening to The Optimal Path, brought to you by Maze, the user research platform that makes insights available at the speed of product development.
If you like what you heard today, you can find resources and companion links in the show notes. If you'd like to stay connected, you can subscribe to the podcast newsletter by visiting maze.co/podcast, and send us a note with any thoughts or feedback to podcast@maze.design.
It's that time of year again, the Maze Annual Conference Disco Conf, short for Discovery Conference, is back for its third edition on Thursday, October 17th. Virtual by design and free to all attendees, check out maze.co/discoconf to learn more. And until next time.