Конспект Intercom on Jobs-to-be-Done

When you’re solving needs that already exist, you don’t need to convince people they need your product. It’s easier to make things people want than it is to make people want things.

Chapter 1: Focus on the job

Personas will always have their place. But if you want to build a great software product, making crucial decisions based around a series of personality traits won’t get you there. That’s because products don’t match people; they match problems.

If there are no key differentiators between all your users, you’ll end up with useless, vague personas.

Some products are better defined by the job they do than the customers they serve. For some products, customers come in all shapes and sizes, from all countries, all backgrounds, all salaries, and all levels of computer skills. The only thing in common is the job they need to get done. In these cases, it’s best to get an intimate understanding of the job itself, what creates demand for it, and what you’d hire to do the job.

Chapter 2: Understanding your real competitors

So when you’re thinking about competitors, it’s best to ignore product categories and instead ask yourself who else is fighting for that same job.

In indirect competition, there are two different jobs a customer wants to do, but the jobs themselves are competing with each other.

Your marketing should work to make the alternative outcome less attractive, or reposition your product so the outcome is no longer in conflict.

The point is, customers don’t experience your product in a vacuum. They experience it alongside every other product, service, and idea fighting for their attention. Some of these will compete with your brand and some will contradict it. Understanding all these forces helps you counter them with your marketing efforts.

Chapter 3: More than mattresses: using Jobs-to-be-Done research for software

Take enterprise software. From a lack of budget, to a change in management, to multiple tools being used for one job, many things factor into why a company might switch to a new product. These factors can be used in your interviews. Involve functional aspects from within a company, 15 along with emotional triggers from that time.

· What tool were you using before you bought <software>? Were you also involved in buying that?

· What was is it like working in <department> for <company> back then?

· Can you remember if anyone else was involved in the decision? What was their role in the company at that time?

· Tell me about the <old solution>. Can you remember how well that was working? Was it just your department using it?

The ReWired Group have identified four forces pushing and pulling customers away from making a purchase.

Our reasons for buying software can lean more toward business goals like increasing engagement or revenue, rather than personal goals like increasing overall happiness (though if software is well-designed, it can do both). You could argue for software, the purchase decision can be influenced by multiple previous purchases rather than just the push factors of the current tool. In a software scenario, the forces are:

· The push of what is happening currently: “We’re not converting users at a rate that we’d like. We can’t afford to keep paying so much per month for this tool.”

· The pull of a new solution: “If we switch to a new tool that has more features around conversion, we can start hitting our targets.”

· The anxiety of what could happen: “What if the new tool doesn’t integrate as well as we’d like? We’ve tried three other tools for this job and none have been good enough.”

· The attachment to what you currently have: “We’ve got workflows and integrations setup and it’d be a pain to get them set up again.”

The consideration set involves the time in which a person (or company) is looking at all the possible solutions for a job they want to fulfill through a product. It’s during this time “active” or “passive” looking takes place. Active looking usually stems from a moment of particular frustration the person has been through with the product. Passive looking can be ongoing for weeks/months while the person is uncertain if the product is doing its job well enough.

For software businesses, asking questions around the consideration set can help you uncover if there were situations where multiple people affected the purchasing decision:

· 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 <tool’s> website?

Creating a timeline of events helps bring the interviewee back through their purchase journey. For software purchases, there are often multiple timelines at work.

This is down to there being numerous people involved in the decision to buy software. You’re really looking for the right people to talk to, the main decision maker. There are so many times you’ll hear: “I wasn’t at when we bought but I’m the main person who uses it!”

Unearth the main decision maker behind buying software by asking questions like:

· What year did <company> move to <product>? Were you there at that point?

· Who decided to make that move? Are they still at the company now? What role are they in? Knowing who the other decision makers are will give you a broader picture of where you need to innovate, and how you can support jobs your product is getting dropped for.

Chapter 4: Getting customers to switch

In short people rarely switch, but when they do, there’s an interesting set of dynamics at play. Whether it’s coffee or software most companies take the myopic route, and simply try to make their product look better than everyone else’s. The appearance of your product is only ever one part of what makes people switch.

Switching is also about removing fear or hesitation associated with trying out your product and making sure you remind them of the problems with their current solution.

The way you motivate somebody to make a switch is the same for a friendship, a relationship, or a software product – identify the struggling moments your customers are experiencing and build around that. Emphasize why the existing way does not make sense, why it’s safe to switch to your product, and why they don’t need to worry about leaving the existing way behind. If you can solve all those things, you’ll get customers to switch.

To create an anxiety relievable only by a purchase…that is the job of advertising. Marketing increases familiarity, reminds consumers your product exists, and spreads product news. But marketing also does another job: it defeats inertia.

Advertising lets you manipulate these four forces. Specifically you can:

1. Increase the push away: Show how bad their existing product really is.

2. Increase your product magnetism: Promote how well your product solves their problems.

3. Decrease the fear and uncertainty of change: Assure consumers switching is quick and easy.

