The Jobs to Be Done (JTBD) Framework is a powerful tool to understand customer context and innovate for success.
In a marketplace full of distracted, unpredictable humans innovating takes more than knowing your customer demographics, you need to get into their heads and be prepared for the use of your product within the context of your customers’ lives.
Personas have been here for a long time, they’ve been used across disciplines for different purposes but at the core, they are about the people that you’re trying to reach.
There’s no denying, personas are GREAT. They represent the end users for what we’re building and help us think of them as people rather than numbers on analytics reports. They bring everyone on the same page and help build empathy to build team alignment and ensure they know what they’re doing and for whom.
We’ve all been there. We get a brief, immediately hold meetings, talk about our data and build personas by giving names to stock images. These pretty infographics eventually make their way to the project wall and stay there until the blue tack wears off.
Apart from the very beginning of a project and a few appearances in weekly demos, later on, the personas don’t really add much value to shape the course of the product.
The assumptions we’ve made at the beginning about Jane, who is 35 years old and lives in the suburbs with her 2 kids and husband, don’t really get validated until the product is delivered. At that point, there’s very little correlation between Jane’s usage of our product and the fact that she’s a young professional, a mother and a wife. We can’t even tell whether a particular feature we’ve delivered was successful or not just by looking at her profile.
However, it’s not Jane’s demographics that will help us deliver value and measure its success. The attributes of Jane have very little to do with why she needed that feature and how she would use it.
It’s time we accept that the persona + user story combo as we know doesn’t really work anymore and we should instead try capturing context for our customers.
Factors like these are the driver of most of our day-to-day decisions. Whether online or offline, our behaviours are strongly dependent on the context we’re in.
Let’s imagine we own a bakery famously known for making doughnuts in town. We’re in the process of building an app to even out the demand we see at the shop which is very high in the morning but quite low throughout the day. The feature we’re building is to schedule orders so instead of buying doughnuts in the morning, customers can order them to be delivered midday when they’ll be eaten.
There’s one type of customer in our persona list called Jane. Yes, it’s the same Jane I mentioned above. By looking at our data we see that Jane comes to the bakery in the middle of the day every few weeks and buys a box of doughnuts.
So the challenge for us is to understand why our heroine, Jane, bought a box of doughnuts in the middle of the day? How can we, as a bakery serve her better and potentially make her spend more and often with us? The classic persona structure falls short to explain why and how we might do this.
The JTBD, on the other hand, can help us understand Jane’s purchasing behaviour and build the app to serve that particular “job” the box of doughnuts is doing.
By asking questions like: What was Jane after when she walked into the bakery? Where else could she have that done? What need/ job was she trying to get done?
It turns out the campaign Jane was leading hit a major milestone that day and she wanted to celebrate with her team. So the job was to celebrate and do something nice for her team. She was on her way to lunch thinking about it and walked into the bakery to get some treats, it just as well could have been cookies from the coffee shop across the road.
By rephrasing the user story this way, you open up possibilities to the way you can solve the same problem.
Instead of going for the classic, which is full of assumptions and irrelevant facts that get dragged in by the persona,
As a _(user)_ , I want to _(action)_ , so that _(outcome)_ .
Try rephrasing the user story to include context. It becomes something like this
When _(context)_ , I want to _(motivation)_ , so I can _(outcome)_ .
(for more on this check out Alan Klement’s blog post on Replacing the User Story with the Job Story)
You’ll see that understanding the motivation and context gives a fresh perspective as to what products/services you could include, independent of the app, when and to whom to market them and how to talk about it. You might also find that the Jane’s and the John’s who were different personas are actually trying to “do” the same job.
We should start thinking of the context users of our product/service are in when they are using a particular feature. Writing the user story in a way to capture it will help with generating alternatives to how to help them accomplish that job and give ideas on how we can measure the impact that feature is having. From idea development, to measuring success the JBTD framework will be the window to a specific user journey.
How do you write your user stories? Have you used JTBD? Let me know @sinemerdemli on Twitter.