Jobs-to-be-Done Theory, when applied effectively, makes innovation 5-times more predictable. Our 25-year track record applying the theory with our Outcome-Driven Innovation process offers that evidence—and it is no surprise as to why it works. Jobs-to-be-Done Theory offers a foundation for addressing the three key questions companies must answer correctly when trying to make innovation more predictable: (1) What are the customers needs? (2) Which needs are unmet, and (3) Are there segments of customers with unique sets of unmet needs? With this knowledge companies can more effectively position and improve their existing products and create altogether new products that customers will want.
The qualitative and quantitative research methods we have developed as part of the ODI process are effective and precise at answering these questions. The process begins with the discovery of the 100+ metrics customers use to measure success when getting a job done. Each desired outcome statement is then prioritized by a statistically valid sample of representative customers so we can determine which outcomes are underserved and if segments of customers exist with different unmet needs.
As the benefits of Jobs-to-be-Done Theory are becoming more apparent, companies, entrepreneurs and prospective practitioners have been eager to put the theory into practice. In doing so, many have created or adopted their own practices, that unbeknownst to them, are likely to fail. One such practice is of particular concern.
New books and articles on the subject are leading users to believe that putting the theory into practice simply means discovering or defining the job or jobs that the customer is trying to get done. While this is an important step in our ODI process, it is just the first step in a more complex process. Discovering what job the customer is trying to get done only helps to define the market to target. Knowing what the job-to-be-done is does not tell you what the customers needs are at the level of granularity needed to make innovation more predictable. Nor does it tell you which of those 100-plus needs are unmet or if unique underserved or overserved segments of customers exist.
Despite this fact, I see many instances where companies and entrepreneurs believe that knowing the customer’s job, and creating a job story around that job to add context, will increase their chances for success. Going from a “compelling job story” to ideation to concept testing is their goal, but following this approach is unlikely to lead to predictable innovation because it fails to provide answers to the questions that make innovation more predictable.
A job story is really just a glorified persona—a story of a customer’s observed functional and emotional jobs built around qualitative data, void of the quantified details that make it a real target. Just as segments of customers defined around demographic and psychographic data are phantom segments, so are those built around a qualitative-based job story. What are the chances that a job story will correctly define a segment of customers with 15 unmet needs without the quantitative data needed to discover the segment or the unmet needs? Realistically, they are near zero. There really is no shortcut to predictable innovation. Without the quantitative data needed for success, innovation remains a guessing game.
So where should companies, entrepreneurs and prospective practitioners start? By creating a job map and a complete set of customer desired outcome statements as described in the book JOBS TO BE DONE: Theory to Practice. In this book we introduce the Jobs-to-be-Done Needs Framework (see Figure 1).
This framework provides a model for (i) categorizing, defining, capturing, and organizing all your customers’ needs. It introduces the types of customer needs that must be considered to gain a deep understanding of what a customer is trying to accomplish. They include (i) the core functional job-to-be-done, (ii) consumption chain jobs, (iii) the desired outcomes tied to the core functional and consumption chain jobs, (iv) related jobs, (v) emotional and social jobs, and (vi) the buyer’s financial desired outcomes. For a given market, all needs are defined and centered around the customer’s core functional job-to-be-done.
The Jobs-to-be-Done Needs Framework provides companies a common language around which to define customer needs. It takes a multilayered and complex set of inputs and shows how they should be categorized and organized, why they are captured, and how they should be used. The framework brings order to a historically chaotic practice. Knowing what types of needs exist and what a “need” is changes everything.
Once all this data is collected, quantitative research can be conducted to determine which needs are unmet and what customer segments exist with unique unmet needs. This is the information that will lead to the creation of a “persona” or segment description that will point to a quantitatively derived, not a phantom, target.
I coined the phrase “Job Story”.
This author misrepresents what they are and their intent.
>A job story is really just a glorified persona—a story of a customer’s observed functional and emotional jobs built around qualitative data, void of the quantified details that make it a real target.
(1) A Persona is a fictionalized customer archetype. They were introduced in Alan Cooper’s book “About Face: The Essentials of User Interface Design”. Since Job Stories don’t aren’t fictionalized and don’t describe the customer, I don’t see how they are comparable.
(2) A Job to be Done does not describe functionality. Hence, a Job Story does not describe functionality. They are specifically meant to avoid doing so. That is why they start with “When [something happens]”. The reason why Job Stories are so popular and powerful is because they replace User Stories – which do describe functionality.
(3) Job Stories do not describe the Job to be Done. They only describe the circumstances which a JTBD arises. If you want to design a solution which helps some with the Job to be Done of “Give me the independence to go where I want, when I want”, the innovator needs to know when the consumer engages in that Job.
How can you design an appropriate solution for a customer, unless you know the context in which they plan on using it?
We often forget the importance of coining terms… Except for the coiners. What’s next?