Eric Migicovsky - How to Talk to Users

Hi everyone, my name is Eric Richard Kazuki. I'm a partner here at YC. I actually started a company that went through Y Combinator back in 2011. I started a company called Pebble; we made one of the first smartwatches.

I am really excited to be here to talk about talking to users because this is one of the perennial things that you always hear about as one of the critical factors in starting a company. The best founders maintain a direct connection to their users throughout the lifespan of their entire company. They maintain this direct connection because they need to extract information from their users at all different stages of running their company.

Oftentimes, people think that, you know, they’re the CEO or they’re the CTO; they’re the technical kind of product leads of the company. They can outsource this research to other people in their company. They can hire salespeople; they can hire heads of product. But at the core, the best companies are the ones where the founders themselves maintain a direct connection to their users. If you are the CEO, it is your job; it is in your job description to talk to customers. So take the time to learn how to do it well.

All founders need to participate in this process as well. Don't, if you're the engineer, if you're the developer, don't think that you can escape this process just because you're the person who's coding. There's a pretty classic scene from the movie Office Space where there’s an individual who says, “I'm the person who is the go-between between engineers and users; I know how to talk to people; I have people skills.” That is one of the things that you do not want to have happen at your company. You want to make sure that the founders and the core members of your company are the ones who develop the skills for talking to users so you do not have to hire someone like that to be the go-between.

Talking to users is so critical that at the core of kind of YC's teachings there are only two things that you must do in order to start your company: you need to code or build your product and talk to users. This is easier said than done. I want to provide today some tactical advice on how to plan your strategy for talking to users, as well as some questions and strategies that you can use to conduct your own user interviews.

At the beginning of your company, a lot of the advice that I’ll present today is actually synthesized fantastically in this book actually written by a YC founder called The Mom Test. The name of the book comes after the process in which we probably all go through where we want to tell our parents about the company that we're working on. We think that by talking to people that we know love us and want to support us, we're actually extracting good or useful information about how to adjust or improve our company. But at its core, this is not the best way to get information.

So, The Mom Test, as Rob actually explains, outlines three common errors that we make when we try to conduct user interviews. The first problem, the first mistake that we pretty much all make is we talk about our idea. We’re founders; we love to pitch our idea. We love to talk about the product that we're working on. But during a user interview, that is not the time to be pitching the product. The goal of a great user interview is to extract information from the person that you’re talking to, to extract data that will help you improve the product or improve your marketing or improve your positioning. It is not to sell them on using your product.

At the core of a great user interview, you need to learn about their life. You need to talk about specifics around the problem area that you're trying to solve that the user may be going through. The second mistake that we pretty much all make is we talk about hypotheticals. We talk about what our product could be; we talk about features that we want to build. We ask questions like, “If we built this feature, would you be interested in using it? Would you be interested in paying for it?” That is wrong. Instead, talk about specifics that have already occurred in the user’s life. This will give you stronger and better information in which to make product and company-changing decisions.

You also want to talk in general about the user's life. You don't want to just talk about the specific problem or, sorry, the specific solution that you're presenting. Try to extract information about the user’s path that led them to encounter that problem. Ask them questions about their life in kind of broader ways to extract context around how they arrived at this problem. Learn about their motivations; learn about why they got themselves into that problem in the first place.

And the third trap that we pretty much all fall into is that we talk. We talk a lot! As founders, we’re always pitching investors, we’re pitching employees, we’re trying to hire people, we’re trying to partner. So we tend to spend a lot of our time talking in a user interview. Try to restrain your interest in talking and really listen. Take notes and listen to what the user is saying because in that span of time, that 10, 20, 30 minutes that you spend with the user, you're trying to extract as much information as possible so that when you return to the office and when you return to your co-founders, you're bringing hard data, real facts about users' lives to the table.

I think that there are five great questions that everyone can ask during their early customer interviews. The first question is: What is the hardest part about doing the thing that you're trying to solve? Let’s take Dropbox for an example. Now many of you may not remember our world before Dropbox, but put yourself back in the position of Drew, the founder of Dropbox, in 2005 when he was initially working on kind of the initial idea of Dropbox while studying at MIT.

