In the world of Jobs-to-be-Done the majority of the practitioners do purely qualitative exercises that are full of aspirations, biases, conflations and assumptions. Did I miss anything? They write Job Stories out of thin air, and we are asked to have confidence that “When an order is submitted, I want to see a warning message so I can avoid resubmitting the order” is useful for innovation.

Well, it’s not. What’s the difference between that Job Story and a requirement framed as “the ability to know when order information is incomplete before submitting so that…”? It’s not an input for innovation, and you can quote me on that.

I’m sure why people take this stuff seriously. I don’t see how adds anything useful to the product development puzzle, let alone the fuzzy front-end of innovation. This is not Jobs to be Done, and you should fire you whoever told you it was :)

Moving on…

I come from the software world, where (and when) we didn’t have creative design teams telling us what the user interface should look like or how a service should be designed or delivered. We just did it. But I’ve recently had the opportunity to work with designers outside of that world. My approach (Jobs to be Done) to generate insights also generates a LOT of data. The kind of data I generate is not the kind of data they are used to, so putting plots, charts and heat-mapped tables full of numbers in front of them was not going to fly.

They needed me to move closer to story-telling so they could grasp the foundation and conceptualize solutions within our capabilities more quickly. I haven’t moved this forward much so I’m always open to hear what you’ve done. I’m just sharing what I have and hope it helps those who are stuck in ODI analysis paralysis

I’ve been talking a lot about going back to select survey respondents to get verbatims that help you tell stories and capture emotion. While that will help you wrap a theme of underperforming success metrics into a nice package, the following is simply to help you package up each success metric individually (for now).

The following example is provided out of context, so it probably won’t make perfect sense to you. It is a miniscule part of a study on communication (one metric from one step). Oh, and this has been slightly modified to protect the innocent.

You’d think that given the amount of time we’ve been communicating with remote parties that the industry would be mature. Well, it and they are. There is more than one industry, which actually makes the job of communicating more difficult than it needs to be. This is why focusing on the job is more important than focusing on solutions or industries, if you’re looking for ways to bring new value to your current (or future) customers.

Develop a catalog of these (job sheets?) for a segment of job executors | end users | customers that are all indicating their desire for more | better performance from available solutions in the same way (an innovation segment, not a marketing segment)
Wrap it in a story that describes the segment
Support the story with verbatims (segment level)

This could be a powerful way to for you - as product strategy professional, innovator, or whatever you want to call yourself - to communicate your findings (targeting) to the teams that would much prefer to conceptualize products and services they know will win in the market than conceptualizing losers and iterating until they find the right problem.

Even Steve Blank has backed away from that, I hear.

I’m sure I’ve stolen this layout from somewhere, so if it was you, thanks! Lemme know what you think, and if you have something to share, please do so below 👇

Thank you for reading Practical Jobs-to-be-Done. This post is public so feel free to share it.

Share

Practical Jobs-to-be-Done

Communicating Jobs-to-be-Done Opportunities…