Can you explain the difference between a “Job to be Done” and a “need”?

In Product Management we talk about the importance of focusing on user needs (or problems and desires). But then some people start talking about “jobs”, which is apparently different to a “need”. What is going on?!

I’ve talked before about how valuable the Jobs To Be Done framework is for mapping the problem space. So let’s have a quick look into how a job differs from a need.

What is a “job”

A job is essentially a task that someone is trying to complete. It is totally agnostic to the solution. An example might be

• “Commute to work in the morning”
• “Get dinner for the family”
• “Play a drinking game”

The syntax is usually:

You will almost always have many different ways of completing the job. For example, with the job “commute to work in the morning”, you might do that by walking, biking, getting the bus or driving. The job says nothing about the product or service that the user might use to complete the job.

But isn’t that a need?

Well, not in the Jobs to be Done framework.

A need is a user’s list of “requirements” when completing the job. It is the scorecard they use when deciding which solution to use.

Let’s take the example of “commute to work in the morning”. We might have needs such as

• “Minimise the time it takes to get to work”
• “Maximise the amount of fresh air I get on the way”
• “Minimise the chance of getting wet on the way”
• “Maximise the time that I can read my emails whilst travelling”
• “Minimise the amount of carbon dioxide I create on my journey”

The standard syntax for this is:

Depending on what needs a particular user has, they may choose a different solution. For example:

• If you want to minimise the time it takes, you may want to drive
• If you want to get fresh air, then you should probably walk or cycle
• If you want to read your emails, then you should probably get public transport

Our needs are how we assess whether a certain solution is going to help us complete the job satisfactorily.

It’s also how we assess whether a product/service was good in retrospect. Did the bus ride allow me to read all my emails? Did my driving actually get me to work quicker? We can check whether the solution met our needs, and make decisions about whether to use that product/service again in the future.

In summary, a job is the task the user is trying to complete. A need is how they choose which product/service to use to complete the job, and how they assess whether it was done well.

Why does this matter?

Jobs for setting the boundaries

I find it really valuable to bake a “job” into the mission / purpose of a team. It gives clarity about what the team is trying to help a customer do, without dictating anything about how it is done.

Teams can then set about understanding their customer needs, assessing the competition based on these needs, and then start to discover solutions that will capitalise on these opportunities.

Needs for measuring performance of our products

Jobs help us clarify what we are helping the user do. Needs help us assess how well we are doing just that. There is a metric built into the syntax that we can use to measure performance.

They create a way to measure whether our solution is actually helping the customer complete their task.

It’s easy to measure business success. Of course we should be measuring business success, but we should also be measuring whether we are performing for our customer. If we are no longer performing for our customer, then it is a great indicator that we will soon see a dip in business performance. We need to measure both.

Mapping out the job to be done, and the associated needs, will give us a way to do just that.

For example, if we know that an important need for our users is to “Minimise the amount of carbon dioxide I create on my journey”, then we should be measuring how much CO2 per mile per person our product/service is creating.

Clarifying the competition

Jobs are a great tool for making you think properly about who you are competing against. Say you are a car manufacturer, it is natural to think that you are competing against all the other car manufacturers. But what is the job that the customer is actually trying to complete?

Maybe you are building a car that people will mainly use to “commute to work in the morning”. Well, you are not only competing against all the other cars on the market, but also the other ways that people can commute to work in the morning. You are competing against the bus, the bike and walking.

What are people’s needs in this scenario?

Well, the car is probably good for speed and staying dry. Less so for reading emails and CO2 creation. So if these needs are really important to people, why don’t we create a car that was electric and could read your emails to you as you drove? This will get more people to use your car/product over the real competition.

Spotting opportunities

Jobs to be Done needs are especially useful to confirm whether we have spotted a gap in the market. If we survey people performing a certain job to understand whether certain needs are important and currently being met, then we will discover where the unmet needs are. An unmet need is an opportunity for us to create some value.

For example, let’s say we surveyed people commuting to work about what was important to them. We might find the following:

As you can see, people really value speed, but they are not satisfied with the options to achieve this at the moment. This demonstrates a clear opportunity to create value (whether that is for a private company or the public sector).

Conclusion

Hopefully you can now see how valuable the “Jobs to be Done framework” can be when mapping out the problem space. We can clarify what we are trying to help customers to do (job), understand where the opportunity is to provide value (research under-served needs) and measure whether our solution is making customers happy (need metrics).

Use the right syntax in the right scenario, and the right answers will pop out.