The model is rarely the product.

When people talk about AI products, they mostly talk about the model. Which model. Which version. Which benchmarks.

The model is the least interesting part.

I don't mean this as a provocation. I mean it practically: the model is a component. Usually a swappable one. What makes a product useful — or not — is everything built around it.

Start with the problem, not the capability

The most common mistake I see in AI product development is starting with the capability.

"We have access to GPT-4. What can we build?"

This produces demos. It rarely produces products.

A product starts with a problem. A specific, real problem that specific, real people have — and that they currently solve in a way that is painful, slow, expensive or unreliable.

The question is never "what can this model do?" The question is "what are users actually trying to accomplish, and where does the current approach fail them?"

The answer to that question defines what the product needs to do. The model is just one of the tools you might use to do it.

What information does the model actually need?

Language models are not magic. They produce outputs based on inputs. If the inputs are incomplete, ambiguous or wrong, the outputs will be too.

This sounds obvious. In practice, it requires careful work.

What context does the model need to produce a useful response? Where does that context come from — user input, system data, retrieved documents? How do you handle the cases where context is missing or contradictory?

Most AI product failures I've encountered are not model failures. They're context failures. The model was given the wrong information and did exactly what it was supposed to do with it.

Where does the human stay in the loop?

Automation is a spectrum, not a binary.

At one end: the model makes a decision and it's immediately acted on. At the other end: the model surfaces options and a human decides.

Most AI products should sit somewhere in the middle — with the position on that spectrum determined by the stakes and reversibility of each specific decision.

High stakes, hard to reverse: keep a human in the loop. Low stakes, easy to undo: automate more aggressively.

The mistake is treating automation as a goal rather than a tool. "How automated can we make this?" is the wrong question. "Where does human judgment add the most value, and where does it just add friction?" is better.

What happens when the model is uncertain?

This question is almost never asked during the demo phase.

In production, uncertainty is constant. Queries that are outside the system's reliable scope. Inputs that are ambiguous. Cases where multiple answers could be defensible.

A well-designed AI product handles uncertainty explicitly. It surfaces confidence signals. It knows when to escalate to a human. It knows how to say "I'm not sure about this" in a way that's useful rather than alarming.

Building this requires deciding, in advance, what the system's limits are — and designing the experience around those limits rather than pretending they don't exist.

Feedback loops and learning

A product that doesn't improve from usage is just a feature.

How does your AI product get better over time? Where does feedback enter the system? Who reviews it? What changes as a result?

This is not automatic. Models don't learn from production usage by default. Improvement requires deliberate processes: collecting feedback, evaluating it, deciding what it means, changing prompts, fine-tuning, adjusting retrieval, updating content.

The teams that build AI products that improve over time are the ones who treat feedback collection as a product requirement from day one — not an afterthought.

Adoption is harder than the technology

I've shipped enough products to know that the technical problem is rarely the hardest part.

The hardest part is getting people to change how they work.

An AI tool that requires users to significantly change their existing workflow will be ignored, even if it's objectively better. People have developed their current approach over years. It works well enough. The learning curve of something new is not worth it unless the benefit is immediate and obvious.

Designing for adoption means meeting people where they are. Integrating into existing tools and workflows where possible. Showing value in the first session. Making it easy to recover from mistakes.

The model doesn't matter if nobody uses the product.

The most interesting AI product questions aren't about models.

They're about workflows, judgment, trust, feedback and change. They're about what happens when something goes wrong, and who's responsible, and how the system earns the right to be trusted with more over time.

The model is a starting point. The product is everything else.