scrum
This is part 2 of the article on JTBD vs. USM
For part 1 of the article, please refer to …… Jobs To Be Done vs User Story Maps
In this article, we will fully dive deep into what Jobs To Be Done (JTBD) really is and how it differs from User Story Maps. I will also help show how to use them collaboratively in meeting your needs.
JTBD first came out when Clayton Chirstiansen, a professor at Harvard Business School’s Product Management group, set out with his team to understand what ‘needs’ drive people to ‘hire’ a product. Needs are driven by “jobs that need to be done”. In short, Clayton and his team ended up interviewing a number of people buying Milkshakes at a fast food restaurant. They asked each Milkshake buyer, “What jobs do they need done that makes them hire a milkshake?”
While many did not understand what the question really meant, Clayton’s team through observation and talking with customers figured out that people who had to commute long distances early AM needed to buy milkshakes to keep them full till lunch, to have something that takes quite a while to consume, to have something that is easily manageable while driving through the commute……. And that, they were not necessarily buying milkshakes because they were delicious. Here is the video where Clayton talks about Milkshakes!
This and other experiments made Clayton and his team conclude that people hire a product because they have a certain job that needs to be done.
This is quite revolutionary.
“The secret to right innovation lies in understanding what causes customers to make choices that help them achieve progress on something they are struggling with in their lives. To get to the right answers, Christensen says, executives should be asking: “What job would consumers want to hire a product to do?”
So, in summary, JTBD:
- Indicates what users want to get done
- Is independent of specific personas
- Provides insights into the deeper needs of the Customers. The deeper needs provide insights to a business on how to be innovative while creating products. A lot of people who love Apple phones still end up buying Samsung because their need is to have a better camera on their smartphones!
User Story Maps (USM) on the other hand, is based on users and their experiences while using a product. USM focuses on specific personas and their story on how they (want to) use your product. A good user story map contains not only the journey but also the experience - challenges, pains, awards and joys the users feel or express while using your product. Although, the USM has no specific set of rules, it is recommended to understand the difference between the sea-level “user steps” (a step that a user takes in the journey of using your product with the intention of completing it once started) and the “backbone” - activity or higher level summary of a group of steps as shown in the image below
Fig. xxx - User Story Map for an Air Travel App
While both the sea level (user steps) and backbone (higher level summary) are in narrative flow, the backbone actually represents the jobs to be done and provides insights into the deeper needs of customers or users.
The narrative flow of sea level user tasks goes like this:
(As a user of this product)
I will do this , and then I will do this, and then I will do this and then….
The narrative flow of backbone (user activity) goes like this:
(As a user that wants to get this job done - air travel in this case)
I need to do this , and then I need to do this , and then I need to do this and then …
Please refer to the examples below illustrating the above:
Looking at these images, one can easily see that jobs to be done are already embedded into the user story maps. Many do not know how to create story maps effectively. If you can build your maps wisely and mark out areas or steps where customers and users experience challenges, pains and have to work around to get through those step(s), you will be able to draw insights on what they want to get done and what needs are not being met for which they have workarounds.
Clayton himself has said:
“For me, this is a neat idea,” Christensen writes of the Theory of Jobs to Be Done. “When we buy a product, we essentially ‘hire’ something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we ‘fire’ it and look around for something else we might hire to solve the problem.”
Many folks who have never experienced story maps and their effectiveness and usefulness in creating delightful products, but know about Jobs To Be Done, use this thinking framework to draw insights.
However, they will still need to create some sort of visual alignment for conversations to build a shared understanding.
ou cannot just use JTBD on its own to help others understand a product. Remember, JTBD is a motivation and not a product design!
However, people who employ user story maps can easily draw out the jobs to be done
Comparison between Jobs to be done vs. User Story Maps
Conclusion:
There’s quite a bit of debate out there on what is a better approach for building a great product, Jobs To Be Done Or User Story Maps. The reason for the debate is due to a lack of proper understanding of how these two approaches work. Looking deeply and objectively, one will find that they are not conflicting but are different ways to understand your customers and user's real problems and goals, which is part of a good product thinking exercise. A user story map will ideally have included the important jobs a user needs to be done
Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more
