Key Outcomes and Jobs to be Done

I first started using the Jobs to be Done framework about 5 years ago, and while I never quite got it to stick, I've seen more of the product teams I work with start using it.  As you might imagine, many clients have asked about the relationship between our concept of Key Outcome KPI pyramids and Jobs to be Done.  So I figured it'd be good to clarify for those interested in using one or both.

Key Outcomes Quantify Jobs to be Done

As Tony Ulwick explains here, it is important to measure progress in completing jobs but the measures felt too qualitative to me.  "Doing the job better" or "doing multiple jobs with one product" seemed nebulous, and that it would be hard to objectively determine whether you helped customers do those types of things.  As product teams are starting to shift from being output focused to outcome focused, it seemed natural to want to quantify the outcomes a customer seeks as a leading indicator of value delivery.  Also, rather than having to explain the jobs to be done to stakeholder and a set of corresponding metrics it seemed more straightforward to quantify the outcomes. 

You can see this in action with our imaginary Chuckwagon product case study.  The key outcome was to minimize the time spent getting a home-cooked meal on the table.  Embedded in that is the job to be done - making a home-cooked meal.  But rather than determining whether Chuckwagon helped make a better home-cooked meal, the key outcome makes it clear that customers value the efficiency of making the meal more.

Key Outcome Pyramids Break Down Into Jobs to be Done

I've seen a couple of product teams break their jobs down into sub-jobs.  While this is helpful from understanding and improving user workflows, it suggests you must build features to support each step of the workflow to help the customer get the job done.  But what about when you're launching a new product?  You don't want to have to wait to launch the whole workflow before starting to get feedback or delivering value to your customer.  By breaking key outcomes down into their constituent parts, you can start delivering value by working through the leading indicators of value delivery in the pyramid.

The key outcome pyramid above is from the same Chuckwagon example.  In order to get a home-cooked meal on the table, you have to do some menu planning, buy the right groceries, cook and clean up.  Each of these is a job that ladders up to feeding your household, but by instead focusing on the metric of time savings, the Chuckwagon product strategy unfolds by first saving time on meal-planning with 1-tap meal plans that get better over time as you rate the meals.  Then they build the feature to convert meal plans into grocery lists and get those groceries to your doorstep with one tap.  Finally, they deliver value by helping you save time cooking and cleaning with an in-home chef offering.  In this way, the Chuckwagon product traverses the pyramid, helping customers save time on the different workflow steps / jobs to be done.

Key Outcomes Can be Emotional

Source: HighAlpha

As the graphic above explains, the Jobs to be Done framework suggests there are 3 layers to every job: functional, emotional and social.  In choosing your key outcome, it's often appropriate to choose an emotional outcome.

As an example, when I worked on a financial wellness product suite at HelloWallet, we realized through user research that our product's main value was that it helped users feel more confident about financial situation, rather than something more functional like telling them what to do to improve their financial wellness (which we did).  This was a huge revelation for us as many users would take a long time to see their financial wellness improve - after all, it takes a long time to build an emergency fund or pay down student loan debt.  But rather than assume users weren't getting value out of our product because the actual bank account balances weren't changing meaningfully, we now knew that people using the product still liked it and found value, because it supported them during the process and helped reduce confusion / doubts.

Closing Thoughts

Hopefully you can see that the Jobs to be Done framework definitely influenced the thinking behind Key Outcome KPI Pyramids.  We know that product teams adopt bits and pieces of different frameworks to create a Frankenstein framework that works for their organization.  Hopefully from this you can see how it is possible to use both key outcomes and Jobs to be Done.