Imagine you're in the computer lab at MIT and you're sitting next to your friend. You turn and you ask, you're working on this project to create Dropbox, and you want to learn more about how other people are sharing files so that you can learn, you know, are these other potential users here or what are the problems that I can help solve with this new technology. So you turn to your friend and you ask, “What is the hardest part about working on a group project with school computers?” You're sitting in the computer lab; it's the perfect context for asking that kind of question.

You begin an open-ended conversation, trying to extract information about how that person currently works on group projects with friends. Hopefully, you'll learn about specific pain points that they have, like they log onto a shared computer; they have to get their files from somewhere. They may have a network drive attached to the university system, but they're working with someone who may not be logged onto a university computer at that time. Maybe you learn about problems with the synchronization of shared work. Maybe you're both working on the exact same document at the same time. How do you begin? How do you currently attempt to solve that problem?

In general, the best startups are looking for problems that people face on a regular basis or that they are painful enough to warrant solving. This question can help confirm for you whether the problem that you're working on is actually one that real users feel is a pain; feel as something that they actively want to solve in their life.

The second question, to the point that I was making earlier about trying to get to specifics rather than hypotheticals, is to ask the question: Tell me about the last time that you encountered this problem. The goal of this question is actually to extract context around the circumstances in which the user encountered that problem. So, for example, in the Dropbox case, you may be talking to your friend and learn about a week ago—a specific time frame. Who were they working with? Which class were they working on? Was this a computer science problem? Was this an English paper?

Try to extract as much information as you can about the context in which they began solving this problem so that as you develop your product, you'll be able to actually reference real-life examples of past problems that potential users have had, and you can overlay your solution on top of that to see if it would have helped in that particular circumstance.

The third question is: Why was this hard? Why was the circumstance in which that student was trying to work on their shared project, their project with other folks, hard? What were these specific things that they encountered that were difficult? The reason why you want to ask this question is that you'll hear many different things from different people. Going back to the Dropbox example, you might encounter some people who say that maybe the problem that they were encountering was when they emailed files back and forth; they ended up duplicating work because they didn't have the exact same kind of document at the exact same time.

Maybe other people will say that they submitted the wrong document in the end to the professor for their group project because they had like crazy strings of file version numbers at the end. So the benefit from asking this question is not just to identify the exact problem that you may begin to solve with your solution but you'll also begin to understand how you market your product; how you explain to new potential users the value or the benefits of your solution.

In general, customers don't buy what they don't buy; they buy the why. So, in the Dropbox example, they may not be excited and overjoyed at saying, “Oh, I now have this kind of file syncing tool that can keep all my files in sync,” but they'll buy the why. They'll say, “Well, this exact product, this product will help with this exact problem that I had just two weeks ago when I was trying to work on a student project with some of my friends.”

So, answers that you get from customers to this question of why that past problem was encountered may actually inform your marketing or your sales copy as you build out the rest of your product. The fourth question is: What, if anything, have you done to try to solve this problem? One of the biggest things that I've encountered while helping YC companies over the last few years is that if potential customers are not already exploring potential solutions to their problem, it's possible that the problem that you’re trying to solve is not a burning enough problem for customers for them to be even interested in your better solution to this product.

So this question tries to get at the root of that issue: is the person who encounters this problem already trying to solve this? In the Dropbox example, you're working on a group project or you're talking to someone who’s worked on group projects in the past. Try to figure out what tools did they experiment with? What tools did they try to use to solve this in the past? Maybe they solved this by getting all the individuals together in one room to work on the project with four computers so that they could talk in real-time to each other as they were working on the project. Maybe they experimented with email.

Maybe they tried setting up—one of the top comments on Hacker News posted during the original Dropbox launch—maybe they had set up rsync, and they would already solve this problem with SFTP or something like that. Again, you want to ask this question for two reasons: one, to figure out whether the problem that you're solving is even really something that people are already looking for solutions to; and two, what are the other competitors out there? What will your product be compared against as you end up rolling out your solution and offering it to end customers?

