Jobs to be done – where marketing & UX meet
I’ve recently been learning about an approach to marketing and product management strategy called ‘Jobs to be done’. It seems an excellent way to bring business and user goals into alignment, and one to explore further in our thinking about product development.
In this post, I’ll introduce the key concepts, provide links to learn more and think about the relationship between ‘Jobs to be done’ and user personas.
What is ‘Jobs to be done’?
First articulated by Harvard Business School professor Clayton Christensen and coauthors in a paper in 2007, ‘Jobs to be done’ encourages marketers to think less about customer demographics, and more about customer motivations.
Most companies segment their markets by customer demographics or product characteristics and differentiate their offerings by adding features and functions. But the consumer has a different view of the marketplace. He simply has a job to be done and is seeking to ‘hire’ the best product or service to do it.
Clayton Christensen and coauthors (Sloan Management Review article, Spring 2007)
This short video is ultimately an advert for a service, but the story it tells provides a great illustration of the concept of jobs to be done. How the same product provides fulfils a very different need for the same user in different contexts. (4 minutes)
And here’s a short video in which Christensen introduces the concept with the simple example of a milkshake (5 minutes):
Christensen has obviously written about this concept extensively (as indeed have a lot of marketing and UX people) in the past 10 years. This article did a great job of selling the concept to me:
What is possibly most interesting about all this for me, is how this idea coming from a very marketing-orientated background has been picked up by the UX community. I think that’s because it’s the first time (correct me if I’m wrong, I’m no marketing specialist) that marketing has begun to encroach on the previously UX territory of user attitudes and behaviours.
I think it’s inevitable that marketing and UX functions will harmonise over time, as both are serving very similar roles for the business. (It’s about 4 years since I gave a tongue-in-cheek-titled presentation to the Chartered Institute of Marketing Higher Education group – “Marketing is dead, long live UX!”)
The end of personas?
Sections of the UX community have been discussing end of personas for quite a long time. Some don’t like them anyway, I think.
I don’t fall into that camp. I think the main reason for this is that the University doesn’t have a particularly high level of organisational maturity when it comes to UX. There aren’t lots of UX professionals working on projects and bringing the development teams into regular contact with their target users. When you don’t have a lot of resource available for user research, involving a team in the development of personas, and distilling what insight you have into something quick and easy to call on is incredibly valuable.
So for me, within the University at least, there’s a good case for continuing to develop and use personas to support projects and services in becoming more user-centric.
Perhaps part of the problem with the perception of personas is the use of the term in multiple disciplines. If you’ve only encountered the marketing approach to personas which can be little more than a collection of demographic segments, or agile development personas which are little more than an elaboration of a role in the use of a system I can understand your cynicism about their value.
This article does a good job of discussing UX personas in the context of jobs to be done:
Update: Within a few days of me publishing this post, Lean UX expert Jeff Gothelf also wrote about the same topic. Great minds, eh?
I’m not sure right at this moment, to be honest. When the right project or opportunity comes along within the team, perhaps we will take a jobs approach to writing our requirements.
If we do, I’ll follow up here.
Thinking differently about project and service requirements
We use a range of techniques to collaborate with stakeholders and users, and express and validate requirements. Here are a few other examples: