Before you can build the “right” solution for your customers, you have to 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’m going to present an updated script that improves upon the first.

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 script starts out by setting the stage and setting a problem context, but the heart of the interview is around exploring your customer’s worldview because that’s where you gather empirical evidence that either supports or refutes your case.

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.

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:

If, however, you don’t uncover evidence that supports your assumptions (invalidation), you have to dig deeper for new problems worth solving. This is where people stumble.

Here are a couple of reasons why:

• First, guessing at “real” problems at the outset is really hard given our in-built bias for our solution (the Innovator’s Bias). Most of us unconsciously frame (or fake) problems around the solution we already want to build and then attempt to seek just enough evidence to convince ourselves we are on the right track.
• Next, if you start with a non-problem, even though you can often see invalidation pretty quickly during the interview, recovering from it isn’t always easy. Limiting the problem context upfront limits your maneuverability and it’s quite possible to leave the interview without any actionable problems to go after.

This is why I updated the Problem Interview script.

The Updated Problem Interview Script

Here’s what I changed:

First, let’s talk about what I took out.

Problem Rankings are subjective at best

I found the Problem Ranking step never led to any useful insights mainly because rankings are subjective and more important, customers don’t often understand their own problems well enough to rank them in the first place.

Next, I refined the framing around early adopters and problems.

Triggers versus demographics define your early adopters

The key question when searching for early adopters is not asking “who” but “when”. In other words, behavioral triggers or psychographics are much more actionable than demographics.

In the photo sharing for parents case-study in Running Lean, while I found moms to do more of the sharing than dads (demographics), becoming a first-time mom (psychographics) correlated much higher with a desire for sharing photos with others.

Outcomes and jobs versus problems afford more discovery

While setting a problem context upfront focuses the conversation, subsequent invalidation causes thrashing. Limiting the problem context is better suited for the Solution Interview when you have more evidence/confidence and the framing is more around pitching than learning.

During the problem interview, where discovery is the goal, a better framing is around triggers and desired outcomes.

Triggers create a desire for better.

Taken together, the trigger and desired outcome create anchor points for the customer journey story you want to learn about.

Something to note here is that while customers desire something better, they often don’t know how to measure and/or achieve better. But uncovering whatever their definition of better is, will nonetheless be key towards crafting your own unique value proposition.

Example: When entrepreneurs get hit with an idea, they might define securing funding or building/launching their product as the desired outcome.

If you’re a longtime reader, you know that I consider an investor-first or build-first strategy as backwards. The objective during the Problem Interview isn’t convincing them otherwise (yet) —but getting their worldview.

Existing Alternatives and Current Solution

Triggers and desired outcomes create the consideration set your customers use to search for alternatives and select solutions. That is what you explore next.

When you frame the context in terms of outcomes and jobs-to-be-done, versus solutions, you should always be able to find existing alternatives.

Inertia, Friction, and Next Summit

For each solution (starting with their most recent), you want to get the customer’s story on how they found, selected, used the solution, and what’s the next goal for them :

Inertia represents obstacles and roadblocks that hold the customer back at the time of choosing a new solution. These can be caused by existing habits or anxieties that surface when considering a new direction.

Friction occurs further down the road. Friction represents obstacles and roadblocks that get in the way during usage. These can also be caused by old habits that have to be broken in order to effectively use the new solution, and anxieties or frustrations created when adapting to the new solution.

The last step is assessing how well the job was done with their chosen alternative. Were they better off than when they started? And what’s next for them? This helps paint the bigger context for your customer and helps you visualize how they perceive their progress roadmap.

The answers to these questions is where you’ll find problems worth solving. I call this the backdoor approach to problem discovery because you don’t lead with problems but rather extract them from customer stories.

Here’s the updated Problem Interview script:

The rest of the interview script is the same as the original. You wrap up the interview by asking your customers for permission to follow up and referrals to others you can interview. And finally you document your results.

As you’ve probably noticed by now, the customer forces diagram (that I’ve also previously written about) not only helps you visualize the interview script, but it can also be used to document the results of your interview giving you a tangible artifact that you can create after each interview.

That is why I rolled the visual into a new Customer Forces Canvas that you can download below and also use to document your results:

While the best way to fill the Customer Forces Canvas is after an interview, some of these terms may still be foreign to you like the difference between inertia and friction or habits and anxieties.

So I recommend filling one of these out on your own by putting your prototypical early adopter in the driver seat.

Here’s an example of one filled out for an early stage entrepreneur:

Got Feedback?

Did you find the new Problem Interview script and Customer Forces Canvas helpful?

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 own solution.

CLICK HERE to download the Customer Forces Canvas

And I’d love to hear if/how you put it to use.