As promised, in addition to regular posts on Practical Jobs-to-be-Done, I’m adding a regular open discussion as well. Sometimes I will suggest a topic, but this is your opportunity to ask questions, and my opportunity to think about the answers before posting them 😉. As long as there is demand and I have time available, I will try to do these weekly or bi-weekly.
I’m doing this to help you think through the application of jobs theory and the many ways it can be used beyond just product innovation. If I can’t answer a question, I’ll tell you and it will probably result in a blog post at some point.
One last thing, I don’t have the answer to Life, the Universe and Everything…unless it’s 42.
Excellent initiative, Mike. I do have a question ...
Considering that the JTBD is defined and mapped, ODI requires that needs are stated with a precise syntax starting with minimize / increase followed by a variable (cost, volume, etc.).
If I understand well, others, like you and THRV, for instance, propose that each job step is further broken down in things I want to determine / know, and find where they struggle, then need to be faster and more accurate in executing those steps.
How do you suggest then, if we abandon the minimize / increase syntax, how to ascertain that the need has been met? Is there anything you put after determine / know so that provider and client agree on satisfaction?
Fernando, I decided to go this direction because I've found there to be a fine balance between precision, and adoption. As I began working with design thinking teams it because obvious that their eyes glazed over looking at a strange new language and data points.
So, for a variety of reason I've simplified this, and it goes beyond just the statement itself. I feel like the statement as I've modified it is a more binary outcome. I KNOW something, for example.
As I've stated in another blog post, I was also intent on putting the results of our analysis into portable containers as a potential hand-off mechanism. To that end, outcomes must consistently support the step, which must support the job. This is why adapted the job story to be used as a test-fit structure in addition to potentially being that portable container. I looked back on prior work, and I found that none of the old structures would fit. Since integrating a hierarchy of universal, or consumption jobs is a challenge I've taken on, this level of consistency is an absolute must.
I haven't done enough testing to determine the delta in precision. But things that sit on the shelf will never be part of the denominator, so my goal is to make this more useful to more people.
I could not agree more, Mike. The original wording and structure of ODI adds a new layer of (mis)understanding that doesnt help at all.
The modification you suggest (precision <-> adoption) is absolutely relevant, since I am dealing with adaptive systems that are never 100% precise. The "end product" is some change in the environment -- including political changes -- that prevents any attempt at an engineering approach.
So I can easily go along the know / determine path, including the job story as you defined it.
At the same time, given the characteristics of my work, there comes a time when my clients and me have to agree that, yes, the project has yielded something that is less cumbersone, faster and accurate.
That is when, and only when, defining together with the client an indicator for the prioritized elements in each job step seems to make sense. And it is always some measure that has to go up or down.
So, for now, I've been breaking down the job steps and writing job stories as you suggest, but the process ends by agreeing with the client how they will *know* that their expected outcomes have been achieved.
Other considerations come into play, like the feasibility of measuring achievement, but those discussions shed light on what, exactly, the clients expect from the project and, consequently, from me.
I only use the job story to test-fit as I'm developing outcomes. I also end up re-tweaking the step language until it's just right. I've always thought we needed a systematic approach because subjectivity is what kills this.
Once we've done segmentation and have a handful of underserved (or overserved) outcomes, then each step might get one job story with one or more outcomes embedded. The container would also have to include verbatims in order to better elaborate the story. I'm still working on that, it could be different in each study
One other thing. I would ask a respondent to consider each outcome on for speed and accuracy while rating it on importance, and difficulty to achieve. I've explained that in a post as well. So, given that I'm not making that distinction I have a smaller set of outcomes.
Another thing I've come to realize is that verbatims are important. However, using the traditional ODI approach the only opportunity we have to collect them is from qualitative interviews. These people do not rate the outcomes, and therefore we don't what segment they would fall into. So, I believe it's critical be able:
1. go back to respondents that fall into a segment to have conversation about the outcomes that they struggled with, or
2. devise a method to tag prospects which quickly places them in a segment. Then we could go out get the stories from them, but ALSO have a tool to pass along to marketing who needs to be able to gain access to this target audience faster, and more accurately (haha)
Meanwhile ... I am trying to use JTBDs in one-off consulting projects. No segmentation, etc. but a very precise definition of the clients' challenge and their expected outcomes. It works very well. The hazy space between what is expected (subjectively) and what is indeed promised as a result of my work gets so much clearer.
Also, the exercise works as a mirror that allows the client to look at what they are trying to achieve, to the point that some clients are becoming interested in using the method as an internal competence.
The action verbs I have been using are discussed with the clients, and it becomes our common glossary for the engagement. There is so much noise to be cleaned up in the terminology, so that as we build the job map we have a chance to generate understanding there too.
I’m just starting to dig in and will be kicking off a JTBD research next week. So this is super timely. I’ll come back with some questions tomorrow morning :-)
Excellent initiative, Mike. I do have a question ...
Considering that the JTBD is defined and mapped, ODI requires that needs are stated with a precise syntax starting with minimize / increase followed by a variable (cost, volume, etc.).
If I understand well, others, like you and THRV, for instance, propose that each job step is further broken down in things I want to determine / know, and find where they struggle, then need to be faster and more accurate in executing those steps.
How do you suggest then, if we abandon the minimize / increase syntax, how to ascertain that the need has been met? Is there anything you put after determine / know so that provider and client agree on satisfaction?
Fernando, I decided to go this direction because I've found there to be a fine balance between precision, and adoption. As I began working with design thinking teams it because obvious that their eyes glazed over looking at a strange new language and data points.
So, for a variety of reason I've simplified this, and it goes beyond just the statement itself. I feel like the statement as I've modified it is a more binary outcome. I KNOW something, for example.
As I've stated in another blog post, I was also intent on putting the results of our analysis into portable containers as a potential hand-off mechanism. To that end, outcomes must consistently support the step, which must support the job. This is why adapted the job story to be used as a test-fit structure in addition to potentially being that portable container. I looked back on prior work, and I found that none of the old structures would fit. Since integrating a hierarchy of universal, or consumption jobs is a challenge I've taken on, this level of consistency is an absolute must.
I haven't done enough testing to determine the delta in precision. But things that sit on the shelf will never be part of the denominator, so my goal is to make this more useful to more people.
Hope that helps
I could not agree more, Mike. The original wording and structure of ODI adds a new layer of (mis)understanding that doesnt help at all.
The modification you suggest (precision <-> adoption) is absolutely relevant, since I am dealing with adaptive systems that are never 100% precise. The "end product" is some change in the environment -- including political changes -- that prevents any attempt at an engineering approach.
So I can easily go along the know / determine path, including the job story as you defined it.
At the same time, given the characteristics of my work, there comes a time when my clients and me have to agree that, yes, the project has yielded something that is less cumbersone, faster and accurate.
That is when, and only when, defining together with the client an indicator for the prioritized elements in each job step seems to make sense. And it is always some measure that has to go up or down.
So, for now, I've been breaking down the job steps and writing job stories as you suggest, but the process ends by agreeing with the client how they will *know* that their expected outcomes have been achieved.
Other considerations come into play, like the feasibility of measuring achievement, but those discussions shed light on what, exactly, the clients expect from the project and, consequently, from me.
Makes sense?
I only use the job story to test-fit as I'm developing outcomes. I also end up re-tweaking the step language until it's just right. I've always thought we needed a systematic approach because subjectivity is what kills this.
Once we've done segmentation and have a handful of underserved (or overserved) outcomes, then each step might get one job story with one or more outcomes embedded. The container would also have to include verbatims in order to better elaborate the story. I'm still working on that, it could be different in each study
Yes, you're making sense ;)
One other thing. I would ask a respondent to consider each outcome on for speed and accuracy while rating it on importance, and difficulty to achieve. I've explained that in a post as well. So, given that I'm not making that distinction I have a smaller set of outcomes.
Another thing I've come to realize is that verbatims are important. However, using the traditional ODI approach the only opportunity we have to collect them is from qualitative interviews. These people do not rate the outcomes, and therefore we don't what segment they would fall into. So, I believe it's critical be able:
1. go back to respondents that fall into a segment to have conversation about the outcomes that they struggled with, or
2. devise a method to tag prospects which quickly places them in a segment. Then we could go out get the stories from them, but ALSO have a tool to pass along to marketing who needs to be able to gain access to this target audience faster, and more accurately (haha)
Mike, I really can't understand why nobody is taking advantage of learning from you ...
I've been waiting for @Yassin to follow up on his comment :)
Meanwhile ... I am trying to use JTBDs in one-off consulting projects. No segmentation, etc. but a very precise definition of the clients' challenge and their expected outcomes. It works very well. The hazy space between what is expected (subjectively) and what is indeed promised as a result of my work gets so much clearer.
Also, the exercise works as a mirror that allows the client to look at what they are trying to achieve, to the point that some clients are becoming interested in using the method as an internal competence.
The action verbs I have been using are discussed with the clients, and it becomes our common glossary for the engagement. There is so much noise to be cleaned up in the terminology, so that as we build the job map we have a chance to generate understanding there too.
It has quite a few uses just on the qualitative side
I’m just starting to dig in and will be kicking off a JTBD research next week. So this is super timely. I’ll come back with some questions tomorrow morning :-)