How we accidentally invented Job Stories
The most powerful thing you can understand when building a product is the motivations behind people’s actions.
At Intercom we’re constantly re-evaluating our process for building great product – product that people find valuable and useful, a product that they love.
One thing we place a huge emphasis on is research. We hire people with direct research experience, and everyone on the product team talks directly to customers. We also hired a Director of Research (Sian Townsend who previously led the research teams for Google Maps) much earlier than most other startups.
While it’s obvious you should be talking to customers frequently to try and understand their needs, it’s not obvious what the best tool to do that is. At Intercom we constantly think about things from first principles, and so very early on we applied that lens to how we were talking to customers. We were big fans of the Jobs-to-be-Done (JTBD) framework, but most of what was written on JTBD was applied to milkshakes and chocolate bars. There was little published research on how to apply JTBD to developing software. So we created our own process based on what we knew.
Personas for empathy, not fresh thinking
For most of my career I used personas and scenarios as one tool for understanding customers. Popularised by Alan Cooper in The Inmates are Running the Asylum, they have since become one of the most widely used tools in a research and design team’s toolkit. (Cooper also wrote a fantastic book called About Face, and I recommend it to all designers who join my team, but I tell them to skip the chapters on personas.)
When I worked at Google, I created dozens if not hundreds of personas across many projects. We often followed Cooper’s method carefully, and we often created iterations of our own. Universally, I found their value was limited. They often helped with building empathy amongst employees who were disconnected from their users, but they rarely led to breakthrough ideas or fresh thinking about a problem.
We have never used personas at Intercom.
People’s motivations can be very similar across demographics
The first time I really started to question the value of personas was when I left Google and joined Facebook. One of the striking things about Facebook’s behavioural data on their users was how similar people’s behaviour was. Personas had led me to believe that people are really different, with really different goals, but the similarities were far greater than the differences, and across every demographic you can imagine: race, age, gender and so on e.g. the motivations behind a married mother of three in the USA posting photos of a family BBQ are basically the same as a Korean teenager posting photos of the house party the night before. The goals and attributes look totally different, but their motivations are the same.
Personas would never lead to the same product being designed and built for both these audiences. Whilst best in class personas focus on goals (goals are what drive people’s behaviour) as well as attributes, the reality is that most personas focus on attributes alone, and even goal-driven personas artificially break apart audiences. So critically, personas artificially limit your product’s audience because they focus on attributes rather than motivations and outcomes. This observation blew apart my faith in them as a tool.
Designing for motivations and outcomes is far better than designing for attributes. This is the key difference between Personas and JTBD. Personas look at roles and attributes, JTBD looks at situations and motivations. Personas explain who people are and what people do. But they never fully explain why people do something. Why people do things is far more important.
Moving from what people want to why they want it
So in mid-2013 at Intercom we found ourselves wondering what a better tool than personas might be. We were talking to dozens of customers each week, and our customer support team were talking to many hundreds more, gathering feature requests, and understanding problems and constraints of our product. Having this direct connection to our customers has been invaluable, but there were two challenges we needed to overcome:
- People are experts in their problem, not the solution, but it is more natural to suggest a solution in the form of a feature request. Describing a suggested solution is easier than describing a problem, but you need to go back to those people with questions to really understand their problem.
- When they reply, their initial answer will tell you what they want, in the form of attributes, but not why that matters. So you need to keep digging into their motivations.
So it was critical that we found out what problem our customers were trying to solve, and why they needed to solve it.
And once we understood the problem, how could we boil all this insight down into something that was very actionable for the design team? Long research reports, and presentation decks with research results, are hard to remember and easy to ignore. We needed something concise, that was easy to communicate and remember. I can’t begin to recall the number of times at Google that we had people participate in research, co-create Personas with us, only to ignore them afterwards because they were too hard to remember, too detailed to parse. Referring to Personas is not the default path, in fact it is the path of most resistance. And often because Personas are not concise enough for fast moving product teams.
Aside from Personas, another very popular tool is User Stories, which had been popularised by the Agile software development movement. We had never used User Stories either. For a start they are not driven by empirical research, and the format is engineering-, rather than customer-driven. They are formatted to describe functionality to be built, rather than motivations people have.
Job stories: capturing situations, motivations and outcomes
After thinking about this problem from first principles, we invented Job Stories. It didn’t have that name at the time (Alan Klement later named it for us) but the process was there, and was working well for us. We first surfaced it in a blog post lamenting The Dribbbilisation of Design. We had been thinking long and hard about JTBD, and made up our own thing that focused on situations, motivations and outcomes:
[ When _____ ] [ I want to _____ ] [So I can _____ ]
‘When ____’ focuses on the situation, ‘I want to ____’ focuses on the motivation, and ‘So I can ____’ focuses on the outcome. If we understood the situation in which people encounter a problem to solve, understand the motivation for solving it, and understand what a great outcome looks like, we were confident that we would be building valuable product for our customers.
Job Stories are now a key tool for us. They ensure the team are research driven, that they understand their problem so well that they can capture it in a concise format. And that their summary of the problem is actionable for all the design and engineering team.
Before we start any project at Intercom we create a one page brief for the project. This is very simple, and must be completed in a single printable A4 page (which are then stuck on the walls around the office so different teams have visibility on what work is going on around the company). It has a section on Job Stories. These Job Stories are what ensure that we know the problem or opportunity we’re tackling, and they keep us focused throughout the project.
Download Intermission template in Word or PDF format
Personas have their place. In political environments where people only pay lip service to customers actual needs, I found them useful to get buy-in; they can drive a stronger connection to actual users of a product.
But personas are:
- laborious to create well
- focus too much on the differences between people
- and are hard to remember and reference.
Turns out:
- many people with diverse attributes have very similar motivations
- those motivations are fast to research
- and the focus on what you build can be captured in a series of short, memorable sentences.
If that doesn’t convince you, remember that personas artificially constrain the total market for your product. We’re all in on Job Stories.
