Step 1 of 5 · Customer needs

Discover customer needs worth building around

An internal idea, a technology and a customer request can all be useful starting points. None proves which customer problem deserves investment.

Start with the progress a real person is trying to make in a real situation. Then identify the measurable results they are trying to improve and where the available alternatives leave those results poorly served.

EVIDENCE BEFORE ASSUMPTION

Customer needs work starts from real conversations, not from the idea already on the whiteboard.

Before you begin: keep the growth challenge in its place

The growth ambition, current trajectory and commercial constraints still matter. They set the boundary for the work. They do not define the customer need.

Use the Growth Check to make the growth gap and the fixed constraints visible. Then begin Step 1 with the job, the situation and the outcome that a customer is trying to improve.

A customer need is not a requested feature

Teams often start with a feature request: “Could you provide predictive maintenance?” Or with an internal answer: “We should use the data we already have.” These can be sensible hypotheses. They are not yet the need.

In Jobs to Be Done terms, a need begins with the job executor and the progress they are trying to make. In outcome-led work, it becomes a set of measurable, solution-independent desired outcomes: the criteria by which the person judges whether the job is getting easier, safer, faster, more reliable or less costly.

A desired outcome is a customer need. A requested feature, specification or product idea is one possible solution.

Map the job before you design the answer

1. Name the job executor. Who is actively trying to get the job done? The user, buyer and economic beneficiary may be different people.
2. Describe the core job and situation. What are they trying to accomplish, when does it become urgent and what makes the situation difficult?
3. Map the job steps. What happens before, during and after the work? Where are people forced to wait, search, coordinate, calculate, check or recover?
4. Write outcome statements. Describe how the executor judges success without naming a product, feature or technology.
5. Measure importance and current satisfaction. Find which outcomes matter most and are served least well by the alternatives available today.
6. Identify the underserved-need segment. Look for a repeatable pattern of people and situations where the same outcomes are important and poorly satisfied.

This is not a workshop exercise performed in isolation. The map is a compact model of what must be investigated with interviews, observed work, service data, transactions, support cases and relevant market evidence.

What a usable outcome looks like

The revised statements can be evaluated against different concepts. A data product, an expert service, an embedded capability or a change in the service process may all compete to improve the same outcome.

Example: from predictive maintenance to the actual job

A machine manufacturer begins with a predictive-maintenance service idea. The team expects customers to value alerts based on machine data.

Customer work changes the frame. Maintenance managers and technicians are not simply trying to receive more alerts. In high-pressure situations, they need to prioritise which issue needs attention, narrow the most likely fault cause and avoid unnecessary site visits without increasing production risk.

Predictive maintenance remains an option. It no longer defines the problem before the customer evidence does.

The decision gate

Proceed to Step 2 when you can state all of the following clearly:

• the job executor, the core job and the situation
• the target customer boundary and the evidence source behind it
• the relevant desired outcomes, expressed independently of a proposed solution
• the outcomes that are important and currently underserved
• the segment or situation in which the pattern is strongest
• the buyer, beneficiary and adoption constraints that must later be addressed

If these are still assumptions, do not force a solution comparison. Collect the missing customer evidence first.