Translating Customer Needs into Technical Specifications

Imagine a team builds an AI system that classifies incoming support messages with high accuracy. Every test looks good. The model sorts messages into the right categories most of the time, and the demonstrations impress the people who watch them. Has the customer's problem been solved?

This article is about the gap between a system that works technically and a system that does the job a customer needs done. That gap is easy to fall into, because AI projects naturally draw attention to the model. The model is where the hard engineering, the surprising results, and the impressive demonstrations live, so a team can end up organizing all of its work around it. The result can be a system that performs well in a technical sense and still fails the customer, because it never did the job the customer needed done.

The belief that causes this failure can be stated plainly: if the AI works, the customer's problem is solved. Under this belief, success is measured by whether the system performs its technical function correctly. Accuracy, latency, and coverage become the goals, and the customer's situation fades into background detail.

The Jobs-to-be-Done lens corrects the technology-first belief by changing the question. Instead of asking what the AI system does, it asks what job this person hired the product to do. The word hired is deliberate. It treats the customer as someone with a task to accomplish, who brings in a product as a means of getting that task done. The product is judged by how well it accomplishes the task, not by how impressive its internals are.

The lens also makes a second point clear. The customer's job is rarely to use the AI. People do not usually want a tool for its own sake. They want an outcome in their working life, and the AI is useful only to the extent that it moves them toward that outcome. The product is a means; the outcome is the point.

The source material gives three examples of jobs as customers would state them. None of them mention AI, a model, or any technical capability. Each one describes a change in the customer's situation. The first is about time returned to a person. The second is about risk attached to a particular kind of work. The third is about the elapsed time from a question to its resolution.

Each of these statements has three parts: a clear subject, a clear change, and a measurable quantity. A team that works from statements like these knows what success looks like in the customer's own terms. Notice that a statement of this kind can be checked against the customer's world without any reference to how the system is built.

A stated job and a technical specification describe the same need from two different positions. The job describes the customer's situation and the measure they use to judge it. The specification describes what the team must build and how it will be tested. The diagram below sets the two side by side.

The translation is where the customer's job turns into technical requirements. The source describes this step as the forward-deployed engineer's work, and it notes that the quality of this step determines whether the eventual system does the job at all. A specification that keeps only the technical quantity, such as accuracy on a test set, has dropped the customer's measure from the statement. A specification that keeps the customer's measure is more likely to be tested against the outcome the customer actually cares about.

It helps to picture the path from a customer's job to a built system as a sequence of layers. Each layer contains a different kind of content, and each one must be derived from the one above it. The job is at the top, stated in the customer's words. Below it, the job becomes measurable outcomes in the customer's metrics. Below that, the outcomes become technical requirements that the team can build and test.

The layers also show why the top matters most. The source is direct that a system can work technically and still fail the customer if it does not do the job. Testing only the bottom layer tells you whether the build matches the requirement. It does not tell you whether the requirement matched the job. For that check, the outcome in the customer's metric must be tested as well.

Finding the job is not a single activity completed at the start of an engagement. The source describes a discipline, which this course calls the continuous discovery cadence, that keeps the team's understanding of the customer current for as long as the work continues. Its core is a regular rhythm of weekly customer interviews. The source recommends ideally three interviews per week and no fewer than two, sustained over the life of the work.

The reason for the rhythm is the texture of the understanding it builds. A team that spends one intense week scoping the problem and then stops listening holds a model that was accurate on the day it was built and then slowly drifts away from the customer's actual work. A forward-deployed engineer who keeps the weekly cadence accumulates a thicker model. That model holds more detail about how the job really happens, where it breaks down, and what the customer cares about this month rather than last month.

The loop explains why the model must be revised rather than written once. Each interview adds detail, the updated model grounds the next decisions, and the next conversation tests whether those decisions still match the customer's reality. Without the loop, the model is only a snapshot.

Every later decision depends on the team's model of the customer. Decisions about what to build, when to push back on a request, and what to deliver early are all grounded in it. The source describes a thin model as one that produces thin decisions, which miss the part of reality that determines whether the system gets used. That is the most common way a technically sound system ends up unused.