Prioritise outcomes, not features
This is the last of the three part series on Jobs to De Done (JTBD) Framework (Part 1, Part 2 ). In this post, I will share about why we must prioritise outcomes and not features. One of the biggest influences to my work has been Tony Ulwick’s book What Customers Want - Using Outcome Driven Innovation to Create Breakthrough Products and Services.
The book was recommended to me by Adrienne Tan in my very first podcast episode on Yours Productly a couple of years ago. Ever since I have read the book, I have applied a lot of its principles directly into my work in good measure.
The other book that has had a profound impact on me is Jeff Patton's User Story Mapping
This book taught me to think about always building less : minimize output, and maximize outcome and impact. Building more software faster is always a good idea. But it's never the solution.
Minimize output, and maximize outcome and impact. Building more software faster is always a good idea. But it's never the solution.
What is an outcome?
Because customers buy products to help get jobs done, if companies want to improve an existing product or to create a new product, they must figure out where the customer struggles in the execution of a specific job and then devise ways to help the customer. This means that companies must analyze the job of interest and ascertain from customers what metrics they use to measure how well the job is executed being executed. Customers know perfectly well how they measure success when executing a job and are very capable of communicating those metrics—and those metrics, simply put, are their desired outcomes.
A corn farmer, for example, may want to “minimize the time it takes for the corn seeds to germinate” or to “increase the percentage of plants that emerge at the same time.” When trying to help customers get a job done better, companies must find out which outcomes customers struggle to satisfy and then devise solutions that address the problems. This is where the term outcome-driven innovation originates. There are two foundational discoveries revealed in outcome driven innovation:
People buy products and services to get jobs done.
People use metrics to measure the successful execution of a job.
These two discoveries provide the framework and inputs needed to effectively execute the innovation process.
Structuring an Outcome Statement
Desired-outcome statements must conform to a specific structure and follow a set of stringent rules. This is necessary because differences in structure, terminology, and syntax from statement to statement can introduce unwanted sources of variability that alter the importance and satisfaction ratings customers give the statements. This in turn will affect the way customers end up prioritizing innovation opportunities. A typical outcome states four parameters:
Direction of improvement: Whether to minimize or increase?
A unit of measurement: What is it that we are trying to minimise or increase?
Outcome desired: What they’re trying to get done and why ?
Contextual clarifier: What is the context in which the job occurs – circumstances, constraints, and barriers?
Here is an example of how I applied the structure in outcomes within my product:
Prioritizing Outcomes
The real power of Jobs-To-Be-Done (J2BD) innovation approach comes from identifying and prioritizing a set of desired outcomes a customer wants to achieve in executing his job.
For any feature, there are going to be multiple outcomes. We list out the outcomes first and then pick and build first for the outcome that we can’t do without. The picture below explains prioritized target outcomes.
The next step I would take up with the customer is to list out all the possible outcomes the customer needs to accomplish. Once all the outcomes are listed, I would then ask them to pick the most vital outcomes and then the second most important and so on and so forth. You can use different assessment and rating schemes to determine which JTBDs should be a priority for innovation. One way to measure the importance of a job is by asking customers based on a Likert Scale (degree of importance to them), using sound samplingtechniques. A Likert Scale can also work for assessing the level of satisfaction customers have with current solutions.
Prioritising outcomes on reach of impact
Sometimes, outcomes can be prioritised by how many people it is impacted. You don't need to solve a problem for all your customers, but for a certain segment of users. In that case, for example you can pick 2 out of 3 outcomes that will define success for you.
Here is an example of how I did it in one of my previous project in a prioritised order:
After considering the team resources and delivery constraints, we only picked the outcomes from the top that provided the maximum value.
When desired outcomes become the focus of customer research, innovation is no longer a matter of wish fulfillment or serendipity; it is instead a manageable, predictable discipline.
"Notice how the list isn’t a bunch of features. It’s a list of real-world benefits—because, remember, your job isn’t to build software, it’s to change the world. The hard part is choosing which people you want to change the world for, and how. "
"The secret to breaking down that really big chunk of output was to focus on a smaller, specific outcome. "