A tangible introduction to jobs-to-be-done

Before diving into what user needs are, let’s talk about this clever illusion. Some might see a duck and others might see a rabbit. It has to be brought to our attention that a different interpretation of this image exists. This illustrates the differences in our perception of what we see, hear or sense in any other way.

Now think about the last time your team and you were well on the way of defining a new product or service. When trying to capture what user needs could be addressed, chances are that your team encountered a problem similar to this rabbit-duck illusion.

For example, a team that is tasked with a spatial design might discuss whether the user need is to make a street car free or child friendly. Although they seem similar, they could lead to a vastly different design. But are these interpretations really describing a need? To make matters worse, we also tend to use different languages to describe problems we encounter. Most of the times, there is no real consensus of what a user need is and how to structure or formulate it effectively. This confusion produces a lot of fuzzy buzzwords: delights, fears, pains, gains, desires, motivations, value propositions, benefits, expectations, requirements,...

But let’s step back. What is this team actually trying to accomplish by stating “car free” or “child friendly”? Drilling deeper might reveal that the actual goal is avoiding risk by reducing the probability of an accident between a human being and a vehicle. Or improving health by reducing the amount of exposure to harmful exhaust gases. These statements should feel more precise because they express an overarching value (e.g. improved health) that could be met with a change to the current state (“reduce fine dust”). This way of stating challenges is what we call “jobs to be done”.

When was the last time you used Waze? Why did you use it? Often, users aren’t using it just to receive directions. Instead, the idea they are sold on is that by using Waze, you’ll always arrive on time. Or stating it differently: we temporarily use it (“hire”) to fulfil a job of helping us get to appointments on time.

If you analysed the features Waze is offering, you would quickly notice that most of its features are fully tailored to fulfilling that goal. Connecting to your agenda to reduce the chance of leaving your location too late. Suggesting new routes to reduce the loss of time on congested roads. Or reducing the risk of picking departure times that are often associated with increased travel time.

Now imagine that you’re on a holiday in the Alps.

It is nice weather and you want to explore the unknown landscape either in your car, your motorcycle, your bike. Would you still “hire” Waze to help you accomplish that? Chances are that you’re not planning to be on time somewhere. You’re probably looking for something that “helps you experience the unique environment”. A product could increase your exposure to a maximal amount of different flora, fauna and landscape elements to do that (e.g. Geocache). Or it could help you do that by increasing the amount of exposure to road dynamics such as height changes, sharp turns (e.g. motorcycle).

This exercise demonstrates that by making that “job” the unit of analysis, we can drastically improve our problem identification and problem solving skills. It is a language teams could use to lift the veil of ambiguity surrounding user needs. The detailed descriptions of the kind of value a user is looking for and how performance could be measured, enable team to work on innovation challenges more effectively.