Personas artificially break apart audiences. And critically, they artificially limit your product’s audience by focusing on attributes rather than motivations and outcomes. Once I made this observation, it blew apart my faith in personas. Designing for motivation is far better than designing for attributes. It’s the key difference between personas and Jobs-to-be-Done. Personas look at roles and attributes. Jobs-to-be-Done looks at situations and motivations. Personas explain who people are and what people do. But they never fully explain why people do something. And why people do things is far more important. So in mid-2013 at Intercom, we found ourselves in search of a tool that would help to uncover why customers do things. We were talking to dozens of customers each week, and our customer support team was 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: 1. People are experts in their problem, not the solution. However, 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 them with ques- tions to really understand their problem. 2. 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 actually trying to solve, and why they needed to solve it. Once we understood the problem, how could we boil these insights down into something action- able for the design team? 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 and co-create personas with us, only to ignore them afterwards because they were too hard to remem- ber and too detailed to parse. Personas are just not concise enough for fast-moving product teams. Aside from personas, another very popular tool is user stories, popularised by the Agile movement in software. We had never used user stories either. For a start they are not empirically research driven, and are engineering driven, rather than customer driven. They are formatted to describe functionality to be built, rather than motivations people have. 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 work- ing well for us. We first surfaced it in a blog post lamenting the “Dribbblisation” of design. We had been thinking long and hard about Jobs-to-be-Done, and ended up creating our own process 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 34