Skip to content
Adem Isler
Back to blog
Published7 min read

The Best AI Products Do Less

By Adem Isler

Artificial intelligenceProduct designAI products
Table of Contents

The quickest way to ruin an AI product is to begin a meeting with:

Could it also…?

At first, there is a perfectly useful product. It solves one problem. People understand why it exists. The interface does not contain seventeen tabs quietly threatening the user.

Then someone requests calendar integration. Reporting follows. After that come team management, workflow automation, voice calls, CRM, social publishing, and probably weather forecasts.

Six months later, the product needs three paragraphs and an animated diagram to explain itself on its own homepage.

AI makes this temptation worse because the underlying model genuinely can do many things. It can write, summarize, classify, research, translate, code, and hold a conversation. That breadth creates a seductive but flawed conclusion: if the model is general, the product should be general too.

Putting every model capability into one product is like placing every ingredient in a restaurant kitchen onto one plate. Technically impressive. Possibly illegal in several countries.

A model can be general. A product should not be.

A large field study followed 5,179 customer-support agents using an AI assistant. Access to the tool increased the number of issues resolved per hour by an average of 14 percent, with substantially larger gains among less experienced workers. The useful detail is that employees were not handed an empty chat box and wished good luck. The assistant was embedded inside a specific workflow and informed by examples from that work.

The NBER study is interesting not because it proves that AI is “productive” in some universal sense. It shows that value appeared when a broad model was placed inside a narrow job, with relevant context and a measurable outcome.

A separate experiment involving 758 knowledge workers found a similarly uneven result. AI improved speed and quality across tasks that fell within its capabilities, but reduced correctness on a complex task outside that boundary. The researchers called this uneven edge the jagged technological frontier.

AI does not have one clean border between “can do” and “cannot do.” It has peaks, holes, and the occasional trapdoor. Two tasks that look equally difficult to a person may sit on opposite sides of the model’s actual capability.

That makes “Can AI do this?” a weak product question.

The answer is often yes, at least during a carefully prepared demo.

A better question is:

Under which conditions can it do this reliably, and which user decision is it meant to improve?

“It does everything” is not positioning

An “AI assistant for everything” sounds ambitious. It also sounds like a restaurant serving sushi, pizza, dumplings, and barbecue from the same kitchen. At some point, the size of the menu stops being reassuring.

When a product has no clear job, the user has no clear expectation.

Is the system offering advice?

Is it taking action?

What changes if it is wrong?

Which data can it access?

When does it stop?

When does it admit uncertainty?

As scope expands, those answers become increasingly vague. The user is no longer operating a tool. They are negotiating with a science-fiction character whose personality was still being revised on launch day.

The advantage of narrow scope is not merely a cleaner interface. A narrow product can be evaluated.

You can define success. You can write meaningful tests. You can identify failure boundaries. You can decide when the model should hand control back to a person. You can replace “it seems pretty good” with evidence.

This matters because language models are unusually good at producing output that looks finished. A confident paragraph can disguise a weak chain of assumptions. A polished answer can be wrong in a way that is expensive, embarrassing, or both. The product has to compensate for that. It needs boundaries, validation, and a clear definition of what counts as done.

Complexity should have to earn its salary

Anthropic’s engineering team has reported that its most successful agent implementations tend to use simple, composable patterns rather than elaborate frameworks. Its advice is refreshingly unglamorous: add complexity only when it demonstrably improves outcomes.

This is almost rebellious in an industry that frequently adds complexity first and establishes a task force to understand it later.

A simple prompt-response flow may be enough. If it is not, perhaps a fixed workflow is enough. If that still fails, perhaps the model needs tools. Only after measuring those steps does a more autonomous agent become a sensible option.

The order matters.

Too many teams start with the most theatrical architecture because it looks impressive in a diagram. Multiple agents debate, delegate, evaluate, summarize, and report to a supervisor agent. Eventually twelve models are involved in deciding whether an email should begin with “Hi” or “Hello.”

Sometimes that complexity is justified. Often it is an expensive way to avoid defining the task.

Doing less is not thinking small

A focused product is not necessarily an unambitious product.

Reducing scope is not the same as reducing importance. In many cases, focus is the only way to solve a difficult problem properly.

A medical tool should not have the same tolerance for improvisation as a brainstorming assistant. A system that moves money should not use the same approval rules as one that suggests headlines. A tool that drafts text can recover from a weak answer with an edit. A tool that deletes data has a more interesting afternoon ahead of it.

The NIST AI Risk Management Framework describes trustworthy AI through several qualities, including validity, reliability, safety, security, transparency, explainability, privacy, and fairness. The relative importance of those qualities depends on the system’s context of use.

“Our model is extremely clever” is, sadly, not listed as a complete risk-management strategy.

Narrowing the product clarifies its context. A clearer context makes the risks visible. Visible risks can at least be managed instead of being discovered by a customer at 2:14 a.m.

Product design is often subtraction

Adding a capability is easy. It looks great in a demo. Someone presses a button, the model performs a small miracle, and everybody in the meeting nods.

Saying that the capability does not belong in the product is harder.

A more useful set of design questions is:

  • At what moment will someone open this product?
  • What single problem are they trying to solve?
  • What does a successful result look like?
  • Which information does the system truly need?
  • How costly is a wrong answer?
  • Which decisions must remain with the user?
  • What will the product deliberately refuse to do?

The final question is usually the most revealing.

Products are shaped not only by the features they contain, but by the features they reject. A refusal creates clarity. It tells the user what the product is for, tells the team what to optimize, and tells the model where its authority ends.

Foundation models will continue to expand. They will understand more media, use more tools, and operate for longer periods.

That does not mean every product should become a digital Swiss Army knife. A Swiss Army knife is useful. Nobody sensible uses one to construct an apartment building.

The model may approach generality.

The product still needs to know why it exists.

Sources and further reading

Local-First Is Not a Feature. It Is a Product Decision.