Intro

Intercom's application of the Jobs to Be Done framework shifts the focus to the motivations and outcomes that drive user behavior. Unlike traditional user stories, which often ignore context and concerns, JTBD uncovers deeper insights by asking the right questions.

The book shares how the company uses this method and how it can lead a product team to exceptional results

Criticism of the Persons method

We never use personas in Intercom. They artificially segment audiences and focus on audience attributes rather than on their motivations and the results they want to achieve. In other words, personas talk about who does what, but they don’t talk about why someone does something. And that’s much more important.

Personas work well if the product's user base can be broken down into specific segments. In this case, personas need to be carefully crafted. Each line in the description should serve a purpose, and the entire team, including stakeholders, should be involved in their development.

For the same reason, the persona method can be good for advertising. However, in product development, personas work poorly because products do not match people; they match problems.

User stories have three big problems: 1. They use personas. 2. They couple implementation with motivations and outcomes. 3. They ignore context, situations and anxieties.

Job Stories and Team around JTBD

That's why we invented Job Stories: [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.

Before each project starts, we create a one-page project brief that explains what we are doing from the user's perspective and focuses the team.

Here's a step-by-step plan for how to implement this approach:

1. Start with the high-level job;
2. Identify smaller jobs that help resolve the high-level jobs;
3. Observe how people solve the problem (the job they are currently using);
4. Come up with a Job Story to investigate the causality, anxieties, and motivations of what they do now;
5. Create a solution that resolves that Job Story.

About JTBD research

Everyone on the team should talk to customers. Designing successful products involves researching how people solve problems now, in what context, and understanding causality, anxiety, and motivation.

It’s helpful to find out what tools a person uses, what their experience is like, and how the process works. Asking your customers “Why?” is the best way to learn their deepest needs. With each new question, you may discover new insights.

One of the important parts of JTBD research is identifying the first thought that started the search for a solution or the recognition of an existing problem. This is easy to track in the example of physical products, but with software, it is not so simple, because there can be many different factors that influence the buyer. JTBD research helps you to uncover something deep — motivation, and real problems of people. This is something more than simple user research.

It is important to look for the person who is directly affected by the problem and decides to fix it. Talking to users of the product is useful, but only by talking to the decision maker can you understand the motivation and true reasons.

You’re really looking for the right people to talk to, the main decision maker

Typically, when researching the value of a product, the first three layers are important: Usefulness (why do you need a drill?), Usability (why do you need holes in the wall?), Desirability (what does it give you?).

Focusing on how people use a feature or product, without regard to categories, can quickly reveal how to improve the product or feature. JTBD also helps you better understand the competitive landscape. Ask yourself, “Who else is trying to solve the same job my product is trying to solve?”

The book also provides sample questions that can be used to conduct a JTBD study. For example, “Once you figured out you wanted to buy a new solution, did you do much research to figure out which tool was right for your company?”, “Were you the only one who was looking for something else at that time?” , “Where did you first hear about the tool you picked?”, “Can you recall how you came to purchase the specific tool you did?”, “When you were looking around, did you (or anyone else) try out any other tools?, What were they?”, “How long did you look around before you clicked “buy” on the website?”

About switching to a new product

People don't buy a product. They switch from something old to something new. That's why it's easier to make things people want than it is to make people want things. But to reduce the fear, anxiety, and doubt of switching to a new product, it's worth building an argument around the struggling moments your customers are experiencing.

ReWired Group identified four forces that influence the purchasing decision process: The push of what is happening currently. The pull of a new solution. The anxiety of what could happen. The attachment to what you currently have. Accordingly, product advertising should be built around these forces.

Many purchases are made out of habit without considering alternatives. For example, people buy the same coffee at the same cafe every morning out of habit. People are not against progress, they just prefer inertia.

What should a product be like and how to integrate the product into the user flow

If a product does too little, there is no point in buying it. If a product does too much, it will most likely collide with other products that do some of the work better. Finding the right balance is an important task for the team.

That said, compared to physical products, it's much easier for digital products to go off the rails and quietly turn into a feature-packed monster, but if the product doesn't do its job well at its core, adding new features will only make things worse.

Any new products need to be 10 times better to get mainstream adoption. It’s only at that point switching becomes a no-brainer.

The product should be as simple and effective as possible. However, you should be wary of MVPs with limited functionality, which can be called “a feature, not a product” or a narrowly specialized product.

Products are built into the user's workflow. This means they have a beginning and an end of use. You can only determine these points if you know the entire buyer's workflow.

The product should stop when one of the following is true: the next step overlaps with the work of large, well-known services and you don’t want to compete with them, the next step can be done in many different ways, the next step is done by other users, you can’t bring any value to the next step. It’s worth remembering that if there is no decision-making or insights in a series of steps, these steps may also need to be removed.