The application of Jobs-to-be-Done Theory, and more specifically the Outcome-Driven Innovation (ODI) process created by Strategyn, is designed to inform each of these efforts. The ODI process employs unique qualitative research methods that enable the capture of all customer needs (desired outcomes) related to the core functional job-to-be-done and the consumption chain jobs that comprise the customer experience (see the diagram below).
The desired outcome statement is a specially constructed need statement that has a unique set of characteristics: desired outcomes are devoid of solutions, stable over time, measurable, controllable, structured for reliable prioritization in a quantitative customer survey, and are tied to the underlying process (or job) the customer is trying to get done.
ODI also employs unique quantitative research methods that pinpoint, with statistical validity, what under/over-served segments exist and which outcomes in each segment are most under/over-served. This enables a company to target opportunities for growth with precision.
The methods are proven to work effectively in hardware, software and service development applications. Let’s take a closer look as to how product planners, hardware engineers, software architects, product support and CX teams, and UX and UI designers can use this valuable information to execute these 4 universal jobs that are critical to success at innovation.
Before any product can be developed, it must obviously be conceptualized and defined. This effort is typically the responsibility of the product planner. While holding a variety of titles (product manager, product owner, marketing manager, developer), the product planner is responsible for:
This was my role when I held a senior product planning position at IBM early in my career. I created ODI to help me get this job done better and more cheaply than competing solutions.
When a company does not have a product planning function, the responsibility for product conceptualization and definition typically resides with the marketing function. In software companies, product planning is sometimes the responsibility of the development team, especially when the organization is using an agile approach which doesn’t emphasize or require a detailed product definition before development begins. Regardless of where the responsibility lies, ODI is an effective method to use to conceptualize and define a solution that is certain to win in the marketplace. Case studies describing the use of ODI for hardware, software and service applications are available.
Jobs-to-be-Done Theory and ODI are integral to successful product planning — they enable a product planner (or a marketer, engineer or developer) to conceptualize a product or service that will win in the marketplace BEFORE it is approved for development. Applied correctly, it results in predictable innovation, as the conceptualized offering is certain to address unmet customer needs.
After a product is approved for development, engineers and software architects are responsible for bringing the conceptualized product to life with a product architecture that enables the customer to successfully execute the job they are trying to get done. When applying Jobs Theory and ODI, this is referred to as focusing on the core functional job the customer is trying to get done.
As part of the ODI process, engineers and architects are presented with a job map and the precise metrics (desired outcome statements) around which each feature was conceptualized and prioritized by the planning team. These inputs are used by the development team to engineer/architect the product and each feature as conceptualized — and to avoid risking an implementation that fails to deliver the value desired by the customer.
For example, when applying ODI at Bosch, a circular saw product engineer was given the following insights when engineering a detent-based solution to help tradesmen quickly make blade angle adjustments:
Keep in mind, the idea of a detent-based solution was already conceptualized by the planning team. The product engineer had to bring it to life while ensuring the customer’s underlying need was addressed as intended. The goal was to “minimize the time it takes to make a blade angle adjustment.” The result was a solution that looked like this:
In the software world, the approach is the same. When Microsoft used ODI to inform the creation of an early version of OneNote, we captured a complete set of customer outcomes and determined which outcomes were most underserved. The product owners conceptualized and prioritized (based on their value to the customer) an extensive feature set that addressed the underserved outcomes.
The features as conceived, and the outcomes they were intended to address, were then given to software architects to guide the creation of the offering/features. Once again, the insights were used to bring the concept to life while ensuring the customer’s underlying outcomes were addressed as intended.
Users have to interact with the products, services and software applications they purchase and/or use. For example, users of hardware and software products have to:
To help users successfully interact with a product, designers must create and provide them with an effective user interface. This is true whether a company is designing a light switch or a graphical user interface for a software application.
ODI informs UI design by helping designers (the usability team, the industrial design team and UX and/or UI designers) better understand the metrics (desired outcomes) customers use to measure success when interfacing with a hardware/software /service offering. There are approximately 90 metrics we have uncovered that define a successful product interaction.
Our first effort to improve UI design dates back to 1995 when we helped Motorola improve the user interface of a 2-way radio product used by firefighters and police. The opportunities we discovered using ODI led to improvements that were revered by the Motorola design team and product users alike. By shaping the knobs on the radio differently, users were able to quickly find the right knobs to use without looking at the radio — this helped save time in emergency situations when every second counts. It also helped drive growth in what had been a stagnate market.
Users/others have to interact with the brand, company and the product for a wide variety of reasons throughout the lifecycle of the product. For example, customers of software products typically have to purchase, receive, install, set up, learn how to use, and upgrade their products. Customers of hardware products typically have to purchase, receive, install, set up, learn how to use, transport, clean, store, maintain, repair and eventually dispose of their products.
We call each of these elements of the customer experience a “consumption chain job”. To get these consumption jobs done well, companies often have to interact directly with the customer. These touch point experiences, whether digital, via phone or face-to-face, can make or break a company.
Good customer experience design is dependent on understanding each of the relevant jobs in detail and knowing what desired outcomes the customer is trying to achieve and where they are currently underserved. The qualitative and quantitative work that is part of the ODI process provides these deep insights. They inform opportunities to evolve the customer experience. We have studied every one of these consumption chain jobs in detail and uncovered a set of desired outcomes for each.
In the hardware community, the customer experience is typically designed and implemented by the product support team. In the software world, the customer experience is designed by what is being called the CX team. While titles can be confusing and limiting, what is important is that someone in the organization is responsible for designing the customer experience so customers can joyfully interact with the company and the product throughout the product lifecycle. Learn more about CX/UX title distinctions here.
Whether you are a product planner or product owner, an engineer or architect, part of the product support or CX team, or a UX or UI designer, the core tenets of Jobs-to-be-Done Theory and the data and information that is made available through the ODI process can help you create value for your customers and make your success more predictable.