| This post is PART 4/6 of a paper entitled “Origins and Progression of Jobs Theory.” Summary—It is argued that ambiguity around customer needs and customer value is the root cause of innovation failure; jobs theory is built on prior theories of customer behavior; how JTBD became bifurcated creating two schools of thought; the two schools are synthesized to create the JTBD framework; post synthesis, JTBD concepts are expanded and refined. |
Read paper from the beginning
In January of 2002, a landmark article entitled “Turn Customer Input into Innovation” by Anthony W. Ulwick appeared in the Harvard Business Review. In this article, Ulwick describes an outcome-based methodology that involves deconstructing the activities associated with using a particular product or service. He suggests that customers perform these activities expressly to accomplish logical objectives, called job steps, that together represent the logical process associated with a particular job. Ulwick asserts that customers must accomplish all job steps to successfully execute a job (1).
In his book “What Customers Want” published a few years later in 2005, Ulwick builds on this job process to create a comprehensive methodology he calls Outcome-Driven Innovation or ODI for short (2). As such, the job process framework, and more generally jobs-to-be-done, is at the core of ODI. Although Ulwick refers to this job process by a few different names over the years, I refer to it here as the job process framework for consistency (see Figure 8).
(Figure 8)
To put a finer point on it, each discrete job activity is associated with a specific job step that customers are trying to accomplish by way of that activity. To be clear, a particular activity (or set of activities) is called “discrete” when it is required to accomplish a specific job step. As such, that activity is separate and compartmentalized vis-à-vis the additional activities that must be performed to accomplish other job steps.
Think of a single job step as an end point or goal toward which a particular activity can be logically directed. Without such a goal, a discrete activity would be aimless or nonsensical which is not consistent with how jobs get done. Therefore, all the logical steps associated with executing a particular job delineates job process logic. A job process is “logical” because activities must be orchestrated in a way that are collectively capable of generating desired results. That being the case, the execution of any job process characterizes purposeful behavior. Together, job activities and their corresponding job steps operationalize job process execution (see Figure 9).
(Figure 9)
For each discrete activity comprising a job process, customers have one or more criteria they use to gauge how efficiently the corresponding job step is accomplished via that activity. Customers also have criteria to gauge the perceived effectiveness of a discrete activity with respect to its contribution to generating wanted results.
In Ulwick’s job process framework, these criteria are called “desired outcomes” and they represent the customers’ needs with respect to job execution. As Ulwick states in his book, What Customers Want, “Desired outcomes … are fundamental measures of performance that are inherent to the execution of a specific job.” Simply put, desired outcomes are performance criteria that determine how well a job is executed in the mind of a customer.
Because customers use products and services to help them get jobs done, these solutions involve the co-execution of jobs via—physical products (i.e., service appliances), provider organizations, digital agents, and/or non-providers. Co-job executors perform some or all of the job activities required to generate wanted results.
As customers interact with a particular solution(s), they experience immediate consequences or outcomes from those interactions regardless of who or what is performing job activities. It is worth emphasizing that these outcomes occur while job executors are performing activities and should not be confused with job steps—which are the logical objectives that customers are trying to accomplish via activities.
Customers evaluate the efficiency and perceived effectiveness of solution interactions by comparing the actual outcomes of those interactions against desired outcomes—their performance criteria for successfully executing a job. Customers have a good experience using a particular solution to the extent that actual outcomes meet expectations as defined by desired outcomes.
Because desired outcomes are tethered to job process logic, these performance criteria are independent of solutions. That is, solutions come and go but the criteria customers use to evaluate the efficiency and effectiveness of solutions remains the same as long as a job continues to be executed—usually well into the future. Stated another way, desired outcomes are the criteria used to evaluate the performance of solutions with respect to job execution, but solutions do not define them.
To summarize, job steps are the logical objectives customers are trying to accomplish by performing activities. In contrast, desired outcomes indicate how customers want to perform those activities as they try to accomplish job steps. As such, desired outcomes are the customers’ needs with respect to executing a job; they are independent of solutions and therefore stable over time. That being the case, desired outcomes are the criteria customers use to gauge how well a job is executed via solutions (see Figure 10).
(Figure 10)
Like the jobs theory model, Ulwick’s job process framework is well aligned with means-end theory. For comparison purposes, the comprehensive means-end model is again shown juxtaposed with jobs theory constructs (see Figure 11). Recall that the means-end model suggests that customers orchestrate a number of discrete activities with the help of solutions (the means) to achieve wanted results (ends).
A means-end chain consists of all the activities that customers are trying to perform in a particular solution-use context. As such, a means-end chain represents the “consumer process” linking wanted results to a customer’s behavior with respect to the purchase and use of solutions.
(Figure 11)
As a discrete activity is performed using a particular solution, certain outcomes occur due to customer-solution interactions (i.e., customer experiences). The outcomes that customers want to happen are called desired outcomes and these often differ from actual outcomes. Therefore, customers have one or more desired outcomes associated with each discrete activity. Customers achieve wanted results, as expected, to the extent that all the outcomes associated with the use of a particular solution(s) are capable of generating those results (3).
The limitation of means-end theory is that the desired outcomes associated with a “consumer process” cannot be defined without first knowing all the discrete activities customers are performing in a particular use context. By way of laddering interviews, customers are asked—what activities are you performing as you use this particular solution? And therein lies the problem. Customers can use different solutions to execute the same consumer process in the same use context. Different solutions structure activities in different ways—which is the nature of solutions. This creates a lot of diversity with respect to the activities customers are performing in a particular means-end chain.
That being the case, a lot of qualitative data must be collected from a number of different customers. That data is then coded, sorted and analyzed to surface the standardized sequence of discrete activities associated with a particular means-end chain. Once these activities are identified, customers are interviewed to ascertain all desired outcomes associated with those activities. The techniques involved in doing all of this are not only time and effort intensive, but they require knowledge of sophisticated statistical methods and tools. This is what makes the means-end approach very cumbersome to use and is partly why means-end theory has not been widely adopted by practitioners.
Ulwick’s job process framework is a much faster and simpler approach. Rather than focusing on the activities associated with a number of different solutions, job process logic is first defined independent of solutions-in-use. That is, job steps are delineated for a customer job irrespective of available solutions creating what Ulwick calls a “job map.” To aid in this process, Ulwick developed a universal job map template that depicts the generic structure of any job process. Adapting this template as a starting point to frame-out job process logic, innovators can quickly map out the job steps for any customer job.
With a job map in hand, customers are then interviewed to capture all the desired outcomes associated with the activities that must be performed to accomplish those job steps. It doesn’t matter that customers may be performing those activities in different ways via the use of different solutions. So long as customers are trying to get the same job done, they are also trying to accomplish the same job steps. As such, customers have the same desired outcomes with respect to performing job activities. Ulwick’s approach vastly reduces the time, effort and complexity of defining a complete set of desired outcomes for a particular job (4).
In short, I posit that Ulwick’s job process framework advances means-end theory. Introducing the concept of job steps to the comprehensive means-end model shifts the primary unit of analysis from solution attributes and activities to job process logic. In doing so, it becomes much faster and less complicated to capture all customer desired outcomes associated with a particular job. This overcomes a limitation of means-end theory that has impeded its broad adoption among innovators.
But more than that, Ulwick’s job process framework operationalizes the job process construct that remains non-explicit in the jobs theory model—the implications of which will be discuss going forward. An augmented (comprehensive) means-end model that incorporates job steps is depicted as Figure 12.
(Figure 12)
Job process logic is not apparent to most innovators because this logic exists in the background like an invisible substrate. Instead, the primary focus of innovation is most often on what can be seen, namely customer activities (aka: the customer experience). In fact, customers themselves are seldom aware of job process logic as a whole since they are faithfully following the routines structured for them by solutions. Because customers are oriented around using solutions, asking customers to define their needs with respect to getting a job done will likely yield suggestions about how to improve solutions-in-use rather than articulating their desired outcomes (5).
This is a subtle, yet important distinction. When the primary focus (aka: unit of analysis) of innovation is on solutions rather than the jobs customers are trying to get done, innovation possibilities are significantly constrained. For example, its often the case that innovation efforts start with mapping customer activities associated with specific solutions (aka: a customer journey map).
Customer “pains” and “hassles” associated with those activities are identified. Innovators then endeavor to solve the customers’ “problems” by enhancing existing solutions and creating new solutions. However, ideating on solution possibilities before defining and prioritizing all customer needs with respect to a job-to-be-done is like putting the cart before the horse, so to speak.
Innovation efforts that take this kind of “solutions-first approach” are naturally funneled into the current design paradigm of existing solutions (aka: the dominant design). Constrained within this paradigm, innovation efforts seek to incrementally improve, optimize or enhance the dominant design. With such a myopic perspective, companies can easily miss ground-breaking innovation opportunities since they often lie outside the scope of the current paradigm.
When companies fail to recognize such opportunities, they run the risk of getting blindsided by game-changing solutions introduced by competitors who recognize and successfully exploit those opportunities. Classic examples include the failure of Kodak and Blockbuster to recognize the potential of digital photography and content streaming until it was too late.
Ulwick suggests a better approach to innovation is to first understand all the customers’ needs with respect to getting a particular job done before ideating on possible solutions. This is accomplished by mapping all the job steps associated with a job, thereby defining the logical job process. The resulting job map provides the structure around which a complete set of customer needs can be quickly captured for that job. Customers are then asked to prioritize the set of needs. That is, customers rate each desired outcome for importance and the extent to which each desired outcome is satisfied by solutions-in-use.
An analysis of the importance and satisfaction ratings reveals which needs are under-served, over-served and appropriately served. Once this is clearly understood, innovators can enhance existing solutions and create new solutions that help customers get a job done better than competing alternatives at the lowest possible cost to the provider. Innovation efforts that follow this kind of “needs-first approach” are far more likely to create game-changing solutions with huge growth potential. Because innovators know in advance the value that customers want from solutions to get a job done better, innovation efforts become predictable rather than hit or miss (6).
Like Christensen, Ulwick makes no mention of means-end theory in his writings or presentations. Regardless of whether Ulwick was aware of means-end theory or not, his job process framework is nonetheless a significant contribution to this stream of research. Additionally, the job process framework operationalizes the job process construct implied by Christensen’s jobs theory model.
Christensen was well aware of Ulwick’s job process approach even before he first wrote about jobs theory in 2003. Notwithstanding this knowledge, Christensen chose to keep the job process construct non explicit in the jobs theory model. Instead, jobs theory focuses entirely on progress, even though, as Christensen posits, “a job is always a process to make progress.”
One reason I believe Christensen did not adapt Ulwick’s job process concept was that it was too meshed with Outcome-Driven Innovation (ODI), which was entirely proprietary at the time (protected by patents). Today, Ulwick’s job process framework as described here is in the public domain. However, other parts of the Outcome-Driven Innovation methodology remain proprietary.
Christensen may have also concluded that adapting Ulwick’s job process approach would make jobs theory too complex for the mainstream. This could doom jobs theory to the same fate as means-end theory. For this reason, Christensen strived to keep Jobs Theory relatively simple to increase its broad adoption among practitioners. Ironically, however, I assert that the lack of structure around the practice of jobs theory has hampered its broader use.
Continue to Part 5 of 6
References
1. Ulwick, A. W. (2002). Turn Customer Input into Innovation. Harvard Business Review, 80(1), 91-97.
2. Ulwick, A. W. (2005). What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services. New York: McGraw-Hill.
3. Reynolds, T. J., & Olson, J. C. (2001). Understanding Consumer Decision Making: The Means-End Approach to Marketing and Advertising Strategy. New York: Psychology Press.
4. Bettencourt, L. A., & Ulwick, A. W. (2008). The Customer-Centered Innovation Map. Harvard Business Review, 86(5), 109-114.
5. Ulwick, A. W., & Bettencourt, L. A. (2008). Giving Customers a Fair Hearing. MIT Sloan Management Review, 49(3), 62-68.
6. Ulwick, A. W. (2016). Jobs To Be Done: Theory To Practice. Idea Bite Press.
