Exercise 1. Write your interview structure
An interview structure will guide all the conversations you might have with any potential users of your product. It will help you structure what you’re trying to find out, guide your conversations as you’re having them, and not let you go off-topic. Once you get to the analysis part, you will also discover you’ll have an easier time drawing comparisons and getting to some conclusions, as all your conversations will have been around the same topics.
What you need:
A big picture of the problem you’re researching
A doc to write this down on and have it available later on your preferred device
What to do:
Write down your interview goals
Write down the gaps in knowledge or assumptions you have regarding the problem for which you’re building the problem. Here’s just a list of topics that might help you out and guide you.
- The existence of the problem
- The pain points regarding the problem: What time or budget are they currently spending to solve this problem?
- Alternative solutions to the problem
- Procedure or policy bottlenecks (internal /external)
- Audience validation: Who are the people who encounter this problem?
- Distribution channels: How do people get their product recommendations in this industry?
Write the questions you want to cover in your interview.
To help you out, we’re including a series of examples for the previous topic. Your challenge will be to focus your interview on the key questions that will help you discover the most insights, while also keeping your conversations under 45 minutes.
How do you feel about [the problem you’re researching]?
What are the implications of [the problem] for your family/your company/your community?
Could you walk me through the process of coming across and solving [the problem you’re researching]?
How often do you come across [the problem] in an average month?
How much time do you spend on [the problem you’re researching] in an average month?
How much money do you spend on [the problem you’re researching] in an average month?
Have you tried something else to solve [the problem you’re researching]?
Have you tried making something yourself?
Have you tried paying someone or paying for something?
Are there any internal procedures in your company that are slowing you down in solving [the problem you’re researching]?
Are there any legal requirements that are slowing you down in solving [the problem you’re researching]?
Can you tell me about yourself?
Where did you find out about the solutions you’ve been trying until now/that you’re working with at the moment?
If you need recommendations in the industry of [the problem], who do you go to?
How do you follow news in the industry?
While you work:
Work from broad to narrow
You don’t have to write down a very strict script that you’d like to stick to. In fact, it’s better to write down broader questions, and point out specific topics you want to touch on as the conversation flows naturally.
Base your predictions on past behaviours
Humans are rather unpredictable creatures, so it’s more reliable to ask them of past behaviours to have a better understanding of how you might fit in their future patterns. Asking someone hypotheticals like ‘How much would you spend on fixing this problem?’ or ‘How much time would you invest in fixing this?’ is no guarantee that when given the opportunity, they’ll actually invest the money or the time to do it. But if someone is already paying money or spending time to fix something that frustrates them, they’d just redirect those efforts towards another product or service – like yours.
Don’t pitch your product yet
It’s not about you and your solution, it’s about your future users. And the best way to get in their shoes is to put your product concept on a back-burner and just focus on their perceptions of the problem, its implications and how it affects them day-to-day. If you learn about the problem, if you get to love the problem you want to solve, you’ll have an easier time building a product and changing a product that fits your users’ needs.