- Eric Mijakovsky, a partner at YC and founder of Pebble, emphasizes the importance of founders maintaining a direct connection to their users throughout the lifespan of their company.
- Founders should not outsource user research to other members of their company, as the best companies are those where the founders themselves engage with users.
- The two essential tasks for starting a company are coding/building the product and talking to users.
- User interviews should focus on extracting information and data to improve the product, rather than pitching the idea or discussing hypotheticals.
- Founders should ask open-ended questions about the user's life and specific instances of encountering the problem they are trying to solve.
- Listening and taking notes during user interviews is crucial for gathering valuable information.
- Five recommended questions for early customer interviews include asking about the hardest part of the problem, the last time they encountered the problem, and why the problem was difficult.

- The video discusses the importance of asking specific questions to potential customers in order to understand their problems and develop a better solution.
- Customers are more interested in the "why" of a product rather than the "what", so understanding the value and benefits of a solution is important for marketing and sales.
- Asking customers about their previous attempts to solve the problem can help determine if there is a demand for the solution and identify competition in the market.
- Asking customers about what they don't like about existing solutions can help determine the features that need to be included in a new solution.
- Talking to users is beneficial at all stages of a company, especially in the idea stage, prototype stage, and after launching to iterate towards product-market fit.
- Tips for talking to users include starting with yourself, talking to friends and colleagues, executing unbiased and detailed customer interviews, and attending industry events.
- It is important to take notes, keep the conversation casual, and be mindful of the other person's time when conducting user interviews.

- The choice of the first customer is critical as it can determine the success or failure of a startup.
- A framework is provided to identify the best first customers before working with them.
- User interviews should extract numerical answers to three key questions about the customer: the cost of the problem, the frequency of encountering the problem, and the budget for solving the problem.
- Visualizing the answers as overlapping Venn diagrams can help identify the best first customer.
- User interviews can also be used to iterate towards product-market fit by asking a critical question on a weekly basis.
- The question, "How would you feel if you could no longer use the product?" can help determine the value and impact of the product on users' lives.
- A percentage of users answering "very disappointed" above 40% indicates a strong product-market fit.
- Asking for users' phone numbers during signup and avoiding design by committee are additional tips for this stage.

- User interviews can provide valuable information about user preferences and needs.
- It is important to discard bad data during user interviews, such as compliments that are not specific or tactical.
- Another type of bad data is fluff, which includes hypotheticals and generic statements.
- User interviews should focus on learning about past problems or issues to improve the product in the future.

- Eric Mijakovsky, a partner at YC and founder of Pebble, emphasizes the importance of founders maintaining a direct connection to their users throughout the lifespan of their company.
- Founders should not outsource user research to other members of their company, as the best companies are those where the founders themselves engage with users.
- User interviews should focus on extracting information and data to improve the product, rather than pitching the idea or discussing hypotheticals.
- Five recommended questions for early customer interviews include asking about the hardest part of the problem, the last time they encountered the problem, and why the problem was difficult.
- Asking customers about their previous attempts to solve the problem can help determine if there is a demand for the solution and identify competition in the market.
- Talking to users is beneficial at all stages of a company, especially in the idea stage, prototype stage, and after launching to iterate towards product-market fit.
- User interviews should extract numerical answers to three key questions about the customer: the cost of the problem, the frequency of encountering the problem, and the budget for solving the problem.
- Visualizing the answers as overlapping Venn diagrams can help identify the best first customer.
- User interviews can also be used to iterate towards product-market fit by asking a critical question on a weekly basis.
- A percentage of users answering "very disappointed" above 40% indicates a strong product-market fit.
- User interviews can provide valuable information about user preferences and needs.
- It is important to discard bad data during user interviews, such as compliments that are not specific or tactical.
- User interviews should focus on learning about past problems or issues to improve the product in the future.

YC Partner Eric Migicovsky outlines a framework for asking questions and collecting feedback from your users.

Transcript and lecture slides here: https://www.ycombinator.com/library/6g-how-to-talk-to-users

This lecture is part of YC's Startup School, a free online program and global community of founders. Register and join the community at https://www.startupschool.org/