The fifth question is very tactical: So, what don't you love about the solutions that you've already tried? This is the beginning of your potential feature set. This is how you ask the question of what are the problems with the existing solutions that they’ve already tried. Now note that this is not the question of what features would you want out of a new file syncing product, in the Dropbox example, because that’s a hypothetical question. Users in general are not great at identifying the next features that they want in the product, just like the old Henry Ford quote—you know, when we were developing the automobile, our users would have wanted a faster horse rather than that car.

So this question specifically targets what are the problems with the existing solutions that they've already tried. These are specifics, and you can begin to kind of figure out what the differential between your new solution and the existing solutions already in the market will be.

Talking to users, as I said before, is useful in pretty much all stages of your company, but there are three critical phases to an early-stage company. I would kind of define that as a company that has not yet reached product-market fit, in which talking to users would be extremely beneficial. Those three stages are at the idea stage, before you've even begun developing any of your product; at the prototype stage, where you have the first kind of rough beginnings of your product, but you haven't really gotten it in the hands of any paying customers or any users yet; and the third one, which is after you've launched and you're iterating towards product-market fit.

How do you guide that journey? I'll talk about a few tips for each phase. At the idea stage, you may have the back of a napkin idea, you may have a thought, or you may be commercializing some technology that you've been dreaming of, but you don't yet have any first users. So you need to begin finding the first people that will be interested in either providing information about the problem that they've encountered or potentially signing up to be your first users.

The best people come to me to ask, “How can I talk and how can I find my first users?” Honestly, some of the best companies are products or services that are built for the founders themselves. So start with yourself. Begin, like test your user interview strategy on yourself. Try to walk through a situation where you've encountered that problem.

The next step after that is to talk to friends, to talk to coworkers, to get warm introductions. It doesn't take a lot of people; you don't have to talk to thousands. Every good user research strategy begins with just one or two people. The critical feature here is executing an unbiased and detailed customer or user interview strategy, rather than just trying to pitch your idea to them.

Another cool hack that we've seen some great success with—actually a YC company in this batch—is using this. A YC company in this batch is actually selling products to firefighters, and they realized that cold email introductions were just not a way that they could get through to the customers. So what they did was they actually just dropped by fire stations in person. They didn't even, you know, email them to say that they were coming ahead of time; they just showed up and they said, “Hey, could we speak to the fire chief? Could we talk to someone about this problem that we've got a solution to?”

You know what? It worked great! They managed to get dozens of in-person, no, 10 to 15-minute long meetings just by showing up. So when in doubt, if there's a specific target customer base that you're looking to get feedback from, just try showing up. It feels a little bit weird because it feels like you're imposing on someone. But at the end of the day, the mindset that I like to get into is if you truly think that you're solving a problem that your target customer base is facing, you'll actually be doing them a favor. You'll be helping them out by taking their 15 minutes and learning more about the problem.

Industry events are another great way to get a number of new customer interactions. I remember that when I was working on Pebble, we actually went to CES, which is this large consumer electronics show in Vegas. We didn't have a booth; we just went in guerrilla-style. We just randomly started setting up meetings with potential users, and we met them in like the coffee shop I would side at the conference. We did that for $0, without any sort of marketing budget, just because that was where a lot of people in the industry were, and we knew that there was like a high concentration of potential people that we could talk to.

Some tips for this stage: take notes, take detailed notes because, as I said before, you’ll never know until later which key facts of these user interviews may be useful. If you're not great at taking notes while you're talking to someone, bring a friend; bring a co-founder. Ask the person if you could record it. When in doubt, capture as much information as possible. Keep it casual; like I said before, you can just show up. You don't have to pre-plan this; you don't have to have, you know, 20-minute blocks on your calendar scheduled for days on end of user interviews.

Feel free to react! Honestly, you'll learn so much through the first 5 or 10 user interviews that your process will dramatically improve from those first interviews to the next batch. So don't feel like you have to do a hundred user interviews all at the same time. Just start with one; start with three; start with five until you get the hang of it.

The third thing is you need to be cognizant of the other person's time. Again, going back to what I said at the beginning: we love our idea, we're founders; we love talking about our idea. So you need to keep yourself in check and make sure that you're cognizant of the other person's time. Honestly, you'll be able to get probably the best information out of say a ten to fifteen-minute long first interview, and that might be all the time you need just for that initial chat.

