Eric Migicovsky’s five questions you can ask in every user interview

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 and you want to learn more about how other people are sharing files so that you can learn 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 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 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 one 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, 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, 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 these 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, 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 syncing tool that can, that can keep all my files in sync. But they'll buy the why. They'll say, well, this exact, 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, as you build out the rest of product. 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 customers, 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 rsync and they had already solved this problem with 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 competition 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 ask the 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, 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, 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 figure out what the diff the differential between your new solution and the existing solutions already in the market will be.