Possibly the most important part of innovation — or consulting for that matter — is the ability to identify a target of opportunity. All too often, we begin with an idea — or worse, we ask a customer what their pain is. What seems to be customer-centric, is actually the chaotic beginning to a solution that will likely fail in the market, or an implementation that will fail to drive sustained business results.
Ideas are dangerous when they are not backed up with facts. Maybe I’m over-emphasizing the danger, but they are certainly not helpful in the real world if they are not repeatable; e.g. a process of generating ideas that turn into dominant solutions in the market can be executed over and over again with predictability. If you simply have an idea with nothing to back it up, it’s nothing more than a hypothesis. I can point to many a founder who had an idea…can’t remember their names right now. You don’t take Hypotheses to market.
The publicly emerging theory for analyzing markets, segments and products is jobs-to-be-done; made popular by Clayton Christensen. He made the term popular; but others were already developing frameworks which were a perfect fit with using the customer job as the unit of analysis when evaluating problems. But not all frameworks are alike, and some simply fail to provide the precision necessary before deploying capital to develop a new product, improve a process or enabling technology, or possibly a new market platform.
The User Story
While it is very popular amongst designers and some product managers, a recent suggestion asks us to throw away the User Story and replace it with what is called a Job Story. For a little bit of background, user stories are part of an agile, or hybrid agile product development process. They sit in the design space and typically incorporate both a simple story containing and actor and something they want to accomplish. Additionally, they should incorporate acceptance criteria and then elaborate them into user scenarios.
The structure is simple:
As a [product/system/service user or persona]
I want to [achieve a goal as a result of using the product/system/service]
so that [tangible benefits that will be realized after using the product/system/service]
An illustrative User Story
We can debate the structure of a user story and try to make it better; but clearly we need a tool for designers in order to build a product. One of the recent improvements in the user story world is User Story Mapping which brings the stories together along a spine that ensures that each iteration (especially the first) is complete. In other words, it helps us spot gaps in the design.
As someone who has both designed and coded many solutions I consider user story maps (and user stories) to be helpful. While not as detailed as traditional design specifications, there is value in an Agile approach that gets validation early from your customer — before it’s too late to make a change.
The Designers’ Replacement of the User Story
I have nothing against continuous improvement. Anything can be made better; even User Stories. But let’s stipulate something before we proceed — User Stories reside in the design space, not the problem space. It’s been suggested that user stories should be replaced with Job Stories — which is something that has been used in the problem space for many years. And then this “new” job story concept just plain gets it wrong. Let me explain…
Looking at the following example, one could get confused as to whether this is trying to define a problem, or define a solution — I’m not sure it does either. It’s certainly not a replacement for user stories — since they are in the design space — and it’s nothing like any job story I’ve ever seen — which normally sits in the problem space. So what is it defining? I don’t know about your customers, but mine expect me to provide solid evidence, facts and ultimately precision to the process of solving problems. Does the following do that?
“[moment of frustration] + [how progress is visualized] + [how life is better]
The job story encourages the product’s design process to focus on context, causality and motivations instead of assumptions, subjectiveness, personas and implementations”
While this structure and the comments preach that we shouldn’t use assumptions, or subjectiveness, I fail to see any evidence to back this structure up — do you? Let me share an example to make it clearer for you:
“When I’m presenting my visual design and I’m worried that people will reject its merits, I want something objective to back it up, so that people will see and discuss the design with less subjective bias.”
I’m not seeing any specific inputs to the design process here; nor do I see any evidence that one size fits all (do all designers have the same needs). While we can certainly make user stories better, this doesn’t even come close in terms of a design aide. Nor do I see it as a problem-solving aide. Perhaps it’s because the entire concept of what a job “is” has been re-defined in such an abstract way. Here is some more elaboration that may help you see what I mean…
“help motivate me, make me feel accountable, help me stop lying to myself and others, put me in control of my health, help me harness the love from my friends and family…These are Jobs”
Personally, I don’t think anyone can design or build a solution that could “help me stop lying to myself and others.” It sounds deep and insightful, I guess, but you can’t build solutions around emotional needs like “make me feel accountable;” especially if you expect them to succeed in the market. I also took exception to another “Jobs-to-be-Done” consultant who defined a job as “GIVE ME ACCESS TO HEALTHY FOOD!” It sounds more like an commandto me. Is there enough information there to be of any help?
Another way to look at these less than functional jobs is to think of them in conjunction with a solution devised that gets a functional job done, and in the course of doing so “increases a positive perception from friends and colleagues.” But, there is no way to create a solution that just makes you feel better (in general), or “put you in control of something.” Even the Pet Rock failed at “make me the life of the party” for more than a few months.
The Innovators Jobs Story
True job stories sit in the problem space. They are designed to communicate
- What it is that must be accomplished (in various contexts)
- Who needs to get the job done (we’ll get to personas later — this is not a persona)
- How success is measured by the “who” that needs to get the job done — in very specific and reusable terms
That last point is important because this is the evidence that will drive many things; including the development of personas, the targeting of underserved needs (or overserved), and the prioritization of efforts. This approach, as you will see, leaves very little to the imagination — while operating within the problem space. We leave imagination to the designers once they have been given the appropriate level of detail to target their efforts.
Since many others (including me) have gone through the Job identification, Mapping, and Outcome determination process before, I’m not going to spend time on that (I’ll put links at the end). Instead, I’m only going to focus on the structure of a Job Story (I’ll write a separate piece on integrating Job Stories and User Stories at some point).
As I first thought about this as a CRM consultant, I observed that the CRM space has a lot of functional jobs, and lot of roles that need to get them done. And each of these jobs has Steps; making it even more complicated. This is important because I’ve generally seen Jobs Stories articulated around a particular step; like so:
When [executing a particular step]…
Executors wants solutions that…
It’s worth pointing out that while we capture ALL needs when creating a Job Map (so we understand perfect execution of the Job), once they are scored it becomes slightly different. If we assume that the scoring process has provided enough differentiation across the metrics, we will have established multiple segments. In other words, groups that are all trying to get the same job done; but are struggling in different ways (e.g. they have different needs).
As a result, we are now focusing on a subset of metrics for a Job in specific context and a persona that is dictated by their subset of unmet needs. The following examples are demonstrated at the Job Level for brevity…
When using a 2-way radio in a [private security context vs a police officer context or a military context]
Private security professionals want solutions that…
[…subset metric 1]
[…subset metric 2]
[…subset metric N]
Since we have segmented the market using the metrics that have been collected, we now have a subset for each profile/personal/segment that we can use to write a Job Story. Keep in mind, that these are the unmet needs for problems we are trying to solve. Designers still have to deal with table stakes because you can’t design a car without brakes.
After some statistics, we’ve got the makings of a few stories
Below, I’m taking an example from one of Strategyn’s case studies — using the context of first-responders that need to communicate remotely while working in emergency or life-threatening situations (I’m pretty sure they feel accountable):
When communicating remotely with another party as a first responder
I want solutions that
— minimize the number of interruptions during a communication
— minimize the amount of interference encountered when communicating
— minimize the likelihood of making inadvertent chance to established settings
— minimize the effort to operate the device with gloves on
While getting the same job done, users of 2-way radios in the security space — who desire discreet or covert communications — would have a job story that might look like this:
When communicating remotely with another party as a security officer
I want solutions that
— minimize the effort required to communicate discreetly
— minimize the effort required to establish a record of the communication
— minimize the number of communications that can be intercepted
Create data-driven personas
It’s worth notingthat the higher level the job, the more likely that individual steps are going to have a number of differentiated outcomes. So, you can write these job stories around steps as well. At the end of the day, the metrics you incorporate into your story are there because the data says so. The last thing you want to do is listen to a designer solve for a problem that only exists in his or her head.
Since Jobs-to-be-done has always sat squarely in the front-end-of-innovation, rushing to the marketing and design steps is the same mistake that has been made repeatedly by companies and leads to our embarrassing success rate for new products, services and/or features. The entire purpose of Job Stories is to articulate unmet needs around specific steps in getting a functional job done — with very explicit supporting data.
A job needs to be something tangible like “Get my kids to school in the morning” and yes, I hate the current definition of personas as much as you do; which is why we establish them after we’ve collected the necessary differentiating data. Current personas are full of assumptions from marketing people that can’t get their minds beyond the simplistic categories that simply do not define common needs.
If you’re a Jobs-to-be-Done enthusiast, you really need to decide if your a problem solver, or a designer. Problem solvers require data to establish the problem, who it impacts, and in what context. Jobs-to-be-Done emerged to help us deal with the fuzzy-front-end of Innovation — which provides designers with the targeting necessary to create the right products, with the right features. To do that, they need User Stories 🙂