Jobs To Be Done framework: a guide for UXers
What is it?
Top line: Users buy / use / hire a product or service to get a specific job done.
It’s a product management framework that looks at what problems customers have that they need to solve. It looks at jobs user need to do rather than looking at what behaviours they undertake. The need is the key to solving the problem.
The framework talks about users “hiring” the service over buying as users are often just using your service for a small part of their life when they need it. (So don’t use er, use)
‘User sends an email’ might be listed as a task in a classic user journey. JTBD looks at what they are trying to do in sending that email. Maybe that email is being sent to cancel a call in 20 minutes, in which case email may not the best tool for the job as the recipient of that email may be en-route to the meeting.
Why use it?
Jobs To Be Done looks to uncover the goals of the user rather than the inefficient behaviour they may have adapted / learnt to get the job done.
Identifying the jobs allows product teams to:
a. To stay focused on the the right thing
b. Think of novel ways to get these identified tasks done
c. To uncover jobs not identified by existing products or services
Where does JTBD come from?
Clay Christensen wrote about it in his book The Innovator’s Solution back in 2003 based on earlier work by Anthony W. Uliwck.
A good place to start is an article from Harvard Business Review by Anthony W. Ulwick and Lance Bettencourt: The Customer-Centered Innovation Map (yes, that is an awful title).
A quick overview of Jobs to be Done
There are 8 stages of getting the job done.
- Define: What does the user need to define up front? what objectives do they set? Eg for taking out a new car insurance policy. They user needs to define the car they want to insure. What their requirements are from the policy, eg cheap, extras included
- Locate: What stuff, information, items, inputs, does the user need to get the job done? For our example, car registration number, model, milage etc
- Prepare: How does the user prepare for the job? Perhaps they site down on the sofa with their iPad and the documents they need.
- Confirm: Once the user has prepared what do they need to verify before they start. For our job they might check they have everything they need.
- Execute: What steps the user need to take to get the job done? Go to google, visit a car insurance comparison website, enter details etc. This is classic user journey stuff all UXers are familiar with
- Monitor: How does the user check everything is going ok? How do they decide what to modify / change? Perhaps they got an insurance quote that was high and needed to change something. If there are lots of steps in the insurance process the user might flag and want to come back to it later.
- Modify: What does the user need to change to get the job done? If the insurance quote was high they removed some added extras to reduce it or went to make a coffee and came back to quote 20 minutes later.
- Conclude: What does the user need to do to know they have finished the job? The insurance company sends them an email saying they are covered. They download their policy documents.
How does it fit into existing UX processes?
In fact any of the UX planning methodologies can sit on top / alongside Jobs to be Done.
How does it differ from other product management approaches?
Where can I learn more?
Tony Ulwick (he’s since dropped the W) offers more depth: Jobs-To-Be-Done Theory, Approach and ODI at Strategyn
A free book When Coffee and Kale Compete by Alan Klement (yes it’s a terrible title, that seems to be a JTDB theme)
He bought the W back and has a book: USA: Jobs to be Done: Theory to Practice: Anthony W. Ulwick and UK: Jobs to be Done: Theory to Practice (eBook).
Applying Jobs to be done: 8 Things To Use in “Jobs-To-Be-Done” Framework For Product Development(ignore the Maslow’s Hierarchy of Need ).
A Medium Channel devoted to Jobs to be Done.
A big list of Jobs To Be Done Resources.
Thanks to Andy Irving for helping me get my head around JTBD.
Originally published at Joe Leech.