If you gather evidence that supports your problem assumptions (validation), you can pat yourself on the back and move to the next step of defining and testing a solution with a Solution Interview:
Inspired by the Scientific Method, the search for Problem/Solution fit starts with creating a model — specifically a business model using a Lean Canvas. On that Lean Canvas, you take your best guess at articulating a customer and problem hypothesis. You then get outside the building and attempt to validate/invalidate your assumptions using the meta-script below.
The only reliable way to gather this evidence is by exploring what customers did in the past or will do in the present. Asking them what they’ll do in the future, e.g., “Will you use…”, puts you in the land of biases and should be avoided.
We have shifted to this approach entirely — not just to find problems at the ideation stage but throughout the product development cycle. The main difference is that during the ideation stage, you explore forces that drive customers to existing alternatives, while later, you explore forces that drive customers to (and away) your solution.
Before you can build the “right” solution for your customers, you must understand the “right” problem. In my first book, Running Lean, I outlined a Problem Interview script for uncovering problems worth solving. In this post, I will present an updated script that improves upon the first.
Its a learning tool: based on what future customers say, we will be able to refine our Business Model. So its important to clear our minds of the Solution at that point, and to only focus on what we are solving, who is the competition, and who has the pain.
This is where we try to understand who this customer is – is he/she in the segment we target? an early adopter?
Note: In retrospect, this first draft shows how we are influenced by our vision of the solution. Most notably, the wrapping up sounds like a pitch, which is not fair since we announce that we have nothing to sell at that point. After a few interviews, we will follow this script more loosely, and focus more on the actual customer pain points.
A Problem Interview is supposed to verify falsifiable hypotheses. Based on our Risk analysis, we formulate the following hypotheses:
In order to find it out, the cheapest and fastest way to test our assumptions is to meet potential customers, and see how they react to the Problem.
100 DOS AND DON’TS FOR CORPORATE INNOVATION
To help you avoid stepping into these all too common pitfalls, weâve reflected on our five years as an organization working on corporate innovation programs across the globe, and have prepared 100 DOs and DONâTs.
Fig. 3 – Outline of a solution interview script – Taken from: Ash Maurya – Running Lean
With solution interviews, I’ve learned over the years to listen a lot when it comes to exploring solutions, as you don’t want to guide your customers towards a solution that you’ve got in your mind or have a prototype for. You might want to have a quick look at this great article titled ‘3 common mistakes during user interviews’ or my earlier blog post about effective user interviews to find out more common mistakes.
Reading Javier Sandoval’s post titled ‘You’ve Been Doing Your Customer Problem Interviews Wrong’ was a great a reminder of some common mistakes that can easily be made when conducting problem interviews (see Fig. 2 below). For example, I know from experience how easy it can be to loose sight of learning and focusing purely on validating assumptions instead.
Main learning point: The distinction between problem and solution interviews is a very helpful one. Whether you do one or the other (or combine the two) thinking upfront about the nature and outcomes of your interviews will help ensure you ask the right questions, listen and avoid common interview ‘pitfalls.’
Fig. 2 – Common mistakes when conducting problem interviews – Taken from: http://blog.javierasandoval.com/youve-been-doing-your-customer-problem-interviews-wrong