4. Decrease their attachment to the status quo: Remove consumers’ irrational attachment to their current situation.

Consumers overvalue what they already have by a factor of three, while companies overvalue their innovations, also by a factor of three. Here’s what it looks like:

When marketing your product, consider all four forces to win customers over. Often your product is more than good enough, but there’s another force blocking you. Advertise against that and you’ll see more movement.

Understand that consumers overestimate their current solution just as much as you overestimate the quality of your product. This means products with only marginal improvements don’t break through. The lead will only change hands when a 10X product arrives.

Chapter 5: Where one job stops and another starts

The most important thing a product manager does is decide where their product stops and someone else’s product takes over.

If your product does too little then it isn’t worth the cost of installation, let alone the actual purchase price. Similarly if a product does too much, it will clash with some other pre-existing software or workflow users are already happy with.

Start your product at the first step where you can add value.

Your budget, whether time or money, should restrict but never define your scope. A large budget should define how well a problem is solved, never how many problems are tackled. Attempting to tackle an entire workflow from start to finish for all types of users is near impossible.

Your product should stop when the next step:

· has well defined market leaders looking after it (e.g. Apple, Netflix, Expedia), and you don’t intend to compete.

· is done in lots of different ways by lots of different types of users (e.g. trying to process salaries in a time-tracking app would be difficult).

· involves different end-users than the previous steps (e.g. managers, accountants, etc).

· is an area you can’t deliver any value.

Any time your user is clicking through a defined series of steps, adding no insight and making no decisions along the way, it’s a sign there are steps to be killed.

Always fill in the gaps before expanding the product. Expanding your product to solve a larger problem can work wonders, but can only be done on a solid foundation. If your fundamental product isn’t holistic, then adding more features only makes things worse.

There is a fundamental difference between making a product simple and making a simple product.

Making a product simple emphasizes removing all unnecessary complexity so every user can solve their problems as efficiently as possible. Making a simple product, however, is about scoping down and choosing the smallest subset of the workflow where your product delivers value.

This minimum viable product approach runs the risk of being labelled a point solution, or worse, “a feature but not a product”. When shooting for a “simple product”, be careful where you draw the line.

Chapter 6: A worse product can do a better job

Most products are obsessed with the intricacies of their own categories. But customers will always surprise you with the creative ways they use your product. They don’t do it deliberately – they’re just adapting your product to their needs.

When you focus purely on how a feature is used, ignoring the product category it’s in, or the type of feature it is, you quickly learn how to improve it. Rather than trying to address a hypothetical markets of would-be consumers, you can make improvements that resonate immediately.

Chapter 7: Abandoning personas: the story behind Job Stories

While best-in-class personas focus on goals (what drive people’s behavior) as well as attributes, the reality is that most personas focus on attributes alone, even when goal driven. So, it's almost useless.

The goals and attributes may look totally different, but their motivations are the same. Personas would never lead to the same product being designed and built for all audiences.

Personas artificially break apart audiences. And critically, they artificially limit your product’s audience by focusing on attributes rather than motivations and outcomes.

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.

While searching for people's motivation there are 2 challenges:

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 questions 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.

User stories 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.

Job Stories work better and focus on situations, motivations and outcomes:

“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 35 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.

Chapter 8: Designing features using Job Stories

Here’s one approach on how a team implements Job Stories into their workflow:

1. Start with the high level job.

2. Identify smaller jobs that help resolve the high level job.

3. Observe how people solve the problem now (the job they currently use).

4. Come up with a Job Story to investigate the causality, anxieties and motivations of what they do now.

5. Create a solution which resolves that Job Story.

Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in, and then understanding causality, anxieties and motivations.

Abstracted attributes and coupling implementation with motivations and outcomes are distractions for a team. If the team digs deep and learns about a customer’s Job-to-be-Done, they craft solutions more effectively. And using Job Stories to design products is one of the best ways to do it.

Chapter 9: Asking why the right way

When it comes to product design, there’s such a thing as getting down to the root problem too quickly. The value in figuring out the “Why?” behind things isn’t so much about the destination; it’s about the journey.

This is especially true for customer interviews. Slowing down, taking your time with each layer of the “Why?”, exploring lots of different ideas together; it all makes your time together much more productive. And it yields far more interesting and usable insights.

Here are the layers I’ve found the most valuable to fully explore:

1. The immediate layer relates to usefulness. What do you actually do with the thing? I use the drill to make holes.

2. The secondary layer relates to usability. What result comes from using it? I’ve made holes to hang photos.

3. The tertiary layer relates to desirability. What’s different now that I’ve accomplished my goal? I’ve hung photos and now have a more personal home.

When talking about the jobs a particular tool can do for a person, try not to rush to the ultimate, deepest answer. That isn’t always where the gold lies. Often, there isn’t just one root answer. Even if there is, it may not be all valuable on its own. Explore each layer thoroughly for the unique value it can provide.