How to Talk to Users — Eric Migicovsky | YC 

YC  Partner  Eric Migicovsky  shares a framework for asking questions and collecting  feedback  from your users. 
Watch this if: 
  • you haven't started talking to users yet 
  • your users are asking for conflicting features 
  • you aren't getting valuable information from talking with users 
 
Transcript 
Eric: Hi everyone. My name's  Eric Migicovsky . 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 maintained a 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. 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." And 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  search  your company. You need to code or build your  product  and talk to users. So, 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 kind of the process in which probably I'll go through where we want to tell our parents about the company that we're working on. And we think that by talking to people that love us and want to support us, we're actually extracting good or useful information about how we could 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, his 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 . So, 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? Or 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 users, the path that led them to encounter that  problem . Ask them questions about their  life  in more 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. The third trap that we pretty much all fall into is that we talk, we talk a lot. We're 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 , the 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've returned 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 a 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 . You want to learn more about how other people are sharing  files  so that you can learn, you know, "Are there 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 sending the computer labs, the perfect context for asking that kind of  question . And you begin an open-ended conversation, trying to extract information about how that person currently works on group projects together with friends. Hopefully, you'll learn about specific pain points that they have. Like, they log on to 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 synchronizing of shared  work . Maybe you're both working on the exact same document at the exact same  time . 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're 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 point. It feels 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 timeframe, 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 or their project with other folks, why was that hard? What were the specific things that they encountered that were difficult? The reason why you want to ask this  question  is because 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 number one  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 on 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 to this  problem . 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 the what, 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 sinking  tool  that can keep all my  files  in sync." But they'll buy the why. They'll say, "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, why was this past  problem  that you encountered so hard? May actually inform your  marketing  or your sales copy as you build out the rest of your kind of  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? 
So, 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 as one of the top comments on  Hacker News  posted during the original  Dropbox  launch. Maybe they had set up auto sync and they had already solved this  problem  with an SFTP or something like that. 
Again, you want to ask this  question  for two reasons. One is to figure out whether the  problem  that you're solving or you're working to solve is even really something that people are already looking for solutions to. And the second one is what are the other competitions 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. "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 begin understanding what the features are that you'll build-out for your better solution to the  problem
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, you know, Henry Ford  quote , you know, "When we were developing the automobile, our users would have wanted a faster horse rather than a 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 at pretty much all stages of your company but there's 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 into 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? So, 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, 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. People come to me and 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, is to talk to coworkers to get warm introductions. It doesn't take a lot of people. You don't have to talk to thousands of people. Every good user kind of 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 actually selling products to firefighters. And they realized that cold  email  introductions was just not working, was not a way that they could get through to 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?" And you know what? It worked great. They managed to get dozens of in-person, you know, 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 hand. 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 high 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 like randomly started setting up meetings with potential users. And we met them in like the coffee shop outside of 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 the stage, take notes. Take detailed notes because like 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 cofounder. 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 could just show up, you don't have to preplan. 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. Like, honestly, you'll learn so much through the first 5 or 10 user interviews that, you know, your process will dramatically improve from those first interviews to the next batch. So, don't feel like you have to do 100 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, you know, 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 10 to 15-minute long first interview and that might be all the  time  you need just for that initial chat. As you move past the idea stage into testing your prototype with users, the next major kind of 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 want to get to the bottom of is how much does this  problem  cost them today? 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, 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 customer is feeling 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, a  problem  on the  industrial  assembly line. 
If you're talking to the operator, the person who's actually there on kind of 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. So, that's someone above them in the office or 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 kind of numerical answers to the three questions that I outlined. So, let's take a quick example. Imagine if you're working on like 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. 
This data 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's 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  restaurants . 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, you know, 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
Well, even though the cost of a new smoothie at McDonald's may not bring in, you know, a large  dollar  amount per transaction, they have a ton of stores and each of those stores services at a ton of people. And on top of that, you happen to get a warm introduction to the like chief  food  officer of McDonald's, which I'm not even sure they have but that person actually controls like a multibillion-dollar budget. And if they wanted to solve this  problem , they would have the authority and they would have the budget to do so. And so, you put that information in your spreadsheet and you actually do like a simple stack rank that just pulls the best answers to those questions up to the top. And you can use this framework for kind of pulling together all of the information that you get from various user surveys to find the best customers. 
The last stage before  product-market fit  that can benefit from user interviews is actually the process of iterating towards  product-market fit Paul Graham  's cut definition for  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 need to build in order to iterate in order 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 only told him whether he had achieved it or not. He wanted to create a real-time quantitative system that had 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 can just  Google  it. I'm just going to kind of touch on it but I would highly recommend  reading  the entire thing because it is fantastic. But 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, you know, 30, 40 users, a 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 if 40% or more of your user base reports that they would be very disappointed if your  product  went away on a weekly basis, that that's kind of the signal. That's the differentiation point that it says, "If you get past this point, your  product  will just grow exponentially." And he evaluated a number of other successful companies and realized that the answer to this  question  was always around or above 40%. 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've found at this stage is kind of a simple hack. Ask your users for the phone number during signup because oftentimes you'll be looking at the data and you'll be wondering, you know, "Why is the data showing this particular kind of  learning  about our customers?" And you may be like thinking in aggregate, like, you know, 20% 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, you know, "Will users 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." Or, "If you want this new feature, put your credit card information or pay more." Even before you actually built out the feature, this could help give you information about whether the feature that 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 kind of 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 your 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. These are hypotheticals. These are generic statements. Whenever you're in the middle of a user interview and you start getting onto this hypothetical, you know, "Oh, 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 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. Well, I'd love to answer any questions but other than that, thank you very much. 
Notes that link here:
Please sign up or log in to add comments and/or write your own notes and articles