JTBD — Getting from in-depth interview to outcome statements

One of the common questions I hear in the JTBD process is how to get to customer outcome statements from your in-depth interviews.

For me this really is the most critical stage of the whole framework and requires real discipline to remove any bias on current products or solutions they might use.

Here are some tips I’ve tried myself after reading various books and blogs. I hope you find them useful. It take a few goes, but I promise it does become easy if you stick with it and definitely worth the effort in the long term.

To help explain using a real example, I’ll use the following functional job to be done throughout:

Listen to music privately

This is a job most of us like to execute when we need some escape from the noise of daily life. The job could of course be abstracted to “Help me escape from daily life”, opening the range of potential solutions, however I won’t go there here and I’ll write another blog on defining the core job soon.

Focus on Outcomes, not Solutions

The great thing about outcomes, is that later on they lead directly to solutions. But you must avoid the temptation now. It takes some practise, but innovation only truly works when you learn to detach your mind from how things are done today.

Tune your ear to hear their pain points

Focus on the underlying job process and listen carefully to hear the difficulties they face along the way. e.g. when I decided I want to listen to music privately, I might be frustrated at how long it takes to untangle my earphones. Or I might find the left earphone isn’t working because the cable is severed.

We’ve all been here right?

Zoom in on these pain points. Ask how they would like the step ideally performed if there were zero limitations.

You are getting closer to writing a couple of outcome statements. But first let’s try to define the structure to express it better.

There are generally 3 types of job outcomes

I have found all outcomes can nicely fit inside 3 categories. When executing a job, people are always trying to:

1. Eliminate time
2. Eliminate inefficiencies, and
3. Avoid problems.

If I listen to music 5 times a day and have to untangle my earphones every time, that pain point may even increase on each iteration. So what I really want is to reduce the time it takes to setup and also eliminate the inefficiency of the cables keep getting tangled again and again. If I plug my earphones in I want to avoid problem of only one ear working.

Some basic grammar rules

Below are some rules to help express your outcome statements in a uniform way so you can compare them fairly when weighing up what to solve for later.

The syntax is:

Minimise the [“time”|“likelihood of” |”likelihood that”] [object of control] [contextual clarifier]

I’ll explain each part below:

• The type of improvement required — use the word “minimise” as customers always trying to reduce process, not increase.
• The unit of measurement : [“time”|“likelihood of” |”likelihood that”] (3 categories above)
• An object of control — this explains precisely what the customer is trying get done faster (time), more predictably (avoid problems), or with higher throughput / output (eliminate inefficiencies).
• A contextual clarifier — this identifies the conditions or circumstances a customer may be encountering. While it can often be left out, it helps to ensure the outcome statement is not misinterpreted.

Some examples of outcome statements

Now we have some rules, let’s try to apply them to the pain points we discovered above. For the frustration of untangling earphones, we may want to write an outcome statement related to time like:

Minimise the time spent to start listening to music

Firstly, notice there is no mention of earphones. That is a solution and constrains our thinking. The category is ‘time’, the object of control is ‘listening to music’, context ‘start’ indicates that it is during the setup stage of the job execution and we begin the sentence with ‘minimise’.

We might also write another to capture the inefficiency of the tangled cable pain point as:

Minimise the likelihood of having to do manual tasks before I can listen to music

Another few examples related to the problem of severed cable pain point resulting in the left earphone not working:

Minimise the likelihood that there is uneven sound in ears when listening to music

Minimise the likelihood that I have poor sound quality during playback

Beware: What you need to remove from your statements

Remove both of these from outcome statements:

• Remove Ambiguous words like ‘easy’ and ‘reliable’ as they mean different things to different people and can be removed by asking what they think are easy or reliable to drive to an objective outcome. E.g. If they person says ”I want it to be easier to start listening to music” you could ask “what do you want to be made easier?” “It takes too long to untangle the chord” until you can get to a more objective statement like “I want to reduce the time it takes to begin listening to music.”
• Remove Solutions words such as those that describe specifications or constraints e.g. if they say “I want stronger chords on my earphones” (stronger chord is a solution.. but why do we need chords at all? And earphones? What if technology has now evolved to just insert plants in my ear?). Get them back to the process and how they’d like it to be ideally and you’ll find a more objective outcome statement like “Minimise the likelihood that I can’t hear sound when trying to listen to music”.

Finally.. confirmation

Confirm each outcome statement with the interviewee to eliminate guesswork e.g. “Do you mean that you want to minimise the likelihood that you can’t hear sound when trying to listen to music?”

Then what?

What do do with all these outcome statements? These go into a survey so you can see which pain points are shared across the market segments. This ultimately leads directly to your market and product strategy which I'll explain in this next blog.