How to Talk to Users, Eric Migikovsky
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.
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.
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, “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.
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?” 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… “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.
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?”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.
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? 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.
idea stage before you’ve even begun developing any of your product
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
third one, which is after you’ve launched and you’re iterating towards product-market fit
At the idea stage … 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. 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.
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.
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.
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.
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 third thing that you want to get to the bottom of is how large is their budget for solving this problem? 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.
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%.
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.
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.