Applying Jobs-to-be-Done to a Design Sprint
At the start of this year (2017) I came upon an ebook titled Intercom on Jobs-to-be-Done published by the brilliant folks Des Traynor of Intercom and Alan Klement. The book is based on a framework for understanding customer behaviour developed by Clay Christensen a prof at the Harvard Business School, his subtly hilarious milkshake example below is a favourite of mine that really boils down JBTD in just four minutes. A must watch if you haven’t already.
While the video explains the concept perfectly, applying it to designing software products is another matter entirely. And this is where Intercom’s book takes it a step further, with their invention of the Job Story. Now this post isn’t about the how the framework works, you’ll read to book for that, but I will summarize it in as few words as possible.
Jobs-to-be-Done helps design better products by focussing on the job the customer is trying to achieve rather than the customer persona. Simply put, why do people hire your product? And here are a couple of simple examples, taken from the book.
People hire email many times a day to keep their colleagues in the loop
People hire Instagram to make their pics look cool and interesting like themselves and share it with their friends.
The Job Story, a concept I particularly like, looks like this:
[ When _____ ] [ I want to _____ ] [so I can _____ ]
‘When ____’ focuses on the situation, ‘I want to ____’ focuses on the motivation, and ‘so I can ____’ focuses on the outcome.
The difference between a the popular User Story in Agile software development and the Job Story is this. The Job Story is written from a customer perspective, it focusses on motivation and outcomes but not any particular solution. The opportunity to generate multiple solutions to a focussed problem is exactly the situation you want when in the exploration stage of a design process.
JTBD + Design Sprint makes Paul a happy client
So this got me thinking how I might incorporate JTDB in my next Design Sprint. I hypothesized that by using Job Stories to shape customer anxieties, hopes, and fears, the sprint team would be able to focus on solutions to these more quickly by having a deeper understanding of the customer. Solutions that were developed during the sprint could then be correlated back to the list of Job Stories to keep us on track.
Meet Paul, a long standing client of mine from my days at my last company Pair Shaped. Paul was looking to create a brand new product in the industry where he worked for several years. I suggested we run a 5 day Design Sprint to develop ideas, and generate a prototype. We also added in strategy day prior to the sprint to really understand all the elements of the business. We used the Value Proposition Canvas for the strategy session, which also happens to focus on customer jobs. It was a great way to introduce the JTBD concept to the entire process.
On Day One, the understand phase of the Design Sprint. I traded the Ask The Experts/How Might We note taking for JTBD. I did this by simple asking what jobs were our potential customers trying to do that our product could be hired to do instead. We quickly came up with a sticky note list of about 40 different job stories for two customer roles that we then grouped together and prioritized.
The rest of the day followed the typical Design Sprint activities—mapping the problem and picking a target. What I discovered with the Job Stories was that we had a checklist we could use to make sure the ideas we were generating were actually solving the customer jobs.
After day 2 and 3, the solution sketches were complete, dot voted and ready to be prototyped. We were able to refer back to our list of jobs and check off each one against interface elements we designed in our solutions sketches. We were able to move forward to storyboarding and prototyping with confidence knowing that we were designing a product that accomplished the jobs our customer hired the software to do.
So that was my little experiment with JTBD, I think it is a powerful tool that kept the sprint focussed on solving customer needs. It was also very easy to explain and was very well received with Paul and his team, who aren’t designers or developers. There is definitely more experimenting to do and likely better ways of incorporating this into the design process, I felt it was a great outcome and will definitely be using it in future sprints.
If you have any thoughts or examples on how you use JTBD in your product design process, I’d love to hear about it. Please share in the comments below.
