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...

How to get results from Jobs-to-be-Done interviews

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...

1. 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)

2. Know when there is a potential | current problem

3. Identify the scope of the problem, e.g., isolated, pattern, widespread, etc.

4. Identify the severity of the problem, e.g., current risk, actual issue, impact of risk or issue, etc.

5. Identify the root cause of the problem

6. Know what steps you can take to solve the problem yourself

7. Know what resources you will be asked to provide if you need help

8. 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…

12. Know what sources of outside help are available, e.g., phone support, in-person support, in-home support, etc.

13. Avoid restrictions around where you can get help

14. Know when outside help is available, e.g., store hours, on-site times, phone support hours, etc.

15. Avoid restrictions on when outside help is available

16. Confirm that outside help will be prepared when it is scheduled

17. Know where you can start the support process, e.g., websites, phone, stores, in-app, etc.

18. Avoid restrictions on where you can start the support process

19. Know who to contact when you start the support process

20. Avoid restrictions on who you can contact when you start the support process

21. Know the estimated amount of time to get your problem fixed

22. Make contact with the selected support provider

23. 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...

24. Ensure that your support contact is familiar with your product | account | situation | circumstance

25. Share the information that is requested by your support contact

26. Verify that you only shared what was specifically needed to solve your problem

27. Understand the scope of your problem, e.g., isolated, pattern, widespread, etc.

28. 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....

30. Verify your support contact has the tools | methods needed to identify the root cause of your problem

31. Verify your support contact has the experience needed to identify the root cause of your problem

32. Verify your support contact has the time needed to identify the root cause of your problem

33. Verify your problem is completely understood by your support contact, e.g., they can restate it, they are paying attention, etc.

34. Verify your support contact knows the steps needed to identify the root cause of your problem

35. Confirm your support contact follows the steps needed to identify the root cause of your problem, e.g., doesn’t take shortcuts, etc.

36. 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...

37. Ensure your support contact knows the recommended steps to fix your problem

38. Verify the recommended steps will not create more problems

39. Provide any resources requested by your support contact, e.g., information, permissions, components, etc.

40. Verify your support contact has the tools needed to fix your problem, e.g., physical tools, methods, procedures, etc.

41. Verify your support contact has the parts to fix your problem

42. Verify your support contact has the experience to fix your problem

43. Know how long it will take to get your problem fixed

44. 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...

45. Know that your support contact followed the recommended steps needed to fix your problem

46. Know that the entire scope of the problem has been addressed, e.g., isolated, pattern, widespread, etc.

47. Know that the severity of the problem has been addressed, e.g., current risk, actual issue, impact of risk or issue, etc.

48. Know that the root cause of the problem has been addressed, i.e., not symptoms, etc.

49. Know that new problems did not emerge while fixing the original problems

50. 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...

51. Know when the timeline to fix your problem has changed

52. Know why the timeline to fix your problem has changed, e.g., what went wrong, etc.

53. Verify your problem has been given a higher priority, e.g., moved to the front of the line, more experienced point of contact, etc.

54. Verify new support contacts know what has already been done

55. Avoid having to provide the same information again

56. 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...

57. Know how to spot the same risk before it becomes a problem

58. Know how to fix the problem

59. 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.