While customer insights have driven hardware and software development for years, Outcome-Driven Innovation (ODI) takes customer-centered innovation to the next level.
Whether a company is investing in the creation of a product, service or software solution, there are 4 key activities that must be executed effectively by the planning and development teams. For each product that is launched, a company must:
- Conceptualize the product that is to be developed for the target market. To be successful, the conceptualized product must help users get a core functional job done better and/or more cheaply. This activity is the responsibility of the product planner or process owner.
- Engineer/architect the product to perform the core functional job it is intended to perform. This activity is the responsibility of the product engineer or software architect. If the product does not get the core job done better/cheaper than the next two activities are a waste of time.
- Enable the user to effectively interact with the product. This activity is the responsibility of the usability team or the UX and/or UI designers.
- Design the customer experience to support users/others as they interact with the brand, company, and product throughout the product’s lifecycle. This activity is the responsibility of the product support or CX (customer experience) team.
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 (see the diagram below). ODI also employs unique quantitative research methods that pinpoint, with statistical validity, what segments and under/over-served outcomes to target.
Design products to address the core functional job and the customer experience.
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 bring more clarity and predictability to their respective planning, development and design efforts.
1. Conceptualize the product that is to be developed
Before any product can be developed, it must be conceptualized and defined. This is typically the role of the product planner. While holding a variety of titles (product manager, product owner, marketing manager, developer), the product planner is responsible for:
- Understanding all the customer’s needs in the targeted market.
- Knowing which needs are under/over-served and to what degree.
- Knowing if segments of customers exist with unique sets of unmet needs.
- Conceptualizing the products, sub-systems and feature sets that will address the unmet needs of the targeted customers.
This was my role when I held a senior product planning position at IBM early in my career.
When a company does not have a product planning team, the responsibility for product conceptualization and definition typically resides in the marketing function. In some companies (mainly software and technology firms), the product planning responsibility may not reside with either a product planner or the marketing function. Rather, it becomes the responsibility of the development team.
We commonly find that developers/designers are executing the product planning role when: (i) that is the way the company is organized, (ii) marketing has done a poor job of getting them the needed information, or (iii) the organization is using an agile approach which doesn’t emphasize or require a detailed product definition before development begins. In any case, developers/designers are well served to use ODI to help them conceptualize and define the solution that is certain to win in the marketplace.
Jobs-to-be-Done Theory is integral to successful product planning — it enables a product planner (or a marketer or developer) to conceptualize a product or service that will win in the marketplace BEFORE it is approved for development/design. Applied correctly, it results in predictable innovation, as the conceptualized offering is certain to address unmet customer needs.
2. Engineer/architect the product to perform the core functional job it is intended to perform
After a product is approved for development, the 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.
3. Enable the user to effectively interact with the product
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:
- Determine which user interface objects to use.
- Determine what actions the objects enable.
- Determine how to interact with the objects to trigger the desired actions.
- Trigger the desired actions.
- Confirm the desired actions are in process.
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, UX and/or UI designers, the industrial design team) better understand the metrics (desired outcomes) customers use to measure success when interfacing with a hardware/software/service offering.
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 tense, emergency situations. It also helped drive growth in what had been a stagnate market.
4. Design the customer experience to support users/others as they interact with the brand, company, and product throughout the product’s lifecycle
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 components 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 touchpoint experiences, whether digital 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.
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.
