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?