If you're like me, you don't enjoy being subject to subjectivity. Let's be clear, subjectivity can be masked in rigor. We see this all the time in consulting and I'm certain it is prevalent in other enterprises as well. Subjectivity is not your friend!
Subjectivity can be and is often embedded in larger systems. As a result, we can easily lose sight of the fact that we've failed to complete the system because the subjective part is just a minor little thing. Unfortunately, something magical isn't going to happen in those cases. We need to do a little bit more hard work in order to find a way to patch that last pothole on the road to successful innovation - and ultimately help to make it easier.
Systems thinking is a discipline for seeing wholes. It is a framework for seeing interrelationships rather than things, for seeing 'patterns of change' rather than static 'snapshots.' — Peter Senge —
I've been working on Universal models for problems, markets, objectives, using Jobs-to-be-Done for a while and I've come to the conclusion that if I'm to do this independently - just like you are probably doing - that there needs to be a last piece to the puzzle to ensure that job maps are constructed both quickly and accurately.
I also believe that these models should be constructed once, and used many times. However, in initial phases of developing a catalog of jobs, none of us want this to take years to complete. The last time I checked, no one wants to wait for answers!
In Systems Thinking, the true wisdom often comes from a willingness to let go of past learning. — Pearl Zhu —
I continue to learn and in the pursuit of learning, I'm not only willing to let go of the past, I'm willing to take honest critiques of any ideas I share with you. So, I hope you will jump in, ask questions, challenge my thinking, or even troll me. While you may be completely wrong, your inputs could be a catalyst to formulate something that might be completely right.
I found a use for Job Stories
As many of you know, I'm not a fan of the way job stories have been used. In a nutshell, they appear to be developed immediately after qualitative research. Therefore, we do know that this makes them assumptions and not facts. The real challenge in innovation is to know and not guess. Thus, my criticism of developing a set of job stories that simply state what some consumers consider to be their pain in a situation that does not apply to the entire population.
While it can be useful for product improvement, pain is generally associated with a solution, and is therefore not a useful data-set for innovation. It's much better to have an established set of metrics that describe performance against an objective (Job), segment the objective using these metrics, and only then articulate where customers are struggling using a construct such as job stories.
One use of job stories is to bridge the gap between the problem-space, and the solution-space. Given that job stories are very similar to user stories, this seems to be a logical bridge (let me know if you disagree).
A new use for job stories is to test-fit your performance metrics and your job steps. What I've found is that historically job steps and metrics will not conform to a consistent integration structure. There is always some fiddling that needs to be done. It gets hidden underneath the rigor and rules of desired outcome statements, for example. This has nothing to do with the value of the data, it simply has to do with my desire to construct models with more consistent internal structure (the words fit between outcomes and steps better).
What I'm proposing is a new (somewhat adapted) job story structure that can be used to increase the consistency of your models. In conjunction with this, we will also need to simplify the metric structure. While there has been a lot of testing of the existing structure, I know from first-hand experience that attempting to integrate that structure with teams that have to consume it (design teams, for example) is problematic.
Since they are my customers, it's on me to transform my outputs to fit into their models...not the other way around. Simply giving them a dashboard of metrics doesn't suffice. Also, if I have to transform my own outputs after-the-fact then that tells me that I need to work on the inputs and/or the system. So, I'm working on both and this is a work-in-progress.
This is an example of a job (test-fit) story:
As a [Job Executor/Beneficiary] + who is + [Job] + [Situation]
you're trying to [Outcome] + "faster and more accurately"1
so that you can successfully [Job Step]
Note: we won't know the situation until after we go through a quantitative phase. Situation options are evaluated along with the Job model so we can explain needs-based segments based on their situations. The other method presumes the situation...which means it's almost always wrong. So, for testing-fitting, you can exclude the Situation.
If we were to take a job step, and a customer success metric that we're working on, we can quickly do a test-fit (just like a wood-worker will do a dry-fit) before making a final commitment, and without a lot of other people's opinions. A test-fit could cause you to make a change to your success metrics, or it could cause you to reconsider the job step.
Let's take a look at a few metrics from a step in the job Marketers have when Developing a Qualified Lead (FYI - I've completely redone this model, and the update is coming right after this post as a series):
Select a target audience
Know2 what potential target audiences exist
Know which needs are a priority for each audience
Know how your solutions address the needs of each target audience
Know how much each audience spends to address their needs
Know how frequently each audience spends money to address their needs
Know how motivated each audience is to find a new solution
Test-fit One
As a Marketer + who is + developing a qualified lead you're trying to know which needs are a priority for each audience faster and more accurately so that you can successfully select a target audience
Test-fit Two
As a Marketer + who is + developing a qualified lead you're trying to know how frequently each audience spends money to address their needs faster and more accurately so that you can successfully select a target audience
Test-fit Three
As a Marketer + who is + developing a qualified lead you're trying to know how motivated each audience is to find a new solution faster and more accurately so that you can successfully select a target audience
Summary
I'm sure you can see that I've changed the way I structure metrics. Of course, this will need to be tested more thoroughly, but I already know that the way I learned to do it is not resonating with my customers, and I would rather change it on the front end, than potentially change the meaning of the data on the back end.
As I've said, I’ve been unable to run some other models I've worked with through this test-fit without altering the structure of it numerous times for a single model. This works, so I'm going with it for now and we’ll see how it works.
I'd rather be approximately right that exactly wrong.
If you’d like to be involved with a more interactive platform, I have a Telegram channel that feeds into a chat group. The more people that get involved, the more active it will become.
A former colleague (Eric Eskey) started using this word a lot and I realized how powerful it is. It’s truly an outcome, and it’s much more consumer friendly
Thanks, Mike, very interesting article.
In the section "Select a target audience" step 4 needs fixing up. This seems to be a mish-mash of "Know how much it costs each audience to address their needs" and "Know how much each audience spends to address their needs".
I would say the latter is more important, because an audience may not yet have found a solution (such as the one you're trying to sell them) to spend their money on, but there will always be an associated cost.
I'm going to try this on a product I'm developing, https://www.dickynotes.com.