14 Interview Questions Pre- and Post-MVP [Templates]
Before you build a prototype, you want to learn as much as possible about people’s challenges. When you are testing it, you need to understand whether you're actually solving those challenges.
Contents
😤 What’s your single biggest challenge?
🧐 Talk me through the last time it happened
🧮 How much does this problem cost you today?
🗓 How frequently do you encounter this problem?
🛠 What, if anything, have you done to try to solve this problem?
😕 What don't you love about the solutions you've already tried?
😒 How's your experience with the product been so far?
💯 Have you shared the product with anyone?
🤥 What don't you love about it?
🤨 Is there any part of the product you find confusing?
🔍 Is anything missing that you were expecting?
💬 Is there anything I should have asked you today that I didn't?
No matter the product you’re building, you can benefit from talking to users.
If you ask the right questions and leave space for the conversation to unfold organically, those conversations will provide you with actionable and unbiased insights.
The main reason why you should bother conducting interviews with (potential) users, is that you need to test your assumptions. Without feedback from users, all you have is assumptions. Even if you have experienced the problem you are solving yourself and you use your own product, one data point is not enough.
Conducting interviews is one of the best ways to find out if your assumptions are right or wrong, and to understand really well why. That way you spend less time building things that people don’t need.
The questions you need to ask vary depending on the product development phase you’re in and your research goals.
In this blog post, I’ll walk you through how we do it at FYI and share the key questions we ask.
🙅 What not to ask
Interviewing people is only valuable if you know how to do it. There are three common mistakes people make during interviews that decrease their chances to collect valuable data. Rob Fitzpatrick does a fantastic job analyzing them in-depth in his book The Mom Test.
The first one is asking leading questions. For example, avoid asking, “So your problem with documents is about sharing right?” Instead, ask: “What’s your biggest problem with documents?” Keep the questions really general, and avoid making them suggestive in any way.
Another mistake is asking questions that give you misleading information. For example, avoid asking about generic behavior (what do you usually do?) or behavior in a hypothetical future (what would you do?). Instead, ask about their actual behavior in the past and dig into the details (when was the last time you were looking for a document and you couldn’t find it?).
A third mistake is talking too much about your idea or product. Your goal is to hear the opinion of the person you’re interviewing, not to sell something to them. So try to restrain your interest in talking and really listen.
Conducting interviews successfully boils down to asking the right questions and listening the rest of the time.
So what are the right questions to ask?
It varies, depending on the stage your product development is in. Before you have a prototype, you want to learn as much as possible about people's challenges. That way, you improve your chances of making something people need.
Let’s go through the questions you may ask in that earliest stage.
😤 What's your single biggest challenge?
This is one of our favorite questions at FYI. We start interviews by asking people about their role at their company and their responsibilities. Then we move to this question: “What's your single biggest challenge when it comes to [the thing we're trying to solve]?” For example, “What’s your single biggest challenge when it comes to finding documents?” Another way we may phrase it is, “What’s the hardest part about finding documents?” You want to understand what the specific things are that they find difficult.
Your product is just a means to an end for the customer: they’ll buy it if it solves their challenges and improves their life.
An example that I find valuable is the invention of the car. Before the car was invented, someone who wanted to go from Boston to New York had two options: go by horse-driven coach, which would take about a week, or by train, which would take about ten hours (assuming there was a connection) but meant they had to depend on the train schedule and stops. With a car, people could travel the same distance in about six hours and start the trip from their house at whatever time they wanted. They weren’t just buying a car – they were buying the convenience to travel.
“Jobs-to-be-done” is a popular framework that helps understand how products matter to customers only as solutions to their challenges. The key idea is that people hire products to get a job done, i.e. to solve a challenge they have. The product’s actual features don’t matter as much as the outcome that the product delivers. Professor Theodore Levitt from Harvard Business School famously said, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
🧐 Talk me through the last time it happened
With the next question, we want to learn more about the circumstances in which the person we’re interviewing encountered the challenge most recently. It’s also a way to make sure we keep the conversation focused on their actual behavior (what they actually did) as opposed to generic behavior (what they think they usually do).
Leveraging the example of the car invention, you’d want to know when was the last time the person you are interviewing had to travel a long distance and what they did.
💔 What were the consequences?
You don't only want to know about the challenges, but also what happened as a result of them.
Aim to understand what the second-order effects of experiencing the problem were; its consequences and the consequences of those consequences. Dig into the stories about when things went wrong until you find the full pattern of pain. It will lead you to the most surprising insights.
When we interviewed people about their challenges with finding documents, we learned that those challenges were impacting their reputation at work. The consequence of not finding a document during an important meeting is that a decision gets delayed, and the consequence of that is that your boss and your team may change their perception of you and your work. Learning about these implications gave us a more accurate understanding of the importance of the problem.
Continuing the story of a person that was traveling long distances before the car was invented, the consequences might have been that being on the road for so long was preventing them from spending time with their family, and their relationships with their partner and children were suffering from it.
🧮 How much does this problem cost you today?
Is it costing people time? Is it costing them money? What’s the cost of having to deal with the problem today? It doesn’t have to be a financial cost. And it doesn’t have to be a cost they’re sustaining today. It may be an opportunity cost – that is, an opportunity they are missing out on because of the problem. What’s important is that they quantify the consequences of having the problem. You want to get to a number here, and it may be more or less difficult depending on the problem you’re researching.
At FYI, we learned that the cost of not finding documents is a lot of time wasted. Here’s a quote from one of our interviews: “I believe I've spent at least 20 minutes every day trying to find the right documents.” Five days a week, 52 weeks a year, that's over 80 hours a year wasted on looking for documents. That’s the kind of quantitative information that validates you’re tackling an important problem.
As for the long-distance travel analogy, a way to quantify the consequences of dealing with slow means of transportation is the amount of time spent on the road.
🗓 How frequently do you encounter this problem?
You want to learn about the frequency of the problem for two reasons. One, because the more the customer is experiencing a problem, the more receptive they’ll be to a solution. And two, because if the problem happens frequently, you’ll get more chances to test if your product actually solves it. Again, try to get as specific as possible here: do they encounter the problem on an hourly basis, a daily basis, a quarterly basis, a yearly basis?
🛠 What, if anything, have you done to try to solve this problem?
We want to know what they’ve already identified as potential solutions. What is it that met their criteria for a potential solution to the problem they have? The reason we want to find out is that’s a starting point. They haven’t found a full solution, but they might have found a partial one. It’s also helpful to know what their thinking process was like.
How do they think when it comes to finding a solution for their problem? What are their requirements—i.e the criteria that they’re looking to meet?
Bob Moesta talks about two forces that make people try a new product. Their challenging circumstances push them to explore new solutions. Some of those solutions will be attractive to them because they meet their criteria. You want to learn everything about these two forces. When did they become motivated to find a solution? What convinced them to try a specific solution over the alternatives?
😕 What don't you love about the solutions you've already tried?
Any solution the customer tries either improves their life or doesn’t.
If it does improve their life, they’ll be satisfied with the money they spent and tell their friends. If it does not improve their life, or not as much as they would like, they’ll try another solution. They’ll keep trying until they find the right solution for them; that is, until their situation improves so much that they are satisfied.
You want to learn about why they were dissatisfied with the solutions they’ve tried so you can create a new one that fills the gap.
You’re not interested in the features of those solutions. You’re interested in how they addressed the customer’s challenges and what part(s) of the challenges they left unaddressed.
When you ask people about their experience with a product, they naturally start talking about the features they like and don’t like. And often, they suggest new features the product could or should have.
That kind of feedback is valuable, and it’s what you’re asking for with this question. However, you need to go a level deeper and ask them further questions if you really want to understand the underlying challenge that a certain feature solves, could solve, or hasn’t solved.
When you are creating a new product, you need to be good at doing two jobs: the therapist and the inventor. And you should not try to do both at the same time. During interviews, you need to be like a therapist and focus your efforts on understanding everything you can about the challenges the customer is experiencing. Only after you’ve got clarity on the customer’s challenges, you can put your inventor hat on and come up with a solution.
This is best illustrated by the classical Ford example. If Henry Ford had asked people what they wanted, they would have said faster horses. His first job was to understand that the problem people wanted to have solved was that the existing means of transportation were too slow. His second job was to invent the car to solve their problem.
😒 How's your experience with the product been so far?
As you move past the early research stage into testing your prototype with people, the questions you want to ask during interviews will change because the goal of your interviews will change.
Your focus will move from the challenges people experience and the value competitive solutions are delivering to them, to the value that your product is delivering to them.
You want to know what experience people are having with your product. Is it making their lives better? Is it meeting their expectations?
Start with a simple question and see what people bring up. For example, ask, “How’s your experience been with the product so far?” Most likely, the person you’re interviewing will start talking about features. Listen, and then dig deeper into the key issues they’re having with those features, so you can understand the motivation behind them. And if they mention something they love, dig deeper into that too and figure out why they love it.
One of the problems we were seeing during our early research for FYI was that documents were spread across different apps, so the first prototype we made was a search bar that let people search across apps. Here's a screenshot of how it looked like:
After one week we interviewed people about their experience with the product...
The feedback we got was that they couldn't always remember the name of the documents they were looking for, but they could remember if another person was involved who collaborated with them on the doc. This information led us to the assumption that it was helpful for our users to have a list of top collaborators in the interface to see the documents they had in common with that person.
We received great feedback about that next interaction, so we kept that part of the product.
Our early users were quite talkative, so we didn’t have to follow a script when interviewing them about our prototype. But you don’t always get this lucky. In the next paragraphs, I will list a few more questions to help you guide the conversation with people who have tested your prototype and are willing to give you feedback.
💯 Have you shared the product with anyone?
This is one of the best questions you can ask post-MVP. If somebody shared your product with their friends, that’s the strongest type of endorsement you can get. If they didn’t share it with anybody, they probably don’t like it too much. Asking this question is also a great way to help the person you’re interviewing to be honest about their feedback. They may start explaining why they did or didn’t share it, and what they do and don’t love about it. If that doesn’t happen organically, you can get that information by asking them more direct questions.
🤥 What don't you love about it?
If you ask more direct questions, people are forced to take an extra moment to reflect on their experience with the product and bring up any issues they have. If they haven’t already shared what’s preventing them from loving the product, they’ll feel free to do it once you ask them directly. People tend to be hesitant about giving negative feedback, but if you explicitly ask for it, you make it easier for them to do so.
😻 What do you like most?
Here you want to learn about the parts of the product that work. What is it that you definitely shouldn’t change? And why?
🤨 Is there any part of the product you find confusing?
A confusing experience may prevent people from loving your product. Ask this question directly to find out if there’s anything that creates confusion. These types of issues are important and usually easy to fix. They’re low-hanging fruits in your list of product improvement ideas.
🔍 Is anything missing that you were expecting?
Is there anything else the person you’re interviewing didn’t mention and they would like to have in the product?
Maybe they forgot about what their expectations were. Help them remember and tell you what their ideal solution looks like and how your current solution compares to that.
If you stop at the surface level, the information you’ll get out of this question will be a list of feature requests. Your job is to understand the problems they want those features to solve and then find the best way to solve them.
💬 Is there anything I should have asked you today that I didn't?
Finally, there’s one question that’s useful in any interview. Regardless of whether you’re researching people's challenges or the experience they’re having with your product, the golden question is: “Is there anything I should have asked you today that I didn’t?” With this one you make sure you didn’t leave any stone unturned and that you get the full picture of what you’re investigating. It’s a question that often leads to pleasant surprises and an opportunity to talk about topics that weren’t covered in the interview.
To summarize: Ask the right questions and listen carefully.
Leverage the questions I shared in this blog post, then put your mic on mute, and write down everything you can learn from the other person.
To help you get started I created two templates that you can copy to your Google Drive and use for your interviews:
Go talk to people and good luck!