PRODUCTHEAD: What’s the fuss about Jobs To Be Done?
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
you and whose product? #
A milkshake is really just a way to pass the time and stave off hunger on a long drive
Users struggling to use your product to complete their tasks have unmet needs
Christensen emphasises the higher order goal, Ulwick the task at hand
Jobs To Be Done is often misunderstood, making it difficult for some to begin applying it
a favour: please share this with other product people
every PRODUCTHEAD edition is online for you to refer back to
For several years there’s been a constant, low-level buzz about Jobs To Be Done (JTBD). As I am with any other purportedly game-changing framework, I have been somewhat sceptical about JTBD. I can’t help but wonder if the people shouting loudest about a new framework’s many and varied benefits are simply the process consultants seeking to sell a new workshop package.
Even so, it’s difficult ignore the scores of people who use JTBD with their products and have found it tremendously useful. Until now, I’ve just not had enough of an understanding of it to make a more informed judgement.
In a nutshell, JTBD encourages you to understand that your product or service exists purely to serve a user need or to help them achieve a goal. This much I agree with: your product is just a means to an end for users, it’s not the important bit.
And so we reach the point at which we open the metaphorical can of worms with JTBD.
There are (at least) two subtly different definitions of the nature of the goal (or user need). One originates primarily from the late, great Clayton Christensen of The Innovator’s Dilemma fame. The other comes primarily from Anthony Ulwick, founder of consulting firm Strategyn.
To summarise the difference: Christensen defines the ‘job’ as the desired outcome, beyond the immediate task at hand. It’s where you’d end up if you kept asking ‘why are you doing that’, over and over; Ulwick defines the ‘job’ as the desired result of the immediate task at hand.
To put it another way, if the task at hand was applying for a mortgage, Christensen would say the job (the end-goal) was something like ‘shortening my work commute’ or ‘having space to start a family in a nice neighbourhood’. Ulwick would say that the job was ‘obtaining a mortgage’.
I feel that the effect of this difference is significant.
Christensen would encourage us to figure the underlying reason why someone is trying to do something, to find out what their end-goal is. This helps to frame their motivations and reveal opportunities to help them to achieve that goal more effectively, possibly with entirely different products or services helping them along the way. This ties in with the positive disruption he describes in The Innovator’s Dilemma.
Ulwick however would encourage us to focus on the user’s context for the task at hand, and to optimise the product to complete that task more efficiently and in a manner more satisfying to the user.
To go back to the mortgage example, Ulwick’s approach would be to simplify the process of applying for a mortgage to make it as painless and satisfying as possible for the user. Not a bad result, by any means.
Christensen would challenge us to see if there was a better path to home ownership that enabled a user to start a family in a nice neighbourhood without the faff of having to apply for a traditional mortgage in the first place.
[As an aside, my friend and partner-in-podcasts Ray Rafiq has been disrupting various aspects of property rental, purchase and ownership through his various startups over the years.]
If it’s not possible to innovate disruptively in this way (perhaps due to some kind of constraint outside of our control), then we fall back to trying to streamline the status quo — but this should be only a temporary compromise on the vision.
As may now be apparent, I share Christensen’s point of view. Product managers should realise that their product or service is not the important bit — it’s simply a means to an end for users. The higher order goal (or outcome) is what is important to users (in this example, ‘starting a family’).
Users are only using your product because it’s quicker, easier, cheaper or more readily available than their alternatives. As soon as a sufficiently convenient, effective or cheaper product comes along that overcomes the inertia of making the change, they’ll jump straight over.
Just try to make sure that it’s your product they jump to, rather being the one they’re jumping from.
And if you’re still confused about Jobs To Be Done, I’ve pulled together some great content this week that will help to resolve things for you.
Speak to you soon,
what to think about this week #
In this short video, Clayton Christensen explains his famous ‘milkshake’ example that he uses to illustrate the job definition in his version of Jobs To Be Done. (Phoenix University’s audio-visual team gets bonus marks for creative use of the windows.)
[CLAYTON CHRISTENSEN / YOUTUBE]
To describe his take on Jobs To Be Done in this interview with Intercom’s Des Traynor, Tony Ulwick uses examples ranging from surgical tools and circular saws to building playlists and circumventing highway traffic.
[TONY ULWICK / INTERCOM]
Whether you’re new to product management or have been a product manager for years, a coaching session can help you to step up your career.
We’ve coached people wanting to get into product management, product people with nobody in their organisation to manage them, and experienced product managers preparing to apply for a promotion.
We can help you prepare for your product manager interview, including mock interviews.
A proportion of the fees from every coaching session is donated to charity. Just reply to this email if you’re interested in finding out more.
Many who see Ulwick’s interpretation of Jobs to be Done see it as a simplified, repackaging of existing ideas. This causes many to dismiss Jobs to be Done, and prevents them from wanting to learn more about it.
People in the UX community, like Jared Spool, look at JTBD and see it as a gimmick. Is their criticism valid, or a result of conflating the two different interpretations of JTBD?
[ALAN KLEMENT / JTBD.INFO]
In this talk, Mike Belsito shares what he’s learned about JTBD working directly with one of its architects, Bob Moesta. Mike will demystify the process of getting started with JTBD — sharing actionable advice and detailing how he was able to quickly improve INDUSTRY: The Product Conference as a result.
[PRODUCT COLLECTIVE / YOUTUBE]
recent posts #
I am searching for a career change and Product Management/ Project Management are my areas of interest. I was looking to understand, based on your experience, if in such roles technical skills are required?
[I MANAGE PRODUCTS]
Starting a new product manager job can be daunting, particularly if you don’t change jobs very often. I work freelance, so I find myself in a new organisation roughly every 3-6 months. Let me share with you my tips for your first few months in a new role.
[I MANAGE PRODUCTS]
Because I tend to help organisations build up their product team from scratch, I’m often involved in the interviewing and hiring process, so I’d like to share with you my product leader’s guide to interviewing product managers.
[I MANAGE PRODUCTS]
upcoming talks and events #
5th May 2021, 16:00 GMT
Online product management round table discussion (topic TBC)
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from worms we’ve managed to persuade back into their tin.