A Jobs to Be Done statement for an AI feature describes the progress a person is trying to make in a particular situation. It does not begin with a model, chatbot or automation. The useful question is not what AI can generate. It is what the user needs to finish, why the current route fails and what evidence would make the result acceptable.
Treat this framing as an internal discovery method, not an external AI standard. A convincing interview quote can identify a hypothesis. Only observed behavior and product evidence can show whether the job is frequent, important and served by the proposed feature.
Write the job around progress
Start with a recent situation. Identify the trigger, the desired change, the constraints and the person who accepts the outcome. A vague request to summarise documents becomes more useful when the team knows who is under time pressure, which decision follows, what must not be omitted and where the approved result goes.
Separate the job from the mechanism. If the statement stops making sense when the words AI or assistant are removed, it probably describes a preferred feature rather than a user need. The discipline behind a precision-focused product release is relevant here: narrow the expected behavior before expanding capability.
Look for existing effort. People may copy information into a template, ask a specialist, search several systems or postpone the decision. Those workarounds reveal the current cost and the trust conditions. They also show where a deterministic rule, better search or clearer workflow could outperform a generative component.
Turn the job into testable product behavior
Define the minimum input the feature needs and the output a user can inspect. Then list common variation: missing context, conflicting records, ambiguous language, unusual permissions and a request outside the intended purpose. The feature should recognise when it cannot complete the job and offer a safe next step.
Make acceptance observable. A user may need to confirm a source, correct a field, choose between alternatives or hand the result to another role. Completion is not the moment the model responds. It is the moment the intended work reaches a valid state in the surrounding process.
The failure of portals designed around management structure offers a useful contrast. Products become burdensome when their organisation replaces the user’s task. An AI feature can repeat the same mistake by exposing model functions instead of supporting the sequence in which work actually happens.
Instrument the journey from trigger to accepted outcome. Record voluntary use, abandonment, correction, escalation, repeated use and downstream rejection. Do not combine them into a flattering engagement score. Each event answers a different question about fit and reliability.
Choose AI only after the job survives contact with evidence
Run a bounded test using representative inputs and real constraints. Compare the assisted path with the current method. Examine time, completion, correction effort and serious failure modes, but label the result for the observed users and period. A prototype demonstration does not establish demand, safety or durable value.
Set a decision rule before the test. Continue when the job is validated, the output can be checked, the failure path is controlled and the operating owner accepts the burden. Redesign when users need different progress than expected. Stop when the feature merely moves work or risk to another person.
Commercial evidence can also clarify the job. The lesson in an existing-customer conversation that became a sale is not a universal conversion claim. It is that concrete context can expose a specific outcome worth serving and testing.
Frequently Asked Questions
It is a concise description of the progress a user seeks in a specific situation, including the trigger, constraints and acceptable outcome.
Usually not. The job should remain valid if a non-AI mechanism solves it better. AI belongs in the solution choice, not the need.
Observe recent behavior, inspect existing workarounds, test a bounded workflow and record whether users reach an outcome they recognise as useful.
Reject or reshape it when the job is weak, deterministic logic works better, evidence cannot be verified, or failure creates unacceptable consequences.
When the job, evidence and risk boundary are clear, an AI product development assessment can determine whether the right mechanism is a model, a deterministic workflow or a combination.