Job Stories – Burning the customer perspective in

Sharing: facebook, twitter


Disclaimer: Alan Klement has done a lot more for Job -stories than me. It seems we had similar ideas at the time. I left it with a sketch. he pulled through. I now think that he is the originator of this concept.


Requirements management is a hard business. There are meters og literature on it that one can read and still agonize on what to do and how to do it. And then most of what’s written is on the details, splitting horizontal, vertical, horizontal AND vertical and so on. However, user stories are a de facto standard to document requirements – at least in the more agile oriented world.

As a <role>, I want to <action> so that <benefit>

Template User Stories

User stories describe solutions. That is a problem. But also, the role as well as the action, which are both guesses are a problem. Still, they make sense, as we at the end of the product process, when we hand them over to developers to develop a concrete solution. (Even here it has to be said that they might not be the only tool to be used. Pure design changes e.g. are hard to describe as a user story and is some kind of an abuse of the tool.) You realize that once you try to use it for that purpose. User stories being the only tool to describe requirements, brings with it the danger of thinking in solutions right away. And this is conflicting with the goals we have in early phases of product work, namely discovery. And this is the start of all products. Potentially, the start of any product work is limited by the tool that is used. So, what can we do when the task is still to discover which product to build and why? How to face the danger of even and earlier solution mindedness and coherence, which might even be hardened by the tool in use? This is where Job stories come into play: They describe customer needs to be met in their context, which makes them a much better tool for the early product phases.

Solution mindedness – the nemesis

Solution mindedness is the hell and abyss of early product development. But we all get hard wired for solution mindedness in every stage of our education. “I don’t want to hear about problems, I want solutions!” This makes it hard to avoid this trap. It feels unnatural to us.

I also have a hard time myself, to detach myself from solutions that instantly come to mind to product problems I am working on. In workshops I observe it all the time: It is and remains hard to focus on identifying, describing and understanding problems first, then validate them and only then work on a solution. But the thing is, only to go through that process means that we are not guessing but really understand what we are doing in products. But we just prefer the solutions, they are visible and observable – the hard work to get there may only be guessed.

The same is happening in customer research interviews, where I catch others and myself all the time, looking for ‘validation’ of my own hidden hypothesis rather than really listening to the problems that are hidden in plain sight. This is (not only) a modern product classic.

On a different level, bosses simply love to delegate solutions. “I observed the competition, they are doing XXX, so we also need XXX”. This makes clear that little thinking is done why this feature works or simply the communication of this reasoning is missing. But this also means, that we can only work on a solution without context and thus can not help by thinking in the context of the solution, as we do not know neither understand the problem to be solved in the background. Sometimes it is even less clear, if the solution to be delivered actually solves any problem. A better way, of course, would be to delegate a problem or a guessed problem and let a team either validate the problem or let it come up with a valid solution in our very own context rather than simply building things, which potentially no one needs.

In short: We love solutions. But this simply does not help as long as we do not understand which problems they solve and why and for whom. Everything else is simply guesswork and chance: the opposite of sustainable product development. As I meet this problem all the time, I thought on how to counter that and what helps is the simple concept of Jobs to be done (JTBD).

A Job to be done is what our product or service does for our customer at its core. It is what makes the client for what we have to offer, the essence of our offering in the customers mind. Whenever a customer pays for a product or a service, it fulfills a certain functional, emotional or other job. JTBD is a wonderful, simple model from Clayton Christensen, which helps us to focus on the value we create for our customers. Because the model is so simple, it sometimes seems a little abstract and trivial at the same time, as if we are missing something. But the beauty lies exactly in this simplicity. The following video is the classical explanation of the concept by Clayton Christensen himself using the example of trying to find out how to improve milk shakes with surprising insights on milk shakes (as long as you don’t know the example already):

And this is how to write down a JTBD as a Job story:

When  ______ (Situation), I want to _____ (Motivation), so I can ______(Outcome)

Template for Job stories

Although looking quite similar to a User Story, what the Job story does is something completely different: It expresses a customer problem or need in its context, leaving completely open how to solve that problem. This gives us the opportunity to start from a problem hypothesis and from there on involve a team in working out the solution. This is a good starting point to start working based on problems, their communication and their understanding. This will then result in a higher level of identification with that problem and more engagement form teams. The solution to be provided is not ‘ordered’ but worked out by the team.

JTBD are really easy to understand once they are defined. Through carrying their context with them, it gives us the opportunity to understand seemingly contradictory customer statements as coherent in their given context. An example from the banking area: Sometimes banks don’t understand that clients sometimes (ahem: most of the time) simply want to be left alone, but then the very same clients comes to the bank and wants to be treated like a queen. The point is, while everything seems to be the same from the banks perspective (same client, same employee, etc.), from the clients’ angle everything is different: In one case he wants to get some cash, in the next situation is is here for a loan to buy a flat. To the counselor it’s all about counseling in each case.

Stages of Requirements Management

Lets go through the different historic stages of requirements definition to get a different view of the role Job stories play:

Classical Requirements Management

A Product Owner is running around in the company collecting requirements from all kinds of stakeholders, informing the solution. The PO is more or less degraded to mediate between the different interests and more or less a technical project manager.

Agile Requirements Management

Here, the client perspective is integrated, by expressing the requirements from a client perspective by using user stories. This helps to inform everyone on the clients’ view on things and this helps to keep people better motivated by injecting some purpose. In addition to the tactical advantage of getting faster feedback by producing increments quicker through reduced batch size, this already much better. But still, we delegate solutions to the teams.

Job stories

The core is that now we start from a stated problem that is a research result. And by only starting work from a Job story, we enforce that research is done. And only from there we start to transform the problem into a solution in a team. This is how the deepest knowledge and motivation is generated.

This form of requirements definition helps get the perspective straight and to put the clients problems to be solved into the focus of our doing. Also, I realized that expressing customer problems in a positive way as a job to be done seems to be easier for most people. The other perspective, dry problem statements seem to kill and depress people. Job stories seem to feel like already pointing to the solution – a nice illusion that seems to help.

A little framework

The following illustration shows Job stories in the context of a product development process along the knowledge funnel:

Jobstories framework

  • Starting with research, we get a hunch of a client problem where we can help. (Hunch)
  • We then express the discovered need as a Job to be done in form of a Job story.
  • Then we try to find heuristics to solve that problem.
  • After that, we try to generalize the solutions into recipes.
  • The recipes we found will be expressed as user stories, which will then be developed. Based on that problem we can start exploiting our solution.

This delivers a nice framework in which the core of the product definition is realizing Job stories, which will then be transformed into solutions, expressed through user stories. If you try to follow this framework once, you will realize that this delivers a nice, holistic tool which also, as a side effect will enable you to engage in nice storytelling to convince your mangers and other stakeholders – simply because you know so much about the user, her problems and how you derived the solution. And this leads to a better level of alignment inside your company on why you are delivering what for whom – from the manager giving his commitment to the operations guy triggering the deployment.

What I described is a nice, little framework, to get from research to a product, by finding problems that are solved by solutions, all of which is formulated through job stories that are transformed into user stories.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>