index.md 24KB
title: 5 Tips For Writing A Job Story
url: https://jtbd.info/5-tips-for-writing-a-job-story-7c9092911fc9
hash_url: 9d00487443
A Job Story is a powerful way to facilitate team conversation and discovery when designing products. They are meant to cut right to the job to be done by eliminating distractions. The job story encourages the product’s design process to focus on context, causality and motivations instead of assumptions, subjectiveness, personas and implementations.
Want more? Download a free PDF book about JTBD or buy it in paperback & kindle
As I write more job stories, I’ve been paying attention to characteristics which make some stories better than others. When a story is well done, it helps me and my team cut right to what needs to be discussed and puts us all on the same page — making the product design process dramatically better.
Here are 5 tips which will help when writing Job Stories:
- Refine A Situation By Adding Contextual Information
- Job Stories Come From Real People Not Personas
- Design Modular Job Stories Which Features (Solutions) Can Plug Into
- Add Forces To Motivations
- Job Stories Don’t Have To Be From A Specific Point Of View
1. Refine A Situation By Adding Contextual Information
When David Wu described to me how a situation can capture a whole set of conditions, it struck a chord with me. When I add more context to a situation, I’ve found that it’s easier to design a working solution which also handles any anxieties which can push a customer away from using a product or feature.
Let’s compare:
- When I want something to eat….
- When I’m in a rush and want a something to eat….
- When I’m in a rush, I’m starving and want something to eat….
- When I’m in a rush, starving, need something I can eat with one hand while ‘on the go’, am not sure when the next time I’ll be able to eat, …
The more context we have for the situation, the better I can design a solution. In version #1, a sit down restaurant will work. In version #4, perhaps a slice of pizza or snickers bar will work best.
2. Job Stories Come From Real People Not Personas
Because they are a mashup of assumptions and attributes, personas can have a destructive effect on product design. They can give a false sense of knowing the customer and thus can really leave gaps in design. For example, you can’t ask a persona about their anxieties, why they chose Product A vs Product B, what else was going on when they chose Product A vs Product B, or that when they first opened your app they didn’t know what to do first….
Job Stories can only come from real customer interviews. Before designing a feature or new product, you must talk to real people and uncover all the anxieties and contexts which were in play when they used your or a competitor’s product.
If you are interested in learning about techniques on how to conduct an interview, listen to the The Mattress Interview with Chris Spiek and Bob Moesta. Chris, Bob and Ervin also have a Udemy course on jobs-to-be-done customer interviews.
Another reason why some favor personas is because they don’t know how else to organize all the information they get about or from their customers. How to organize job stories will be addressed in a future article.
3. Design Modular Job Stories Which Features (Solutions) Can Plug Into
When designing job stories, it’s important to not commingle them with solutions. This is another important distinction from user stories which encourage defining implementation.
When commingling personas ( or situations ) and solutions….
Below is from a source describing how to write effective user stories. The author encourages to also create sub stories which ‘add detail’ to help develop the user story. Here is an example:
As a user, I can backup my entire hard drive.
…and after adding detail….
As a power user, I can specify files or folders to backup based on file size, date created and date modified.
and…..
As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.
Given the examples above, suppose the power users didn’t care much to specify which files or folders to back up bases on file size, date created….. In this case how do you figure out what went wrong. Is your persona wrong? Is the feature wrong? Is it the wrong feature for the persona?
Breaking out situations ( jobs ) and solutions.
The bottom line here is that when jobs are seen as separate from solutions, you notice that they can be explored differently and at different times. Another benefit of modular stories and solutions is how you can begin to see where jobs overlap and several jobs can end up sharing a common solution.
How job stories relate to solutions and other job stories is a topic onto its own. In the mean time, start off with visualizing the relationship between job stories and features like this:
The last image references what I call a Situational Segment. It’s an idea I’ve been thinking about lately and is a topic that needs to be explored on its own.
4. Add Forces To Motivations
Another idea from David Wu is to include forces with motivations. In the job story format of Situation — Motivations — Expected Outcomes, the Motivation stage can be augmented by adding pull and push forces. Adding forces to a motivation is much like adding context to a situation. Let’s consider the mayday feature by amazon, as Ross Belmont put it:
When I’m using my tablet and encounter a problem, I want to get help right away so I can finish what I started.
Let’s stick with the motivational part: I want to get help right away and add some forces:
Situation:
When I’m using my tablet and encounter a problem….
Motivation:
I want to get help right away…
Force: I’m irritated because I was in the middle of something…
Force: I’m nervous I won’t finish what I was just doing…
Force: I get nervous asking for help…
Force: Asking for help might make me look stupid…
Force: I’m shy about showing what I’m working on to someone else…
Expected Outcome:
So I can finish what I started.
When a story adds forces, we can then design solutions which help reduce forces that push customers away from a product or feature and increase the forces that pull them towards a product or feature. In Amazon’s case, they could:
- Reassure that customers don’t have to wait long to get help. ( I’m nervous I won’t finish what I was just doing )
- Ensure that customers can choose how much access the customer support rep has to your tablet. ( I’m shy about showing what I’m working on to someone else )
- Remind customers how common it is to ask for help. (Asking for help might make me look stupid)
5. Job Stories Don’t Have To Be From A Single Point Of View
Lately, I’ve been experimenting with the idea of not restricting stories to the point of view of just one person. Instead, I’ve been writing stories from a third person point of view.
When:
When someone approaches a bank for a home mortgage and fills out an application…
Motivation:
The applicant wants to know if the application is accepted or not…
The banker wants to make sure that the application is filled out correctly…
The bank wants to check if the applicant has acceptable credit history…
Expected Outcome:
So that a home mortgage is quickly given to a low risk person, which the bank feels confident it will profit from.
Again, I’m experimenting with these so I’d love feedback on what people think about this. So far, 3rd person stories do well when a product deals with multiple parties, such as a real time bidding site like eBay.
Learn more
I’m still working with job stories in my product design and I’m sure the more the concept is put into practice, adjustments will be made and it will continue to be built upon. As these come up, I’ll continue to comment about it.