.png){kind=logo}
Most AI features do not fail in engineering. They fail in scoping. Someone describes a capability that sounds magical, the team agrees it would be great, and six weeks later there is a demo that works on three examples and falls apart on the fourth. The feature never ships because it was never scoped to ship — it was scoped to impress.
Scoping an AI feature is a different skill from scoping a conventional one, because the failure modes are different. Here is how we do it.
Start from the failure case, not the happy path
A conventional feature either works or has a bug. An AI feature is probabilistic — it is right most of the time and wrong some of the time, and the wrong cases are where the product lives or dies. So we scope from the failure case first. Before defining what the feature does when it works, define what happens when it is wrong.
That single discipline kills more bad scope than anything else. If the answer to “what happens when the model is wrong?” is “the user is stuck” or “we silently ship garbage,” the feature is not ready to build. If the answer is “the user gets a graceful fallback and we learn from it,” now you have something shippable.
Find the smallest version that is still useful
The temptation with AI is to scope the most impressive version. The discipline is to scope the smallest version that delivers real value, because that is the one that ships and starts teaching you things.
We ask three questions of every proposed AI feature:
- What is the one job this does that a user genuinely cannot do well today?
- What is the narrowest input range where the model is reliably good?
- What can we cut and still have something a real user would choose to use?
The most impressive demo and the most shippable feature are almost never the same thing. Scope for the second one. The first one is a trap with a nice screenshot.
A narrow feature that works beats a broad one that mostly works. You can always widen the input range once the core is proven — but you cannot recover the trust lost by shipping something that breaks on contact.
Decide what “good enough” means before you build
Conventional features have a binary done. AI features have a quality bar, and if you do not set it explicitly, you will argue about it forever. So part of scoping is defining the threshold: at what accuracy, on what set of real examples, is this feature good enough to ship?
This is why an evaluation harness is part of scope, not a testing afterthought. You decide the bar, you build the measurement, and then “is it done?” becomes a number instead of an opinion. Without that, the feature drifts — always almost ready, never shipped.
Put a human where the model is weakest
The best-scoped AI features are honest about where the model is strong and where it is not, and they design the human into the loop exactly there. The model does the heavy lifting on the part it is good at; the human handles the exceptions the system routes to them.
This is not a compromise — it is the design. A feature that tries to be fully autonomous before the quality justifies it ships late or ships broken. A feature that lets the model do 80% and routes the hard 20% to a person ships on time and gets better as the data accumulates. The autonomy comes later, earned by evidence.
The scoping checklist
When we lock scope on an AI feature, we have answered all of these:
- What happens when the model is wrong, from the user’s point of view?
- What is the narrowest useful version we can ship?
- What is the explicit quality bar, measured on real examples?
- Where does a human handle the exceptions?
- What are we deliberately not building in version one?
A feature that has clear answers to these ships in weeks. A feature that skips them becomes a demo that haunts the roadmap. The line between the two is drawn in scoping, long before anyone writes a prompt.