Why Job Stories trump User Stories? (Part 2/3)

6 min readApr 24, 2017

This is the second article in the three part series on the topic of Jobs to Be Done (JTBD). A three part series is just to underline how important JTBD is a methodology in building the right products. And the more I understand it, the more I feel there is to understand. Episode 1 was a foundational podcast on the subject from the very knowledgeable Amanda Ralph from Australia. However, as I dug deeper, I felt I needed more help to begin applying these principles to my work and thus needed handholding. Now that I understood the philosophy and the mindset, is there more to it? Are there tools and concrete processes that can be readily applied to my product teams. As I was struggling to get answers to some of these questions, I came to know about Alan Klement, who has written a lot on this subject and had also worked for the The Rewired Group, the original proponents of the JTBD methodology. Something about him fascinated me beyond bounds. Some of his blog articles had a radical take on user stories and challenged its effectiveness. He instead had invented something called the job stories. And this concept of his has become hugely popular and applied by people and companies all over the world. It didn’t take me more than a minute to decide that I should talk to Alan Klement next.

About Alan Klement

Over the years Alan has built businesses and products for himself and others. In doing so, he’s learned that he’s a maker. He loves working with people to research customer motivation, and then go on to create kick ass products and services. He has worked with The Rewired Group on JTBD projects and is a guest in prominent blogging platforms and podcasts. Alan is set to release his upcoming book on JTBD in March this year.

Subscribe to the podcast on iTunes

If you hard pressed for time to listen to the podcast, here are the highlights of the interview:

Q1. What’s the story behind the The Rewired Group, Bob Moesta and Clayton Christensen?

It was Bob Moesta’s team that worked in the Milkshake case study that Clayton talks about (in episode 1 of this series) in the video. And it was Bob himself who confronted the people who were buying the milkshake in that project. Both Bob and Clayton were at Harvard Business School during that time. Bob introduced JTBD to Clayton. Clayton then wrote about it in his very popular book Innovator’s Dilemma. When people responded favorably to the subject, Clayton asked Bob to focus deep on his work towards JTBD and offered to support him. And that’s how The Rewired Group was started.

Q2. How did you get to work with The Rewired Group?

They heard about my Job Stories and they reached out to me to do a podcast with them. They liked a lot of stuff that I was saying and offered me to do a few gigs together to see how it would work out. And that’s how I began working for them.

Q3. What is the problem with writing regular user stories?

Regular user stories don’t produce great conversations. The problem with user stories is that it discourages team communication. They are just another way to avoid talking-things-out and to have disconnected team members push tasks to another. The core problem with user stories is that they are just words — and words are open for interpretation. It’s a fundamentally broken technique; this is why there is so much writing (promotion) on ‘how to write user stories.

When I used to write user stories with my team, my teammates would read them, think they understand them and then go on with their own interpretation of the story, which ended up being different than mine. I started noticing the problem was with the user stories, and not me, when different engineers would interpret the same story very differently.

So I did something different: I stopped writing them.

Define problems, not solutions

User stories also fall into the all too common trap of defining a solution (what to do) instead of presenting problems to the team. Take acceptance criteria for example. You can only have accurate acceptance criteria when you know how something is implemented.

User Stories make too many assumptions

The other problem with user story is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome]) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.

Here’s the format Alan shares:

The first problem is that we start with a Persona, which is a very bad idea and then plop in an action which we think should be taken in order to achieve the expected outcome.

Let’s look at a sample user story:

In the above chart, when someone reads moderator or estimator is that really adding anything? If anything it’s adding ambiguity to the flow. You and I are going to attach our own interpretation of what a moderator is or why they are in these particular contexts.

Q4. How does a job story solve the above-said problems?

Job story is all about Context and Causality. Each job story should provide as much context as possible and focus on motivation and forces instead of just implementation.

For me, Job Story has evolved over the years. At first, it was a mix of emotions and tasks. Now I prefer the Job Story to be as emotional as possible.

The format I prefer now is:

[ A moment of frustration ] + [ how progress is visualized ] + [ how life is better ]

An example of this would be:

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.

Q. (25.00) Why are personas ineffective according to you?

Because personas focus on creating a story made up of a customer’s attributes, instead of a story that explains a purchase, personas leave the brain in a unsatisfied state. To fix this, in just a split second, the brain decides to make up it’s own story. Because of this, Personas have destructive effects on an organization. As each team member reads a persona, they will subconsciously fill it with their own assumptions which differ from everyone else.

Designers make Personas bigger and more rich in the hope of gaining more context about them. Some Personas can be 1–2 typed pages which meticulously describe attributes of these imaginary customers.

Yet, no amount of colorful attributes can fill the gaps our brains will automatically fill when reading Personas. These missing gaps are the causalities which drove the customer to consume a particular product.

When reading a Persona, the brain craves a story that ties everything together. If the story lacks causality, it will struggle to create that story, and will eventually just make up it’s own causalities.

Links and resources mentioned in the podcast:

Innovator’s Dilemma by Clayton Christensen: http://www.amazon.com/The-Innovators-Dilemma-Revolutionary-Business/dp/0062060244
Podcast by The Rewired Group on JTBD: JTBD Radio
5 tips for writing a job story: https://medium.com/the-job-to-be-done/5-tips-for-writing-a-job-story-7c9092911fc9#.lcimdwxa7
Replacing personas with characters: https://medium.com/down-the-rabbit-hole/replacing-personas-with-characters-aa72d3cf6c69#.hxxp4ao8f
Alan’s website: http://alanklement.com
Alan’s most popular article about Job Stories: http://www.alanklement.com/replacing-the-user-story-with-the-job-story
Alan’s guest article on Intercom: https://blog.intercom.io/using-job-stories-design-features-ui-ux/