As you move past the ideas stage into testing your prototype with users, the next major benefit that you can get from talking to users is figuring out who will be your best first customer. This is critical because it’s possible that if you choose the wrong first customer, that you may be led down a path that constrains you or artificially traps you without actually getting paid by that first customer.

So we've created a framework that you can use to begin to identify, before you begin working with them, who the best first customers will be. During user interviews at this stage, I love to ask questions that extract numerical answers to three facts about the customer that I'm working with. The first one that I like to get to the bottom of is: How much does this problem cost them today? And I like to get a hard number, either in terms of how much revenue do they stand to earn if they solve this problem or how much expense do they currently spend trying to solve this problem? How much money is wasted today as they try to solve this problem?

The second one that I like to get to the bottom of is: How frequently do they encounter this problem? Do they encounter it on an hourly basis, a daily basis, a quarterly basis, or a yearly basis? The best problems that startups can target are ones that are encountered more frequently. This is usually beneficial for two reasons: one, is they encounter a problem on a more regular basis. It means that the customers feel the pain of that problem on a more regular basis, and they'll be much more receptive to a potential solution.

The second reason why you want to tackle a problem that people encounter on a more frequent basis is you'll get more chances to know whether your product is actually solving a problem. In my case with Pebble, I love the fact that I was working on a device that was kind of intended to be used every day. You know, you wake up in the morning, you put your watch on; that was great for me because I knew that if users weren't wearing their watch on a regular basis, that meant that I was doing something wrong. So the best first customers are ones that have this problem very frequently.

The third thing that you want to get to the bottom of is: How large is their budget for solving this problem? You can imagine that, say, you're solving something for an industrial assembly line problem. On the industrial assembly line, if you're talking to the operator—the person who's actually there on the assembly line—they may encounter this problem on a really regular basis, but they just don't have the budget; they don't have the authority to actually solve the problem, that's their boss, someone above them in the office, in the headquarters.

So again, as you're trying to identify the best first customers, make sure that you're asking questions about whether they actually have the ability to solve the problem. Given the choice, I like to visualize answers to these three sets of customer questions as overlapping Venn diagrams, with the best first customer being at the center of the Venn diagram where they have the highest numerical answers to the three questions that I outlined.

So let's take a quick example. Imagine if you're working on a super smart blender that's designed to produce the tastiest new fruit smoothies. You talk to several users; let's say you’re talking to McDonald’s, the French Laundry, and the Google Cafe. You create a spreadsheet that simply has three columns with the answers to the questions that you’ve extracted through your user interviews.

Via this data, you can actually be used in prioritizing which customer you begin to sell your product to first. So for example, the French Laundry is an amazing restaurant up in Napa. Maybe they have an opportunity to roll out a new extremely fancy, over-the-top smoothie with your new technology. They can extract a lot of money from each sale, but the frequency is not that high. There are just not that many customers that are interested in a fruit smoothie at the French Laundry, and you’re talking to maybe the sous-chef at the restaurant.

So you realize that they don't really have that much money to solve this problem, even if they wanted to. The other potential customer that you're talking to is the chef at one of the Google cafes. Unfortunately for you, Google gives away their food for free to their employees, so that person doesn’t actually stand to earn more money or save that much more money if they were to use your new smoothie technology in their restaurant. Granted, there are a lot of Googlers, so there probably would be a lot of smoothies made per week. But at the same time, again, they just don’t have the budget to be able to really dig into this problem.

So you learn through the initial customer interviews that McDonald's is actually the best potential first customer for your product. While even though the cost of a new smoothie at McDonald's may not bring in a large dollar amount per transaction, they have a ton of stores and each of those stores serves a ton of people. And on top of that, you happen to get a warm introduction to the chief food officer of McDonald's—I'm not even sure they have one—but that person actually controls a multi-billion dollar budget, and if they wanted to solve this problem, they would have the authority and they would have the budget to do so.

So you put that information in your spreadsheet, and you actually do a simple stack rank that just pulls the best answers to those questions up to the top. You can use this framework for kind of pulling together all the information that you get from various user surveys to find the best customers.

