Define your AI product’s first job

An AI product idea often begins with a broad capability: help a team work faster, answer customer questions, or organize company knowledge. Those directions can be useful, but they do not tell a builder what to ship first. A first job needs a person, a moment, an input, and a result that someone can inspect.

The practical output of this exercise is a one-page pilot brief. It should be clear enough that a product builder, a reviewer, and a prospective customer would describe the same initial release after reading it. You can write it before choosing a model or connecting a workplace system. Writing it first can expose disagreements before integration work begins.

Describe the moment, not the whole role

“Help account managers” is a category of work. “After a project review, prepare a draft list of decisions and open questions from the approved meeting notes” is a task. The second description gives you a trigger, a source, and something a reviewer can compare with the original material.

Choose a moment that happens often enough to observe. Ask the person doing the work to show a recent example, with sensitive details removed where necessary. Look at what starts the task, which documents are opened, and what the person produces. A demonstration of the present workflow is usually more concrete than asking someone to imagine an ideal assistant.

Write down the task’s beginning and end. If the first release starts with approved notes, it does not also need to join meetings, record them, or manage invitations. If it ends with a reviewed draft, sending that draft can remain a separate step. These boundaries make the initial promise easier to explain and test.

Name one primary user

The buyer, daily user, and reviewer may be different people. An operations director could approve a pilot that project managers use and account leads review. Put those roles in the brief. A product that saves time for the daily user but creates more review work for someone else may have moved the burden rather than reduced it.

For the first job, choose one primary user whose behavior you can observe. Describe their familiarity with the source material and the decisions they are allowed to make. A new employee needs a different explanation from an experienced specialist. A useful answer for one can be confusing or insufficient for the other.

Also identify who can say that an output is wrong. That person should help write the review criteria. If no one can judge a result without a long debate, the proposed task may be too vague or the source material may need attention before the product can be evaluated.

Specify what the product is allowed to read

List the actual inputs. For a brief assistant, those might be the approved meeting notes and the current project brief. For an internal answer tool, they might be a specific collection of procedures. Avoid phrases such as “all relevant context,” which leave important access and freshness decisions unresolved.

For each input, record its owner, where it lives, how often it changes, and who may use it. A document that is available to an administrator is not automatically appropriate for every employee. Microsoft’s Copilot privacy documentation provides an example of organizational retrieval tied to user permissions. A separate product needs to define and verify its own equivalent boundaries.

Give the product a response for missing inputs. If there are no approved notes, it might ask the user to add them. If the current brief is unavailable, it could prepare a summary without claiming to identify changes from the previous version. The user should be able to see which material informed the result.

Make the output concrete

A sample output is often the most useful part of the brief. Write one by hand. Include the headings, the level of detail, and the references a reviewer would need. Then ask the intended user to use it as if the product had produced it.

For a meeting-to-brief task, a sample could contain four sections: decisions, proposed changes, unresolved questions, and suggested actions. Every action should have a source reference. A missing owner should stay visibly unassigned. A date that was discussed but never agreed should not appear as a commitment.

This exercise can reveal that the desired output is smaller than the original idea. The user might prefer six checked items over a polished page of prose. That is useful product information. The format should serve the next task, rather than demonstrate how much text the system can generate.

Decide where review happens

Human review should be an actual interaction, not a sentence in a product description. Decide what the reviewer sees, what they can edit, and what happens after approval. An assistant that creates drafts needs a clear distinction between saved work and work that has been sent or applied elsewhere.

For the pilot, you could require an account lead to approve a brief before it is saved to the shared project folder. The review view might place the draft beside the relevant notes. If a proposed task would create an external commitment, keep that action behind a separate confirmation until the team has deliberately evaluated a broader release.

Think through rejection as well. Can the reviewer discard the draft and start again with corrected input? Can they mark a line as unsupported? A product learns little from a single “bad answer” button if the team cannot tell whether the problem was missing information, an incorrect inference, or an unsuitable format.

Define success before the demonstration

Choose a few criteria that relate directly to the job. For the brief example, these could be accurate decisions, no invented commitments, visible unresolved questions, and an acceptable amount of review work. The criteria should describe the result a customer needs, not merely the appearance of a fluent response.

Anthropic’s discussion of agent evaluations emphasizes clear tasks and success criteria. The practical lesson for an early product brief is to make the test inspectable. Keep the input and output together, so a reviewer can explain why a case passed or failed.

Avoid choosing a target percentage simply because it sounds impressive. Start by seeing the kinds of errors the task produces. An omitted optional detail and an invented client commitment have different consequences. Your release decision should account for that difference instead of averaging everything into one score.

Put one worked example in the brief

Here is a fictional pilot: a three-person account team wants a draft project update after its weekly client review. The inputs are approved notes and the latest brief. The output separates confirmed decisions from proposals. The account lead reviews the draft and saves it manually. No messages are sent automatically.

The pilot includes several examples: a meeting with clear decisions, one with no decisions, one with a changed deadline, and one where the notes contradict the current brief. Reviewers record missing decisions, unsupported statements, and the time spent correcting the draft. The team reviews the results after a fixed number of meetings.

That example is small enough to build around. It also gives the team a way to say no to extra features during the pilot. Calendar access, automatic task creation, and a client-facing chat interface may become useful later, but each would introduce another job to define and test.

Record the stop conditions

A pilot needs an end date and conditions for pausing early. If the product mixes client information, repeatedly invents commitments, or cannot show the source behind a claim, the team should know who can stop it. A pause is an operating decision, not a personal judgment on the idea.

Specify what happens to the pilot material when the trial ends. The buyer should know how to export useful work, remove connected sources, and revoke access. These details belong in the conversation before the team begins adding real project information.

Your finished brief can fit on a page: primary user, task trigger, approved inputs, sample output, review boundary, success criteria, and pilot end conditions. Read it aloud to the person who will do the review. If they can point to the exact result they will judge, the first job is ready to become a prototype.