I love JTBD, it’s a user understanding; marketing product and feature planning process and a set of tools based on user needs and behaviour.
Jobs to be Done is about framing the problem not the solution.
That really appeals to me with my user experience background as it’s a user-centred design framework with a sprinkling of MBA thinking.
I’ve used it on a number of projects with different teams and offer JTBD training and consultancy. I know JTBD’s strengths and weaknesses.
A 20 minute talk from me on the basics of JTBD.
What is Jobs to be Done? A definition
Jobs to be Done is a framework containing both the processes and tools to understand user needs and plan innovative products and product features to meet those user needs.
The great thing is that it covers the whole user journey from users’ thinking they have a need for the product through to switching from a competitor to using and moving on from the product.
From a A Script To Kickstart Your Jobs To Be Done Interviews
The two schools of JTBD
The problem with JTBD is that it’s not easy to grasp and worst of all there are two competing and often incompatible JTBD approaches. Think VHS and Betamax; both play stuff on your TV but they way they approach JTBD is different.
In the red corner we have have by Clayton Christensen, Bob Moesta and others as well as the folks at Intercom. Their approach is practical and great for making sure you are building the right things for the right reasons. There are also more examples from the digital world in applying JTBD.
And in the blue corner we have the much more innovation-and-MBA focused school headed up by Tony Ulwick. This approach is more business, innovation and c-suite focused with less on implementation. Examples come from traditional industries like manufacturing.
The two sides don’t get along, more on that later.
The good of JTBD
End to end user journey
JTBD doesn’t just focus on the product itself. It looks wider and takes in attracting customers from their initial first thought through to onboarding to leaving.
You can read more about designing across the product lifecycle from a series of articles I’ve written for Smashing Magazine.
JTBD has the concept of the timeline and how user needs change across different parts of the journey.
Job stories
Job Stories are a great tool for describing what a user is trying to do as well as the wider context.
Here’s an example:
When I am in a shop thinking about buying something
Help me to know how much money I have quickly
So I can check if I can afford these trainers when I’m in the queue for the checkout
They are much richer than user stories with extras like context and motivation to help put the user at the centre of the problem.
I like that they can contain emotion. Emotion is often lacking from many of the tools we use to plan better products.
Job stories aren’t perfect (see later) as they are light on detail and can’t necessarily be given to agile team to build as they are.
Switch interview / Understanding the four forces
One of the best parts of JTBD is the with interview. Or understanding how to get users to switch from a competitor to your product.
The Push of the Current
The Pull of the New
The Anxiety of the New
The Attachment to the Current
Here’s an example of the four forces for a bank:
Read more here about the four forces
Cross functional / team shared language
JTBD works well because it’s just limited to the product, UX or digital teams. The stories and language translate to all parts of the business from sales and marketing to customer support.
Jobs stories and Design Sprints work well together
Job stories are a great tool to set the objective for a design sprint. Clear, well research job stories mean your Design Sprint will run better.
Best of all it’s in the Harvard Business Review so it must be good
Many of the people I’ve worked with came across JTBD through an exec reading something in HBR. These are the two articles that started it all.
The bad of JTBD
The value of JTBD is only as good as the research that goes into it. The research tools and processes suggested by both JTBD schools are poor. (My background is in user research, 13+ years, 500+ interviews and research in academia)
Garbage in, garbage out
The biggest mistake I’ve seen with JTBD is summed up nicely from this multi-billion ££ UK cooperation I have been working with
We really XXXXXX it up. The research was all wrong. It sent us in the wrong direction really early. I wish we’d done proper research.
But if the research is done well JTBD is fantastic. User experience researchers to plan and undertake the research. JTBD is all about customer interviews (people are really bad at remembering what they did or even saying why they did something). I’ve seen the best results with contextual / ethnographic research methods. One-on-one interviews are very limited when it comes to uncovering context and JTBD is all about context.
JTBD are not the best tools to use in design
They can help with motivation and give a wider context that is lacking from user stories but they are often not detailed enough to just give to a design team to crate something from.
There isn’t much in the JTBD cannon on design. It reminds me of this postcard:
JTBD and product development / agile
The other thing JTBD is weak at is converting insight into design and product development.
The good thing about Job stories is they are verbose and rich. That’s also the problem with them when it comes to agile development.
The most successful teams translate Job Stories into user stories and integrate them into their existing scrum / agile practice.
The ugly of JTBD
It does get ugly in JTBD land. The two schools are constantly taking a swipe at each other and if you read anything on JTBD it might feel very different from something else you have read. This is down to the red vs blue sides of the JTBD world. Here’s a little taste of the weirdness.
Fear not, there is good stuff to be taken from both sides and I’ve worked on projects that have taken a lot from JTBD.
Is JTBD for you:
- Do you want a user-centred design approach that is c-suite-friendly?
- Do you struggle to walk both marketing and product development along the same path?
- Do you need a framework to help identify and promote unmet users needs (aka innovative ideas)?
- Are you stuck in the build trap ie heads down releasing, releasing, releasing without any vision or goal?
If you answer yes to any of those question JTBD could help you.
- Does your product roadmap contain both visionary items as well as stuff users really need?
- Do you use models like Kano to plan product development?
- Do you have alignment with the leaders in your organisation?
- Is marketing working toward the same things are you?
If that sounds like you you don’t need JTBD complicating what you are already doing well.
As with any approach take the best bits and integrate them into your existing processes. JTBD can help with alignment but isn’t in itself a fully baked solution to create perfect products.
I offer a one-day JTBD workshop to help your organisation understand what parts of JTBD can work for you and how to use it to get alignment across your organisation. I share experience of using JTBD with banks, travel companies and more.
Leave a Reply