# Designing an AI feature: start from the job, not the model

> Start from what the person is trying to get done, define failure up front, and keep a path to a human for when the model falls short.

Published: 2025-02-21 · Source: https://subxcat.com/articles/designing-ai-features · Author: SUBXCAT

Most AI features are born the same way: "we have model access, let's add a button." The demo looks great, and a month later three people use it, two of them on the team. The model isn't the problem. The feature was designed around the technology instead of around a job.

Here's what to think through before the first prompt.

## Start from the job, not the capability

Write down what the person is trying to do and what's getting in their way. Not "generate a product description" but "get forty new products listed by Friday without spending an evening on copy." The difference looks cosmetic, but it changes the design.

The second version makes a few things obvious:

- you need batch processing, not a button on every product;
- review speed matters more than any single polished text;
- a human will read the output anyway, so it has to be presented for easy editing.

If you can't describe the job without the word "AI," there may not be a job.

## Check whether you need a model at all

A fair share of the problems people bring to language models can be solved with a template, a regular expression or plain search, which is cheap and predictable. A model earns its place where the input is varied and the rule is hard to write down: free text, messy documents, questions phrased any which way.

A good test: try writing the correct answer for ten real inputs. If the answers follow from simple logic, write the logic. If each one requires figuring out what the person meant, that's a job for a model.

## Define failure before you start

This is the most underrated step. The model will be wrong sometimes. The question is how, and at what cost. Answer in writing:

- which mistakes are harmless (the copy is a bit dry, a detail is missing);
- which are unpleasant (a wrong number, the wrong tone with a customer);
- which are unacceptable (an invented contract term, someone else's data in the answer, an action taken without confirmation).

Everything else follows from this list. Harmless mistakes can be left for a human to fix. Unpleasant ones need a check or a "verify against the source" prompt in the UI. Unacceptable ones have to be ruled out by construction: the model should be unable to do that thing, not merely unlikely to.

## Decide who presses the last button

There are three modes, and it pays to choose deliberately:

- **suggestion**: the model proposes, the person decides. Right for almost everything at the start;
- **draft**: the model does the work, the person reviews before it goes out;
- **automatic**: the model acts on its own, the person sees the result afterwards.

Automatic only makes sense where mistakes are cheap and reversible. Sorting incoming mail into folders, yes. Replying to a customer on the company's behalf, not until real data has given you confidence. Moving to automatic is a decision made on evidence, not on a feeling.

## A fallback path to a human

Every AI feature needs a way out for when the model doesn't deliver: the provider is down, the answer is empty, the person doesn't like the result. Options:

- a regular form where the same thing can be done by hand;
- a handoff to support with the context already attached;
- an honest "that didn't work, try another way" instead of an endless spinner.

If the product stops working entirely without the model, you don't have a feature. You have a single point of failure.

## Write down how you'll know it works

Before launch, agree on what you'll watch: results accepted without edits, how often people hit "retry," how many come back to the feature a week later. A couple of logged events will do. Watch behavior, not applause at the demo.

## The upshot

A good AI feature is an ordinary product feature with one probabilistic part. The job, the failure criteria, who makes the final call, what happens when it breaks: answer these in writing before the first prompt. The model will change. The answers will hold.

If you want to walk your product's features through this frame, SUBXCAT can help design them and get them to production.