Writing Technical Specifications from Customer Goals
The Jobs-to-be-Done lens asks what job a person hired the product to do, and in AI deployments the answer is usually an outcome in the customer's work rather than the use of AI itself.
A Support Team That Had A Good Model
Imagine a team that has built an accurate system for sorting incoming support tickets by topic. The system performs well in testing, and its builders are proud of the classification accuracy. Support managers, however, report that tickets still take about two days to get resolved. The model works, yet the outcome the managers care about has not changed.
This article follows one idea through that gap. A project can be technically successful and still fail the customer, and the Jobs-to-be-Done lens exists to catch that failure before any system is built. We will trace how a team's thinking moves from a model to a specification, and see where the path can break.
Where Many AI Projects Start
Many AI projects begin with a sentence like this: we have a capable model, so let us find a place to use it. The team then looks for a feature to attach the technology to, and the project is judged by how well the technology performs. This starting point feels productive because it begins with something concrete, but it quietly assumes that the product's purpose is to run the AI.
Replacing What Should Our AI Do
The Jobs-to-be-Done lens replaces the question what should our AI do? with a different question: what job did this person hire your product to do? The word hire is deliberate. It treats the customer as someone who has a task in their life or work and who brings in a product to get that task done. The product is judged by whether it did the job, not by whether it contains impressive technology.
Applied to AI deployments, the answer to the job question is rarely use the AI. The source gives examples of jobs that are closer to what a customer actually wants. None of them mentions a model, a classifier, or a prediction. Each describes a change in the customer's life or work. That is why the lens is useful: it moves the conversation from the mechanism to the outcome.
A feature describes what the product contains. A job describes what the customer is trying to accomplish. The distinction matters because a team can list every feature correctly and still have no idea whether the customer's task got done. The source notes that two properties follow from this distinction, and both are worth checking whenever a team claims to understand its customer.
Expressing the Job in Customer Terms
A job is expressed in the customer's language and measured in the customer's metrics. This keeps the team focused on the customer's world rather than on the system's internals. Language and measurement are two halves of the same discipline: the first says how the job is described, the second says how success is judged.
The Translation Step
Stating the job is not yet enough to build anything. The source identifies a distinct step between the customer's job and the technical specification, and it describes this translation as the central work of the deployment. The person doing the translation takes a statement in the customer's language and turns it into a description of what the system must do, what inputs it receives, and how its behavior will be checked against the customer's measure.
The diagram below shows the chain. The important point is the link in the middle. The translation step is where the job becomes buildable.
What Happens When Translation Is Skipped
If the translation step is skipped, the specification is written from whatever the team already knows how to build. The system's behavior then drifts away from the job the customer hired it to do. The source warns that skipping the translation can produce systems that do the technically interesting thing without doing the job.
Tracing the support ticket project
A team has an accurate ticket classifier, but managers report that tickets still take about two days to resolve. Trace how the project went wrong and what the translation step would have asked.
- 1Name the job
The job is the support work the managers hired the product to do: getting tickets resolved. Sorting tickets by topic is a feature, not the job.
- 2Identify the customer's metric
The managers measure success by how long tickets take to get resolved. Classification accuracy is the builders' measure.
- 3Check the chain
The team started from a model, built a classifier, and judged it by accuracy. The chain never reached the managers' measure, so accuracy could rise while resolution time stayed about two days.
- 4Ask what the translation would require
A translated specification would state what the system must do, what inputs it receives, and how its behavior is checked against resolution time. Those questions expose whether the classifier can move the managers' measure at all.
The classifier does something technically real, but the specification never connected it to the job. The outcome the managers care about is outside the spec, so the project cannot be judged a success by the customer's standard.
Mistakes Teams Make With the Job
Common mistake Treating the AI feature as the job
What it looks likeStating the job as we need a ticket classifier.
Why it failsA feature describes what the product contains. A job describes what the customer is trying to accomplish.
Do this insteadState the change in the customer's work, such as tickets getting resolved sooner.
Common mistake Measuring success with the builders' metric
What it looks likeJudging the ticket system by classification accuracy alone.
Why it failsThe job is measured in the customer's metrics. Accuracy can improve while the customer's measure stays flat.
Do this insteadAdd the customer's measure, such as time to resolution, as the test of whether the job was done.
Common mistake Skipping the translation and writing the spec directly from the model
What it looks likeWriting the specification from what the team already knows how to build.
Why it failsThe system then does the technically interesting thing without doing the job.
Do this insteadInsert the translation step so the spec states what the system must do, its inputs, and how it is checked against the customer's measure.
Common mistake Writing the job in product or model terms rather than the customer's words
Practicing the Translation
A team proposes an AI tool that drafts replies to customer emails. Before writing any specification, state the job in the customer's language, name the customer's metric, and list the questions the translation step must answer.
Hints
- Describe a change in the customer's work, not the drafting model.
- Ask how the customer would tell whether the job went well.
- A specification should say what the system must do, what inputs it receives, and how its behavior is checked against the customer's measure.
Key Takeaways
- The Jobs-to-be-Done lens asks what job the customer hired the product to do, and in AI deployments that answer is usually an outcome in the customer's work rather than the use of AI itself.
- A job is expressed in the customer's language and measured in the customer's metrics, which keeps the team focused on the customer's world rather than the system's internals.
- The translation step turns the customer's job into a technical specification that states what the system must do, what inputs it receives, and how its behavior is checked against the customer's measure.
- Skipping the translation lets the team build from what it already knows how to build, so the system can do the technically interesting thing without doing the job.