Chapters (Powered by https://bit.ly/chapterme-yc) - 
00:00:00 Introduction
00:00:27 Best founders maintain a direct connection to users
00:02:03 Write code and talk to users
00:02:43 The Mom Test book - Three common errors when conducting user interviews
00:03:22 1. Talk about their life, not your idea
00:03:58 2. Talk specifics, not hypotheticals
00:05:16 3. Listen, don’t talk
00:05:56 Five great questions that everyone can ask during their early customer interviews
00:06:05 1. What is the hardest part about [doing this thing]?
00:08:16 2. When is the last time you encountered this problem?
00:09:15 3. Why was this hard?
00:11:14 4. What, if anything, have you done to solve this problem?
00:13:06 5. What don’t you love about the solution you already tried?
00:14:16 Three critical phases to a early-stage company – Talking to users is extremely beneficial
00:14:58 1.1. Idea stage - Find first users with problem
00:18:08 1.2. Idea stage – Tips
00:19:30 2.1. Prototype stage - Identify your best first customer
00:20:01 2.2. Prototype stage – Framework to identify your best first customer
00:25:21 3.1. Launched stage – Superhuman Product-Market Fit Engine (https://app.chapterme.co/player/video/19WpIbBhxJU)
00:28:24 3.2 Launched stage – Tips
00:30:55 conclusion

I actually started a company that went through Y Combinator back in 2011.

I am really excited to be here to talk about talking to users because this is 1 of the perennial things that you always hear about as 1 of the critical factors in starting a company.

The best founders maintain a direct connection to their users throughout the life span of their entire company.

They maintain 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 sales people, 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.

And that is 1 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 2 things that you must do in order to start your company.

You need to code or build your product and talk to users.

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 we probably all 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 to, 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 is 3 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 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.

Second mistake that we pretty much all make is we talk about hypotheticals.

We talk about features that we want to build.

We ask questions like, 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?

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, the path that led them to encounter that problem.

Ask them questions about their life in kind of more broader ways to extract context around how they arrived at this problem.

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.

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 return to your co-founders, you're bringing hard data, real facts about users' lives to the table.

I think that there are 5 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?

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 working, 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, 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 sitting in the computer lab, it's 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 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 on to 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 or confirm for you whether the problem that you're actually working, the problem that you're working on is actually 1 that real users feel is a pain point, feel is 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.

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, 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 1 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 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.

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 syncing tool that can keep all my files in sync, but they'll buy the why.

They'll say, well, this product will help with this exact problem that I had just 2 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 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 product.

Fourth question is What, if anything, have you done to try to solve this problem?

1 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 1 room to work on the project with 4 computers so that they could talk in real time to each other as they were working on the product.

Maybe they tried setting up as 1 of the top comments on hacker news posted during the original drop box launch.

Maybe they set up R sync and they already solved this problem with SFTP or something like that.

Again, you want to ask this question for 2 reasons.

1 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 1 is, what are the other competition out there?

What will your product be compared against as you end up rolling out your solution and offering it to end customers?

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, or 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.

Users in general are not great at identifying the next features that they want in the product.

Just like the old Henry Ford quote, 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 3 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 3 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 in the hands of any paying customers or any users yet?

And the third 1 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 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.

The best, you know, 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.

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 co-workers, to get warm introductions.

You don't have to talk to thousands of people.

Every good user kind of research strategy begins with just 1 or 2 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 to, 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 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?

They managed to get dozens of in-person, 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 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 just randomly started setting up meetings with potential users, and we met them in 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.

Take detailed notes, because like I said before, you don't 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.

Like I said before, you could just show up.

You don't have to have, you know, 20-minute blocks on your calendar scheduled for days on end of user interviews.

Like 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 100 user interviews all at the same time.

Just start with 1, start with 3, start with 5 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.

So you need to 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 just for that initial chat.

As you move past the idea stage into testing your your prototype with users, the next major kind of benefit that you can 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 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 to ask questions that extract numerical answers to 3 facts about the customer that I'm working with.

The first 1 that I want 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.

Second 1 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, quarterly basis, yearly basis?

The best problems that startups can target are ones that are encountered more frequently.

This is usually beneficial for 2 reasons.

1 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 they weren't, 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 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, or 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 3 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 3 questions that I outlined.

Imagine if you're working on like a super smart blender that's designed to produce the tastiest new fruit smoothies.

Let's say you're talking to McDonald's, French Laundry, and the Google Cafe.

You create a spreadsheet that simply has 3 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 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 1 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 customer, potential first customer for your product.

Well, 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 store services is 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 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.

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 definition for product market fit is when you've made something that people want.

Mark 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 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 built a, well, 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'd achieved it or not.

He wanted to create a real-time quantitative system that would help 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 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, 3040 users, a critical question.

How would you feel if you could no longer use superhuman?

3 answers, very disappointed, somewhat disappointed, not disappointed.

See all Y Combinator transcripts on Youtube

Eric Migicovsky - How to Talk to Users