Building a Jobs-to-be-Done Map for Getting a Problem Fixed
I'll walk you through a Universal / Generic Model for Jobs-to-be-Done research
Creating jobs-to-be-done maps (aka Job Maps) doesn’t have to be that intimidating. What most people don’t do well is follow the rules. I have to admit that after learning all of the rules for Outcome-Driven Innovation I tend to cringe when I see people break them. Sometimes it’s because they learned them 10 years ago - when they were different - and other times it’s simply because they don’t understand them.
There is also a lot of emphasis on the jobs-to-be-done interviews as well. I’ve contributed to that emphasis myself...
Generally speaking, you can make a lot of progress on a job map before the first interview. When you are studying consumer related jobs, most of us have done them many times. In these cases, you can use your common sense, and some basic desk research to make a lot of progress. If you’re studying highly skilled professional jobs, the context and the terms will definitely require some additional time in front of those professionals to ensure you don’t miss anything or misstate anything.
At the end of the day, however, the mapping itself should be highly logical and highly consistent in structure.
Many rules in jobs-to-be-done seem to be introduced in order to pursue a perfection that may not add additional value to the average researcher. In fact, they can become so burdensome that people mis-interpret them, or worse, discard them out of expedience. So, let’s just begin this process by discarding almost all of the rules you learned about desired outcome statements.
That means I don’t have to list them here because my new structure conforms to almost none of them.
Regarding the universal job map, I always start with it. But if the initial results begin to break my test-fit model I simply make the necessary changes so my model makes sense to the average person. After all, I’m just an average person and so are most of us. Let’s review the test-fit one more time before we begin:
As a [Job Executor/Beneficiary] + who is + [Job] + [Context] you're trying to [Outcome] + "faster and more accurately" so that you can successfully [Job Step]When you plug your outcomes and steps into the job, read them back to yourself. If it doesn’t make sense, or it doesn’t sound right, fix it. Sometimes that will mean re-evaluating the step. Other times it will mean moving the outcome statement to a different step. And other times it will make you realize that there is a new step required.
All of these things 👆 happened as I was developing this map, which I did in stages (i.e., I did a first pass, let it sit for a few days, 2nd pass, etc.)
I’ve selected a rather simple job that is universal enough (not specific to a product or situation) that we have all experienced it. I did not interview a single person to develop this map. As a result, it would be imperfect for specific products, services, contexts or situations. But you could certainly take this and make the necessary modifications to address those specifics. But, as a starting point, just ask yourself what you’d need to know, avoid, verify, understand, etc. in order to successfully complete the step.
It may even be imperfect as a universal model. But who cares? I’m not pursuing perfection; I’m pursuing significantly better than everything else I’ve seen. So, let’s have a look at people who are trying to get a problem fixed.
Please note, this is not people trying to fix a problem. The focus here is on obtaining help from a 3rd party who provides support for the problem you are experiencing. It could be a technical support phone number, a physical service center, etc. You could make this more specific, or you could simply add screening questions to capture the various channels or contexts that you can use to take different cuts at the outcomes and/or needs-based segmentation. This might require larger sample sizes, however. I'm not getting into a comprehensive survey design here.
This model also does not present the other side of the job-to-be-done, or the people who are actually fixing the problem. I do have that one as well 😎
Getting a problem fixed
As a refresher, when developing a survey, put each step on a single page and have respondents rate each statement on two dimensions, importance and difficulty as follows:
Decide to get help
The first thing we need to do is to decide if we need to get help from a 3rd party...
Know the difference between a potential problem and a current problem, i.e., a risk vs. an issue (Note: I did this instead of duplicating outcomes for potential and current problems. You could break them out in your model if you like)
Know when there is a potential | current problem
Identify the scope of the problem, e.g., isolated, pattern, widespread, etc.
Identify the severity of the problem, e.g., current risk, actual issue, impact of risk or issue, etc.
Identify the root cause of the problem
Know what steps you can take to solve the problem yourself
Know what resources you will be asked to provide if you need help
Ensure that you have exhausted all possibilities on your own
Get the outside help you need
Once we’ve decided that we need help from a 3rd party we need to access that help…
Know what sources of outside help are available, e.g., phone support, in-person support, in-home support, etc.
Avoid restrictions around where you can get help
Know when outside help is available, e.g., store hours, on-site times, phone support hours, etc.
Avoid restrictions on when outside help is available
Confirm that outside help will be prepared when it is scheduled
Know where you can start the support process, e.g., websites, phone, stores, in-app, etc.
Avoid restrictions on where you can start the support process
Know who to contact when you start the support process
Avoid restrictions on who you can contact when you start the support process
Know the estimated amount of time to get your problem fixed
Make contact with the selected support provider
Find the right support contact on the first attempt, e.g., one who has been assigned, one with the right experience, etc.
Convey the problem to your support contact
Once we’ve accessed the 3rd party help, we need to communicate our problem to them so they can prepare for their diagnosis...
Ensure that your support contact is familiar with your product | account | situation | circumstance
Share the information that is requested by your support contact
Verify that you only shared what was specifically needed to solve your problem
Understand the scope of your problem, e.g., isolated, pattern, widespread, etc.
Understand the severity of your problem, e.g., current risk, actual issue, impact of risk or issue, etc.
Ensure that the problem can be fixed
The support contact can then begin to diagnose the problem to come up with a corrective plan and we want to know that there is a high likelihood that they can do it....
Verify your support contact has the tools | methods needed to identify the root cause of your problem
Verify your support contact has the experience needed to identify the root cause of your problem
Verify your support contact has the time needed to identify the root cause of your problem
Verify your problem is completely understood by your support contact, e.g., they can restate it, they are paying attention, etc.
Verify your support contact knows the steps needed to identify the root cause of your problem
Confirm your support contact follows the steps needed to identify the root cause of your problem, e.g., doesn’t take shortcuts, etc.
Confirm that your support contact identifies the root cause of your problem
Get the problem fixed
With a corrective plan in hand, they can begin to fix the problem...
Ensure your support contact knows the recommended steps to fix your problem
Verify the recommended steps will not create more problems
Provide any resources requested by your support contact, e.g., information, permissions, components, etc.
Verify your support contact has the tools needed to fix your problem, e.g., physical tools, methods, procedures, etc.
Verify your support contact has the parts to fix your problem
Verify your support contact has the experience to fix your problem
Know how long it will take to get your problem fixed
Verify your support contact has the time to fix your problem
Verify your problem has been fixed
Not only will our support contact attempt to verify that the problem has been fixed, but we also need to make sure it’s fixed...
Know that your support contact followed the recommended steps needed to fix your problem
Know that the entire scope of the problem has been addressed, e.g., isolated, pattern, widespread, etc.
Know that the severity of the problem has been addressed, e.g., current risk, actual issue, impact of risk or issue, etc.
Know that the root cause of the problem has been addressed, i.e., not symptoms, etc.
Know that new problems did not emerge while fixing the original problems
Know that your service is now working as expected
Update the plan to fix your problem, if necessary
If something went off track, we need to understand the next steps required to get it fixed...
Know when the timeline to fix your problem has changed
Know why the timeline to fix your problem has changed, e.g., what went wrong, etc.
Verify your problem has been given a higher priority, e.g., moved to the front of the line, more experienced point of contact, etc.
Verify new support contacts know what has already been done
Avoid having to provide the same information again
Provide new information that is requested by your point of contact
Address future problems on your own
Once the problem has been fixed, we want to make sure we have a higher level of awareness about this problem going forward in order to avoid it, or correct it ourselves...
Know how to spot the same risk before it becomes a problem
Know how to fix the problem
Avoid having to get help for the same problem
Jobs-to-be-Done Model for Get a Problem Fixed © 2022 by Michael A. Boysen is licensed under Attribution-NonCommercial-ShareAlike 4.0 International
Sometimes it’s helpful to see a job map in visual form. Don’t waste your time creating one until you are completely done fiddling with the structure, though.
This could probably use another review. If you see anything that shouldn’t be in the model, anything out of place, anything that doesn’t pass the fit-test, or anything that is missing, please feel free to point it out. I want you to find things so that others can learn from it.
Hello, Mike. This is an excellent map for complicated problems.
If we face a complex problem, there is no way to find root causes in advance. They only become clear in retrospect. For instance: if a service is underperforming, there is a multitude of recursive causes and effects at play: technical, political (external), market, marketing, political (internal), HR-related, etc.
Converging at one or two of them at the outset would lead to biased interpretations.
So, yes, excellent map for complicated problems. And a useful simplification in terms of problems and issues.
I also like to differentiate between problems and dilemmas. A problem has to be solved; a dilemma must be conciliated. A typical example would be centralize x decentralize decision rights,
In my opinion, this is not a once-for-all decision. We decentralize because we have problems related to lack of engagement, slow reaction, and so on. And we centralize because we are losing control, compliance, effectiveness, etc.
Confusing problems with dilemmas leads to negative behaviors since whoever thinks that the problem has been solved will rely on enforcement actions to make the "solution" work -- even when the pendulum has moved towards the other pole, and the original decison (for instance: centralize x decentralize) has become disfunctional.
While problems have to be solved, dilemmas have to be managed.
Makes sense?