AI Is Not a Product

One of the first things you learn in product management is that people don't want a quarter-inch drill. They want a quarter-inch hole. This is Jobs to Be Done in one sentence: people pay for outcomes, not for tools.

AI is the drill.

And selling it as the hole is one of the more expensive mistakes the industry is making right now.

We Have Been Here Before

Every major technology wave produces the same brief confusion. The capability arrives, it is genuinely impressive, and for a period of time the capability itself becomes the product conversation.

SQL arrived and organizations hired SQL experts. Not because SQL was the outcome, but because SQL was new, powerful, and nobody quite understood where it fit yet. Then the abstraction layer arrived, the database became infrastructure, and what mattered was the report, the query result, the business decision it enabled. Nobody selling enterprise software today leads with "powered by SQL."

Java arrived and for a few years "Java developer" was the most recruited title in technology. Then Java became one of several languages the system happened to be written in, invisible to the buyer, irrelevant to the outcome. C# arrived and did the same thing. Mobile arrived and "mobile-first" was briefly a product strategy before it became a design principle before it became assumed. Cloud arrived and "cloud-powered" was a differentiator for about eighteen months before every vendor put it on their website and it stopped meaning anything.

AI is doing the same thing, at greater speed and with more cultural noise than any of the prior waves.

The pattern is consistent. A new capability arrives. The capability is confused with the product. The confusion is expensive and lasts until enough buyers have been burned that the market recalibrates. Then the capability sinks into the stack. The product rises above it.

We are in the expensive middle of that arc right now.

What a Product Actually Is

A product is a hire. The customer has a job to be done. They hire your product to do it. The job is the thing that matters: the outcome, the transformation, the problem solved. The technology is how the product does its job. It is not the job.

When a logistics company buys route optimization software, the job is freight delivered on time at acceptable cost. When a finance team buys forecasting software, the job is a reliable picture of where the numbers are going. When a marketing team buys content tools, the job is campaigns that run faster and perform better. In none of these cases is the job "use AI." AI is how the product does the job. It is the engine, not the destination.

TurboTax is the clearest illustration of this. The job is: file my taxes and keep as much of my money as legally possible. TurboTax lets you hire software to do that job. For a higher price, it lets you add a human accountant to the same workflow. The job does not change. The module executing it does. Nobody hired TurboTax for the experience of using tax software. They hired it to not overpay the IRS. Whether the recommendation came from an algorithm or a CPA is irrelevant to the outcome they were paying for.

The confusion matters because it produces the wrong product decisions. A team building an "AI product" asks: how do we make the AI better, faster, more capable? A team building a product that uses AI asks: what is the job, who has it, what does success look like for the person who hired us to do it, and is AI the right tool for this specific part of the problem? These are different questions and they produce different products. The second set almost always produces better ones.

What This Means If You Are Building

Start from the job. Not from the model, not from the capability, not from what the technology can do in a demo. Start from the specific outcome a specific person needs, in a specific context, with specific constraints. Then ask whether AI is the right tool for any part of that.

Sometimes the answer is yes. Often it is yes for some parts and something else for others. Occasionally AI adds noise rather than signal, and a simpler approach works better. These are not failures of ambition. They are signs of a team asking the right questions.

The products that will create durable value are the ones where users barely notice the AI. They notice the hole. The report that used to take three days arrives in forty minutes. The anomaly that would have appeared in next quarter's audit is flagged this morning. The AI is somewhere in the stack, invisible, doing its work.

What This Means If You Are Buying

If you are procuring AI, you are not buying a technology. You are hiring something to do a job, and the questions that matter are the hiring questions.

What outcome does it produce? How is that outcome measured? What does success look like in six months, not in the demo? Who is accountable when the job is not done? What does the vendor guarantee, and what are they declining to guarantee?

Any vendor who cannot answer these questions clearly is selling you the drill. They may be selling you a very impressive drill. But if you cannot articulate the hole you are trying to make, you are not buying a product. You are buying a capability in search of a job, and that is an expensive place to be.

The RFPs that ask "do you use AI?" are asking the wrong question. The ones that will produce better outcomes ask: what job will this do for us, how will we know it worked, and what happens when it doesn't?

The Temporary Interface Problem

There is one more manifestation of this confusion that deserves its own examination, and it will be the subject of the next piece.

Prompt engineering is now on the mandatory skills list for product managers, UX designers, and developers. Online courses are selling it as a foundational AI competency. Organizations are adding it to job descriptions.

Prompt engineering is a real skill. It is also a temporary one.

Writing prompts to get useful outputs from a language model is not different in kind from writing punch card programs fifty years ago, or learning to edit a configuration file in Vi twenty years ago, or hand-coding CSS before the frameworks arrived. These were genuine skills for their moment. They were also interface artifacts: the awkward period between when a technology arrived and when the human-technology interface matured enough that the workaround disappeared.

Nobody teaches punch card programming today. Nobody lists Vi proficiency as a core design competency. The interface evolved until the workaround was no longer necessary.

Prompt engineering is already following that arc, faster than most people teaching it have noticed. Research on some of the latest reasoning models shows that elaborate, carefully structured prompts can reduce performance compared to simpler, more direct requests. For at least some of the models that matter most, the craft that was essential in 2023 is already less useful than it was. The interface did not wait for the training industry to catch up.

What will not be abstracted away: knowing what job you are trying to do, knowing what good output looks like, knowing when the result is wrong and why. Those are judgment skills. They do not disappear when the interface improves. They become more valuable.

The Hole Is Still the Point

AI is not a product. It is the most capable drill the industry has ever built, genuinely impressive, and it will be used to make holes that could not have been made before.

But the hole is still the point.

The companies that treat AI as a product will spend the next several years defending a capability that is becoming generic. The companies that treat it as a tool in service of a specific job will spend the next several years making holes nobody else can make, because they understand the job better than anyone else does.

A product built on C# is not a C# product. A product built on AI is not an AI product.

It is a hire. Make sure you know what job it is doing.