Jobs to be done research

Jobs to be done


I first heard about Jobs to be done as an alternative to user stories as a method of defining deliverables at Defuse 2015 conference. Emma Meehan presented how the team at intercom use Jobs to be done to make better design decisions.

Intercom are probably one of the most high profile advocates of this method with their own ebook available on this topic but it was a method they learnt from the Rewired group ( )

One of the fellow architects of JTBD, Clay Christensen has said,

“In hindsight the job to be done is usually as obvious as the air we breathe. Once they are known, what to improve (and not to improve) is just as obvious.”

The biggest distinguishing factor here is that approach to describing a tool, service or method as a “job”. I won’t even attempt to explain what Job stories are or how effective they are. I have already mentioned some key names and influencers in this area who have kindly documented and shared their experiences. In this blog post I hope to summarise how I plan to use Job stories in my major project.

Key Takeaways

After spending some time reading the Intercom eBook and watching a video by Sian Townsend entitle, “Jobs to be Done: from Doubter to Believer by Sian Townsend at Front 2016 in Salt Lake City, Utah” available here.

There are a couple of key takeaways I have picked up. In summary these would be;

Takeaway 1 – The Job to be done timeline

As mentioned above the fundamentals of Job stories is understanding the concept that people hire your product or service to get a job done.

Once your mind switches to this method of thinking and you begin to really look at how people currently get jobs done you are already opening up to this new method of thinking.

How do I apply this to my project? If for instance I hypothesise that people will book a hair appointment with a messenger app as they find it more convenient, more appropriate and a better solution I have to ask more than why? If the persons goal is to “get a new hair style” then the jobs to achieve this starts much earlier than just booking the appointment. I have to breakdown all the jobs along the journey. As a researcher and designer you can get to understand this full journey through the JBTD interview. When you document and understand this it is referred to as the Timeline.


More on this can be read here.

When I define the high level job I am hoping to tackle I aim to complete a series of JBTD interviews to understand the full timeline.

Takeaway 2 – The Job Story

Job Stories are one element of the Jobs to be Done framework. The belief here is that user stories are not effective or realistic ways to define features.

Alan Klements medium post sums up the issue with user stories in this nice graphic:

“the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality.”

Basically there is no room to ask why? The job story is all about context and causality. When you structure the job story as ,

“When …, I want to…, So I can…”

It puts the focus on the motivations of the user and drives the reaction or change of consequence in using the job. One of the biggest changes here is that there is no persona or user attributes mentioned. This is another big feature of Jobs to be done and Paul Adams has written extensively on why personas no longer work.

How we accidentally invented Job Stories

In my major project I hope to push my design solutions forward by focusing on the motivations, causalities and anxieties. If I do reach a point of looking at features of the product I hope to be able to use job stories to describe each feature.

Takeaway 3 – Observation

There is a nice “6 step guide” to determining a Job story and can be used to help you think innovatively in your area. These are as follows;

1. Start with a high level job
2. identify a smaller job
3. Observe how people solve the problem currently
4. Interview
5. Come up with a Job Story, or Job Stories, that investigate the causality, anxieties, and motivations of what they do now.
6. Create a solution

One of the key steps here I believe as a designer lies in the observation stage. How do people currently get the job done? What are the substitutes or in other words your competition? What I like about the thinking here is that your job could be replaced with something that you traditionally wouldn’t even consider in the same area, never mind even user story.

There is a case study referenced over and over again around JBTD and it involves a milkshake. It explains how they discovered for a popular fast food company that people at 8am in the morning were using milkshakes as a job to fill hunger on their commute. Now this may seem surprising and i’ll leave all the magic and intrigue when you read the case study yourself. What I found interesting here is the realisation that they were now competing with other alternatives (sometimes healthy) like a banana, coffee, donuts, breakfast cereals, etc etc. It was winning because it had ease of convenience of storage in a cup holder, a straw for non messy consumption and it was very filling.

Only through observation was such a result discovered. I will be taking this onboard as I move forward with my major project. I have always valued good solid user research and I am eager to focus this research around a particular use case or job!

As I mentioned in the opening of this blog post, this is by no means a full understanding of JBTD. I would encourage you all to read and consume all of the links and articles mentioned here. To get started you should visit the main site for more resources, case studies and experiences shared.

Leave a Reply

Your email address will not be published. Required fields are marked *