Frame an AI product before choosing a model

Start with a decision, not a technology

A request such as “add AI to support” describes neither a product nor an outcome. Bring it back to an observable decision: classify a request, propose an answer, retrieve a procedure, choose an image edit or trigger a follow-up. Until that decision is explicit, the team is optimizing a demo rather than a use case.

The frame should fit in one sentence: for which user, in which context, which decision should become faster, more reliable or simpler? This forces a choice. It also exposes cases where a deterministic rule, better search or clearer interface is enough.

• A specific user and operating context
• The decision or task being improved
• The current cost in time, error, delay or control
• The exact moment the system hands control back

Map the complete path

The model is only one step. Draw the path from signal to action: input data, rules, model call, checks, possible human decision, action and feedback. A correct output that arrives late, lacks context or cannot be corrected is still a bad product.

This map exposes hidden dependencies. Who owns the data? What happens when it is missing? Is the action reversible? Who sees an exception? Which event helps improve the system later? Those answers shape the architecture more than a small benchmark gap between models.

Write the red lines before the prompt

An AI product must know what it is not allowed to decide. The boundary depends on the field: do not alter a source without approval in an image tool, do not turn a suggestion into a clinical decision, and do not launch outreach when evidence is insufficient.

Give every output three possible states: executable, requires confirmation, or cannot determine. The third state is a product capability, not a failure. It keeps uncertainty visible and gives the operator a clear way to take over.

Test a useful loop, not the complete vision

The first release should close one value loop, even a narrow one: a real input, a useful transformation, validation and an action. Peripheral work can remain manual while the team observes where friction actually sits.

Measure signals tied to the decision: time to a usable first output, correction frequency, rejection reasons, untreated cases and ability to reverse. Generation volume or tokens consumed say nothing about value delivered.