29 November 2013
29 November 2013

An alternative way to do customer interviews: the revelation of the JTBD framework

How to conduct a guided interview with the Job to be done framework

How to conduct a guided interview with the Job to be done framework – credits: http://www.flickr.com/photos/flibble/

I recently discovered the JTBD framework at Business of Software: what I learnt made me swear that I’ll use it from now on in every customer interview I need to do in order to understand their underlying needs and support our product pipeline. It is that brilliant.
It’s like a targeted, systematic guided interview process, easy to understand and to use. You should use it too.

Better than focus groups

Having been involved in User Research for a while, I have been moaning for years about focus groups and how they can often mislead research by creating a wrong view of the market.

If fact, the first time I was involved with one of these studies was as a design student, designing a new ‘form factor’ for a telephone. A manufacturer was looking at “refreshing the phone industry” which was up until then, quite grey and beige. They asked a set of users what colours they would like and how much they would pay for it. People suggested colours such as yellow, reds, blues, and so on. Later, when the session was finished, participants were thanked for their time with a free telephone and given a choice of whichever colour they’d like. There were the greens, and blues and the yellow available to them, but EVERYONE picked up a neutral grey (the risk-less option during those days). The conclusion was, as we know: don’t ask people what they want, but observe what they do.

You’ll get the idea in 4 min:

In contrast, the concept of the Job to Be Done has proven very useful to gather customer insights on the reasons why people purchase items and what influences their decisions. This is critical to making the right choices in successful product development or marketing.The concept was developed by Clayton Christensen (professor at Harvard, author of the “innovator’s dilemma”) and turned into a framework by Chris Spiek and Bob Moesta, original contributors to Clayton’s research.

The best and quickest way to get familiar with the idea, is to spend 4 minutes now listening to Clayton talking about how and why customers of a fast food restaurant “hired” milkshakes before 8 am. http://www.youtube.com/watch?v=s9nbTB33hbg.

What’s the framework like?

It is important to note the framework is designed to understand the motivations of people who have already bought something. It is not designed to find out what would motivate a prospect to buy something in the future – in the same way it’s not possible to ask people what they do because you’re better off observing them. If you interview enough people, you’ll see some patterns emerging that will allow you to make hypotheses on how to improve your tool or landing page to attract more customers.

Actually, there are two frameworks based on the underlying psychology behind any purchase process:

The force diagram.

 

Force diagram from the the JTBD framework. Captured for you by Red Gate UX

Force diagram from the the JTBD framework. Captured for you by Red Gate UX

It’s based on the fact that, left alone, people wouldn’t change anything in their current state, and they need things to make them tip over to become a customer:

  1. they need a good reason to change their behaviour(that includes buying something). This could be a problem of some sort (eg. their car is broken and it is more expensive to repair it than to change it) or a hope for a better life (driving with an open roof car would be sooo much better)
  2. they need to overcome two fears before they can proceed:
  • The uncertainty about the choice they have to make (eg. will life really be better with the new car? Can I justify it?)
  • Change the the habits of the present (eg. What will I do with my current car? The weather is never nice enough to drive without the roof)

The timeline

The timeline from the JTBD framework

This is based on the fact that the purchasing process starts way before the purchase actually happens (for the reasons highlighted above) and there is always a sequence of actions that lead to the action of purchasing. Understanding those triggers is like rewinding time.
Those two tools should be used to guide interviews and help you understand your audience.
Be careful, though: for it to be really valuable, you need to interview real customers (ie. people who actually bought your product, not those just thinking about it) because until they’ve done it, you won’t be able to tell if they are realistically going to do so. This would ruin your understanding of the last trigger.

The trick to making them valuable is to help the person to travel back and forth in time, and get them into a state of mind where they can remember and share every detail of their journey.

For this you need to:

  • Introduce yourself and break the ice before you start the interview (like in any user test). Start by saying you’ll spend 30 minutes to understand how they came to buy [Insert product name here], that there is no right of wrong answer, and that we’ll ask questions to put them in context.
  • Start with what is known (eg: the time of purchase) and get them to tell their story from there, going back and forth in the narration so you understand it all. Use sentences like: “Can you tell me when and where you bought [Insert product name here]?” “Was it the first time you thought about buying something similar?”
  • Use anchors in your language to help people recall what happened. Try and ask them about concrete stuff, like what the weather was like, what they were wearing on that day, etc.
    It might look irrelevant, but it’ll help to put them in context so they can tell you their story, and almost forget about your product: exactly what you want!

If you want some guidance on how to conduct an interview, you can listen to this interview, conducted in Cambridge, last summer during a SWITCH workshop organised at Redgate.

It shows what’s at play when someone needs to buy a portable phone, and it’s fascinating.

When the interviews are done, what’s next?

In theory, after a few interviews, you should start seeing patterns emerging that you can base some hypotheses on. For instance,

  • most of the people coming to your website did so after visiting another website,
  • most of them were trying to achieve something precise under time pressure,
  • most of them share a similar profile,
  • people couldn’t purchase your tool unless they had the approval from their boss,
  • or something similar.

From those hypotheses, you can infer new marketing messages (for example how much of a time saver it is to use your tool), or new material (for example, a crib sheet for someone’s boss) or even new features (for example the reporting tool that makes the boss happy)!

To conclude:

In essence, the Job To Be Done framework is a set of tools designed to conduct guided interviews in a systematic way, with the intent to understand the purchase process that every human being is confronted with when making a purchasing decision. From these qualitative, research interviews you can spot some patterns that should highlight product improvements or business insights. It is a bit tricky to start with, because you need to avoid biasing your questions, but it looks like it becomes easier with a bit of practice.

If you have conducted interviews like this, I’d love to read your comments.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Software development

SQL Server Configuration — the Redgate survey results

In the Foundry Team at Redgate, we’ve been looking into how data professionals manage the complexities of their wider data estates. One aspect of this is configuring, deploying and monitoring dr...

Also in Blog

Easing the transition from shared to dedicated database development

Working in dedicated development environments for the database is the ideal for many. This is the message we frequently hear throughout the industry from thought leaders, at conferences, and in many w...

Also about User research

UX katas - heuristic evaluation

The "extended" UX team sharpening their swords…

At Redgate, our software engineers run regular  “code katas”, workshops where developers practise their coding skills on simple problems, then...