Outcome statements define the customer’s success metrics at every step of a job

The real power of Jobs-To-Be-Done (J2BD) innovation approach comes from identifying and prioritizing a set of desired outcomes a customer wants to achieve in executing his job. Recall from the last article “Creating Job Maps to Gain Insight Into Customer Pain Points,” jobs are processes consisting of multiple steps. At each execution step of a job, a job executor is expecting so achieve specific outcomes.

Customers may not know “how” to get their job steps done better, but they will know quite accurately their level of satisfaction in getting their current job steps done. Not just the ultimate job outcome, but all the steps along the way in executing a job (or chain of jobs) from the beginning to the end.

But don’t expect a customer to be able to precisely articulate all of his desired outcomes to you. It’s not quite that easy because most customers aren’t thinking about their jobs in a structured innovation framework. It is up to us as developers and innovators to listen to and observe the jobs customers are trying to get done, and then translating the raw inputs into actionable information.

We need to probe deeply into the what, why, when and circumstances a customer faces when executing his job using qualitative research techniques. Qualitative research can include site visits,  in-depth interviews, ethnographic research and a combination thereof. In a future article we will explore how to conduct exploratory “jobs-to-be-done” research.

Depending on the complexity of a “job,” we can expect to uncover 50 to more than 150 desired outcomes form our exploratory research. The initial research will uncover a rich set of desired outcomes for us, but the information will come in the form of “unstructured data.”  We will need to translate the data into a common structure that we can further test and prioritize in subsequent rounds of quantitative research.

Structuring an Outcome Statement

A desired outcome typically states a direction of improvement (minimize or increase); a unit of measurement (number, time, frequency, likelihood); and what outcome is desired.

For example, if we listen to a field technician talk about the steps involved in installing a complex system, we might discover he really struggles with not having the right tool at the job site. Perhaps the right tool was never kitted in his tool box. Or because job site gets visually clutter and chaotic, tools get misplaced causing the tech to go searching for the tool, resulting in wasted time and frustration.

An outcome statement for this example would look like this:

With additional analysis of the unstructured data from the initial research, we might uncover several outcome statements like these:

1. Increase the likelihood of finding the right tool

2. Increase the likelihood of having the right tool on hand

3. Decrease the time it takes to find the right tool

4. Decrease the time it takes to store a tool

5. Increase the likelihood the tool will not be misplaced

6. Increase the likelihood of knowing if a tool is missing before coming to the job site

Structure provides a consistent definition of job success

You might be thinking that the outcome statements don’t provide specific specifications. That is correct. Specifications are created during the design and development phases of the NPD cycle and define a specific solution.

If we were to start collecting hard specifications during the discovery phase of research, we would have had to pre-determined a specific solution. Remember, a core principle of the job-to-be-done innovation framework is that it is solution neutral.

Our objective in the research stage is to get a clear understanding of what the customer is trying to get done, how he defines success in getting job steps done, and where he is struggling to improve his overall job execution satisfaction.

We want to get a sense of general direction of success and pain that helps define a trend and overall desired outcomes  by  the job executor. Don’t expect to get hard figures here!

Of course you might get some specific hard specifications during the initial exploration, and that may or may not be good. It may be good because it tells you a minimum or maximum parameter of an requirement that must be met. For example, a company might require all parts received in its warehouse have a specific bar code attached to streamline the receiving process.

But hard specifications “assumes” requirement based on a current solution. To innovate, we need to look beyond the current solution and imagine novel new ways to help customers achieve better outcomes in getting important jobs done. Perhaps a receiving department could speed up its time from dock to stock by using an RFID tag system and eliminate the step of scanning bar codes completely for example.

Be like Columbo and keep an open mind

So always be “solution” neutral when conducting jobs-to-be-done innovation research. And be like Columbo – the TV detective – keep an open mind and look for the nuances and contradictions  of the desired outcomes …  that’s where we can find opportunities to innovate.

In our next article, we will discover how to use outcome statements to create a rich set of unambiguous market driven data we can innovate around.

Here’ to detective work!

Kevin