Jobs To Be Done Framework
Scrapping the persona and approaching product design in a different way
What is Jobs To Be Done?
The concept of Jobs To Be Done (JTBD) was popularised by Harvard Business Professor, Clayton Christensen (same dude behind The Innovator’s Dilemma) et al in a 2007 MIT Sloan Management Review Article. In a follow up article in 2016 JTBD is summarised as follows:
“Knowing more and more about customers — is taking firms in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance — what the customer hopes to accomplish. This is what we’ve come to call the job to be done.
When we buy a product, we essentially “hire” it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we “fire” it and look for an alternative.”
Clayton’s intro is good, however it is not tailored to digital products (the examples are all about milkshakes and moving house) and since it’s created by an academic, Clayton is a bit thin on how to apply it, being mainly focused on describing this new mental model. As a result, various other people and organisations have attempted to apply this concept to digital product design, most usefully (in my opinion), is Intercom.
The co-founder of Intercom begins to explain JTBD with the following example:
“Imagine you have just taken a photograph, now there are several different jobs that you might like to do:
1.) Capture this moment privately between two people, so we can look back on it fondly in years to come.
2.) Embarrass a friend in front of another friend.
3.) Get this photo backed up online, so I can point others to it.
4.) Get a copy of this photo to my grandmother who doesn’t use computers.
5.) Make this look cool and interesting. Like me. And then share it.
6.) Get this edited and into my portfolio so people consider hiring me for future engagements.
In this case the products you could hire are Facebook, iPhoto, Instagram, Flickr, or maybe 500px. When you think about how many of these apps you use, you realize the job is the distinction here, not you.
Focusing on the job rather than the persona helps highlight how features like red-eye reduction, multiple photo sizes, or filter effects are only useful for certain jobs.”
Can we get rid of a persona completely? The JTBD framework definitely proposes you do.
The Intercom co-founder explains in depth how when working at Google he created tonnes of personas and yet none of them were useful. This might seem like a shock, but my team and I had actually found ourselves intuitively distancing ourselves from working with strict personas for quite a while now. Perhaps you’re in the same position?
Either way, the JTBD framework is super simple to experiment with (which we’ll come onto in a sec) and in any case it’s hard to argue with this quote from Intercom:
“If you want to build a great software product, making crucial decisions based around a series of personality traits won’t get you there. That’s because products don’t match people; they match problems.”
Designing for JTBD v Personas
Personas look at roles and attributes. JTBD looks at situations and motivations.
Personas explain who people are and what people do. But they never fully explain why people do something. Why people do things is more important.
Applying JTBD
Remember those user stories with a format of:
As… I want to... To allow...
Well, a JTBD story is as follows:
[ When _____ ] [ I want to _____ ] [so I can _____ ]
Specifically, the when focuses on the situation, the want focus on the motivation, and the can focuses on the outcome.
Example stories are as follows:
- When an important new customer signs up, I want to be notified, so I can start a conversation with them.
- When an item does not have an estimate or has an estimate I’m not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.
The VP of product at Intercom first popularised “Job Stories” in his blog post The Dribbblisation of Design and highlights that using job stories focuses on all four layers of design:
And not just the “Visual” layer, which in his opinion a great deal of designers focus too much on (I don’t think myself or my team suffer from this — but perhaps others do?).
Expanding the Job Story
Alan Klement (a JTBD consultant) built upon the JTBD story concept with the following additions:
Products with multiple roles
Clarifying who we’re talking about
When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.
Roles with cause and effect
Sometimes a job story affects multiple people, with knock on effects
When a Seller isn’t happy with the bids they are getting and takes their product off the market, Buyers who have already submitted bids, want to be immediately notified that the product has been pulled, so that Buyers know they no longer need to keep tabs on the product and should look for a different, similar product instead.
Using events instead of roles
Sometimes, there might be a situation when an event affects all the roles of groups. Then there is no reason to have a specific role.
When a customer is on their mobile device and forgets their password, they want to get their password in a way that makes it easy to reclaim it via their mobile device, so they can continue to log in and access their news feed.
Summary
As I previously stated, I’d begun naturally distancing myself from working with strict personas for quite a while and so this change in thinking about product design was not as revolutionary as perhaps some of the writing around the concept describes it as.
That said, I imagine for an organisation that currently spends a great deal of resources on researching personas, adopting the JTBD approach (and it proving successful) could save a great deal of time and effort.
In conclusion, I found the JTBD framework great in communicating epics and the construction of job stories extremely useful in understanding a user’s expectations from using a product feature.
Please go ahead and experiment with this approach and tell me what you think!
Update: March 18
Whilst working with this concept for a couple of months, myself and my team have found difficulty constructing job statements that make a distinct difference between the motivation and outcome.
Therefore, our new job statements start the outcome with a verb, making it clear that there is an expected action, that is derived from the motivation.
For example:
When a customer is in the existing portal,
They would like to explore the new portal,
Deciding the change is an improvement.
Admittedly, this revision does blur the definitions of action and outcome, however this revision is to make it clear that the customer is actually going to do something next. It’s meant to signify their next step in the journey: the customer is interacting with the product after all, not pacifically waiting for something to happen.
