A Jobs To Be Done (JTBD) primer
Introduction
Jobs To Be Done is a framework that aims to help teams identify which problems to solve.
The aim of this article is to provide a quick overview of some of the key concepts of Anthony Ulwick’s book ‘Jobs to be Done: Theory to practice’ and other articles.
What is the purpose of Jobs to be done?
Within the Product Management community, there is a great deal of focus on topics such as how to minimise risk by validating ideas with less cost, coming up with solutions collaboratively to find something that works, and iteratitve delivery practices to shorten the feedback loop.
While each of these is undoubtedly crucial, there is relatively little written on how to prioritise which problems exactly to find a solution for.
This is where JTBD comes in, suggesting a set of steps to define the set of customer needs in a meaningful manner and identify any segments of customers with unique sets of unment need.
This is then used to make sure that existing products are marketed most effectively and product development is focused on the areas of opportunity.
This gives the entire team a clearer problem to solve, and one which can be backed by quantitative data.
If our goal as Product Managers is to hit a target, using experiments and ‘failing fast’ will mean that you can take another shot sooner. Jobs To Be Done aims to increase the chance that any given shot will be a hit since you won’t be shooting in the dark.
What are the characteristics of a well defined job?
While there are a number of different types of jobs described by Ulwick, the most important one is the core functional job. This describes what the user is actually trying to achieve at that time in a way which is stable over time and solution agnostic.
A good job statement is structured as follows:
Job statement = verb + object of verb + contextual clarifier
eg <listen>to<music>while<on the go>
Taking a step back, a similar job might be defined as “entertain myself while on the go”. In this case you might want to listen to music, but there might be other ways of meeting that need, including playing mobile games, reading a book or listening to a podcast. Taking a step back in this way is designed to help you find adjacencies which you can compete into or defend against possible new competitors.
Job map
A completed job map represents the “ideal process flow” for that job: all the steps in the ideal order for efficient execution.
Once the steps are identified, a company can create value in a number of ways — by improving the execution of specific job steps; eliminating the need for particular inputs or outputs; removing an entire step from the responsibility of the customer; addressing an overlooked step; resequencing the steps; or enabling steps to be completed in new locations or at different times.
What are desired outcomes?
Desired outcomes are customer-defined performance metrics which are tied to each step of a job map. Similar to jobs, desired outcomes need to be stable over time and solution agnostic.
A good desired outcome is structured as follows:
Desired outcome = Direction + metric + object + contextual clarifier
eg <Minimize>the<time it takes>to<get the songs in the desired order>for<listening>
Ulwick also recommends that unnecessary variability between outcome statement wording is minimised. This means that they should all start with either minimise or increase. He also recommends that around 90% should be ‘minimise’ with 10% being ‘increase’. This is because “customers are typically trying to get a job done faster, with less variability and waste”.
Having a well defined set of desired outcome statements helps to further hone in on the ways in which improvements to the way the job to be done can be achieved.
To give an indication of how detailed to be here, Ulwick recommends that around 100 desired outcome statements should be defined for the entire process. This would include desired outcomes for things such as ‘emotional jobs’ and ‘consumption chain jobs’, which look at the wider context of the job to be done. Examples of these might be things like ‘minimise feeling of frustration while im finding something to listen to’ or ‘minimise the time it takes to get my existing data migrated over ’.
Using the desired outcomes
The set of desired outcomes are then rated by enough people for statistical significance on importance and satisfaction with current methods of doing that job.
This data set is then analysed to identify clusters of needs which are underserved or overserved first at the level of the group as a whole and then perhaps try to identify segments which are hidden within the wider population.
If a segment is overserved, then a company may be able to deliver a slightly less functional product if it delivers significant cost savings. If a segment is underserved then an offering which meets those specific needs more has a good chance of being successful.
An important point to remember is that before going into new product development, a company should look at its current product offering to see if any of its existing products can be marketed better to those segments.
Only when that investigation has been completed, is it time to take that set of unmet needs through the process of product discovery and development.
Sources
- Jobs to be Done: Theory to Practice — Ulwick, 2016
- Defining good problem statements
https://jobs-to-be-done.com/the-5-tenets-of-jobs-to-be-done-theory-ba58c3a093c1 - Defining a good set of need statements
https://sloanreview.mit.edu/article/giving-customers-a-fair-hearing/ - Nice summary of goals and steps
http://www.marketingjournal.org/how-to-fail-at-jobs-to-be-done-anthony-ulwick/ - Good summary of JTBD/ODI
https://jobs-to-be-done.com/outcome-driven-innovation-odi-is-jobs-to-be-done-theory-in-practice-2944c6ebc40e - Desired outcome statement breakdown
https://sloanreview.mit.edu/article/giving-customers-a-fair-hearing/