The last stage, for product-market fit that can benefit from user interviews, is actually the process of iterating towards product-market fit. Paul Graham's definition of product-market fit is when you've made something that people want. Marc Andreessen also has an amazing blog post about product-market fit, where he describes it as when the product is just being pulled out of you, when you no longer have to push the product on customers; they’re just pulling it from you.

But the problem with these definitions of product-market fit is that they're vague. They're also retroactive in that you have to already have product-market fit in order to know that you've reached it. So they’re not as useful for helping you figure out which features you can use, which features you need to build in order to iterate and to improve your product to get to product-market fit.

You may have heard of the app Superhuman, which is a super-fast email client. Well, the CEO published an amazing blog post a little while ago about how he was actually annoyed with this vague definition of what product-market fit is and how it was a lagging indicator that didn't help him predict product-market fit. It had only told him whether he achieved it or not. He wanted to create a real-time quantitative system that helped guide his company towards product-market fit, and of course, it involved talking to users.

He wrote a great blog post on this; you could just Google it. I won't go into it too much, but I would highly recommend reading the entire thing because it is fantastic. In it, he describes a process where, on a weekly basis, he asks pretty much all his customers—but it doesn’t even have to be your entire customer base; it could just be 30 or 40 users—this critical question: “How would you feel if you could no longer use Superhuman?” Three answers: very disappointed, somewhat disappointed, not disappointed.

He measured the percentage of users who answered the question “very disappointed.” These are the users who most value your product. These are the users who your product has now become a key part of their life; it's kind of weaseled their way into their daily habits. He read some analysis that said that 40 percent or more of your user base reports that they would be very disappointed if your product went away. On a weekly basis, that’s kind of the signal—that's the differentiation point that says if you get past this point, your product will just grow exponentially.

He evaluated a number of other successful companies and realized that the answer to this question was always around or above 40 percent. So again, I probably won’t be able to go into it too much more in detail, but I would recommend reading this blog post if you're at the stage where you're iterating and you actively have users that you can ask this question of. This can be an immensely useful thing for quantitatively determining whether the features that you worked on in the previous week were actually benefiting or adding to your product-market fit, or potentially detracting from it as well.

Some other great tips that we found at this stage are kind of a simple hack: ask your users for their phone number during signup because oftentimes you'll be looking at the data, and you'll be wondering why the data is showing this particular kind of learning about our customers. You may be thinking, in aggregate, like 20 percent of people have this problem. Sometimes it helps to just get on the phone and talk to one person who's encountering this problem. So I always encourage founders to put contact information, including phone number—which is like a direct connection to customers—pretty high up in the user signup flow.

The second one is don’t design by committee. You can't simply ask your users what features they want. You have to begin to understand whether those features are truly going to help make your product more sticky and more useful. You can do this through kind of the advice that the Superhuman CEO lays out in his blog post or you could ask other tactical questions like instead of asking, “Do you think users would be interested in using this new product or this new feature?” instead say, “Here’s an upgrade flow. If you want this new product, put your credit card information in; or if you want this new feature, put your credit card information in or pay more—even before you actually build out the feature.” This could help give you information about whether the feature you're working on is actually something that the users are going to use.

The third thing to do during user interviews at this stage is to remember to discard bad data. Some of the worst bad data that you may encounter is compliments. People may say, “Oh, I love the new design,” or “Man, this thing is really useful.” You may love that during the course of user interviews, but they actually are not useful information because it’s not specific; it's more of a general statement about your product, and it's not tactical. It's not giving you correct information on what you can change or what you can improve about your product.

The second main type of bad data that you may encounter is fluff; they're hypotheticals. These are generation Eric statements. Whenever you're in the middle of a user interview and you start getting onto hypotheticals, you know, “Here's what the product may look like in the future,” try to steer it back to specifics. Again, you're conducting a user interview not to pitch your product but to learn about problems or the issues that the user has faced in their past so that you can improve it in the future.

That's it! That was meant to be like a quick short dive into talking to users. I don't know if we have any time for questions. Cool, awesome! I'd love to answer any questions, but other than that, thank you very much! [Applause]