Everyone knows that in order to solve a problem, you first need to clearly identify it. Actually, that last statement is false! Not everyone knows.
Many will tell you that a problem should look something like:
- Our revenues (or margins) are declining and we need to find out why!
- We’re losing customers but we’re not sure where they’re going. Where are they going?
- People say we’re no longer innovative, find out why! Now!
A lot of times you’ll end up with a 150-page PowerPoint deck that essentially says….because…
- A made-up persona has migrated to a new (emergent) made-up persona
- Their job is done, they no longer need to do it, it’s over, help them create a new job (see jobs-as-progress) #zing
- Your marketing needs to be more personalized… therefore you need a CDP
In Jobs-to-be-Done we begin by defining the problem-space. This elevates the investigative lens and provides a beginning and an ending point to the scope. In terms of growth strategy formulation this elevation is critical.
It also recognizes that the things I mentioned in the bullet points above are symptoms, not problems; just as pain points relate to a product, not a goal or objective.
We look at the problem space in a unique way. At its core, it is a group of people trying to get a job done (an objective) and is best represented as a series of sub-objectives that we call Job Steps (or mini-jobs). Each step is a job in and of itself; but when its context is a step within another job, it is only broken down into success measures, not a job map. Think hierarchy.
Job Performer and their Role
Here’s something that drives me crazy. Someone, somewhere planted in the minds of noobs that products have a Job to be Done. It bothered me so much that 10 years ago I wrote this blog post to address it (this exchange was between a noob and a inexperienced practitioner).
The beginning of the process is very straight forward … it also creates the most analysis paralysis:
- Step 1: Identify the group of people (the proxy is a job performer, e.g. ,a consumer, a first-responder, etc.)
- Step 2: Define the Job and the Job Statement. I use the gerund form of the verb so I can more tightly integrate it into a set of statements used with prompt engineering. Cutting a piece of wood or Removing an anatomical structure instead of “Cut a piece of wood.” This structure is essentially a derivative of a process naming convention I learned from just about every book I’ve read on process and workflow modeling.
Since I provide tools to identify these for you, I’m not planning to go into the laborious detail that used to be necessary. If you’d like to learn a skill akin to ditch digging, here’s something I wrote several years back that takes you through the processes step-by-step. Ugh! 🤦🏻
When identifying these steps we have historically categorized them into 8 phases for product innovation and 9 phases for service innovation. I’m including all nine below.
Note: There are no decision loops in a job map. Think of it as a happy path even though you will see that things are very seldom happy once the data comes in - unless you look at everything on average (more on that later)
- iDefine: in the define phase, we want to know what aspects of getting the job done need to be defined, planned, or assessed by the job performer upfront in order to proceed
- Locate: in the locate phase, we want to know what items or resources - tangible or intangible - must be located, gathered, collected, accessed, or retrieved by the job performer to do the job
- Prepare: in the prepare phase, we want to know how the job performer must prepare or integrate the inputs, or the environment(s), from the Locate step to do the job.
- Confirm: in the confirm phase, we want to know what the job performer must verify, prioritize, or decide before doing the job in order to be successful.
- Execute: in the execute phase, we want to know the primary thing the job performer must do to execute the job successfully.
- Monitor: in the monitor phase, we want to know what the job performer must monitor in order to ensure the job is executed successfully.
- Resolve: in the resolve phase, we want to know what problem the job performer might need to troubleshoot, restore, or fix for the job to be completed successfully. [for service innovation]
- Modify: in the modify phase, we want to know what the job performer might need to alter, adjust, or modify for the job to completed successfully.
- Conclude: in the conclude phase, we want to know what the job performer must do to finish the job.
If you need a guide to help walk you through some of this, I created the original Jobs-to-be-Done Canvas a while back as well. Check it out 👇🏻
While I generally just maintain a list of Job Steps in a Notion database and put the metrics below them (with a toggle) …
…this is what most people do because that’s how they’ve been programmed by the powers-that-be. It’s a worthless artifact at any time prior to the final readout - and even then your stakeholders just want you to answer their freakin’ strategic questions!
So, what the heck do we do this map now?
The answer is …. we develop performance metrics for the model. And that is what I dive into next…