/w=640,quality=80,fit=scale-down){kind=logo}
The goal of every interview is to learn. For problem interviews you want to focus on learning about the problem and prove your assumptions wrong wherever possible. I strongly recommend reading The Mom Test, it is short, practical and funny, what more can you ask from a book!
Who to interview
Try to only talk to people you think are early adopters, they might not be but you need to be honing in on who they might be all the time.
^ (Book Summary)
How to do a problem interview
Step 1: Prepare a semi-structured script
Step 2: Find people you think might be early adopters
Step 3: Run interview (much more detail in the video above)
Step 4: Re-listen to interview and analyse
Wireframe script ready for customisation
Section 1. Who are they?
- Collect any missing pieces of important information such as demographics and psychographics
Section 2. Could they be an early adopter?
- Do they experience the problem you are seeking to solve?
- How often?
- What solutions have they tried already?
- Why can't they avoid the problem?
- What happens before/after the problem?
- Have they asked anyone for help about this problem?
- Has the problem gotten better or worse over the past year?
- Do you know many other people who have this problem?
- How excited do they seem about the potential of solving the problem?
Section 3. Ask if you can follow up with them
- Add them to an email list of potentially interested people and keep these people well informed about developments. You can also get a rough sense of who is the most interested in this problem by who reads the emails.
Best practice
- Avoid hypotheticals, you need to speak with the interviewee according to where they are not where you want them to be
- Interview 1:1 when possible, people tend to loosen up faster and therefore open up more
- Focus on actual behaviour, not speculative or abstract feelings, people are not very good at predicting their actions, knowing what they want, or knowing their true goals. Your job is not to ask the person for the solution. It is your job to figure out the best solution, and then validate that your solution is actually right
- People love to talk about features and solutions, don’t let that dominate the conversation. Try to keep things factual. Get them to tell you stories about how they previously experienced a problem, if they tried to solve it (or why not), and what happened
- Go fishing where the fishes swim, it is not enough to wait for early adopters to come to you, you need to figure out where your early adopters are hanging out and go to them
- Hunt down things you were not expecting, don't fall into the trap on confirmation bias as sometimes people will tell you what they think you want to hear
- Ask open ended questions and if you do accidentally ask a closed question follow it up with 'why?' or 'tell me more about that situation?'
- Don't be afraid to ask 'why?' as long as your interviewee is not annoyed it is a good idea to keep asking why on particularly important points
- Ask them to be brutally honest (break the politeness barrier)
- Listen more than you talk
- Allow for silence, it can help to train yourself for silence before going into it, just find someone you don't know very well and ask them a question and then pause for 30 seconds after they have finished speaking (you can tell them what you are doing before you start the conversation)
- Ask if there is anything you should have asked, but didn’t
- Stop them talking when necessary, sometimes people will answer your questions in ways that are definitely irrelevant. When that happens politely interrupt them and say something like "Sorry, I just want to go back a bit, you mentioned x, could you tell me more about that?"
Things to avoid
- Suggest answers/lead interviewee
- Talk more than you listen
- Pitch the solution
- Be thinking of the next question to ask, instead of actively listening to the response
- Nod your head yes or no while the interviewee is speaking
- Ask only closed ended questions
- Schedule the interviews back to back, without any time in between to debrief
What end result are you aiming at?
Through this process you want to gain a deep understanding of a problem and understand what solution is currently being used to solve this problem.
Every solution to a problem requires an action, in other words; if nothing is done, nothing happens. Therefore if someone who has a problem is not willing to take an action then there is no point creating a solution.
As an example: Trying to cure cancer is a problem and it has many bad solutions such as chemotherapy. (I say bad because chemotherapy has huge negative side effects and is a last ditch attempt which has a low chance of success). Climate change is another example in the same vein, there are lots of bad/ineffective solutions, proving it is a problem worth solving.
As another example: A hospital has a problem in that it needs to disinfect things. There solution is to buy hydrogen-peroxide. Now let's say they spend $10 on hydrogen-peroxide, if your solution can deliver the same amount of hydrogen-peroxide for $9 all other things being equal you would expect them to switch. If they don't you could come to the conclusion that saving $1 is not a problem worth solving for them.
The key with this is to understand what the problem really is, in the above example it is purely a financial decision that is the problem and therefore might not be painful enough for the hospital to bother solving.
An example on a smaller scale; if someone tells you they want to be fitter or smarter or a better leader and you ask them 'what are you currently doing to make progress towards this?' and they say 'nothing' then you know it doesn't matter what solution you come up, because they won't take action. This usually means the real problem worth solving is something else. ie. a fixed mindset, not prioritising the change, etc.
You want to be able to express the problem you are solving as
[When _____ ] [they want to _____ ] [so they can _____ ]
Here is a good example and tutorial for how to probe for these kinds of insights