What Isn’t Changing About PM-ing with AI?

Every product team I talk to right now is being asked the same question in different words: where’s the AI? It comes up in roadmap reviews, board decks, sales calls and all-hands. Most of what gets written about AI and product management is about what’s changing. This post is about what isn’t.

Where the pressure comes from

It helps to be honest about where the signal to build AI is coming from. Sometimes it’s customers. More often it’s investors asking about the AI story, competitors announcing an assistant, or a general fear of missing the train. If you work in big tech or a mid-sized company, the pressure is real and it comes from above. I get it. Nobody wants to be the company that sat this one out.

There are also two different things hiding under “AI” that get mixed up all the time. One is building with AI: using it to research, prototype, write code and analyse data faster. The other is building AI products: putting a model in front of your customers as part of what they pay for. The first changes how we work. The second changes what we sell. They deserve very different levels of caution.

What we’re being asked to build

In practice, the pressure turns into two habits.

Strap AI on everything. Add a chat box, a “generate” button or a summary panel to whatever already exists, so the release notes can say AI.
Start with the solution. The brief arrives as “we need an AI feature for X” before anyone has said what’s wrong with X today, or for whom.

Neither is new. Product teams have been handed solutions in search of a problem for as long as there have been roadmaps. AI just makes it easier, because the demo is impressive and the cost of a first version looks low.

What’s not changing

The job is still to take a step back before you build. That part of product management hasn’t moved at all.

What’s the problem we’re trying to solve? Who has it, how often, and what does it cost them today?
Will AI solve it? Sometimes a model is the best tool. Sometimes a better default, a clearer form or a rule does the job more cheaply and more reliably.
How will we measure it? Decide what success looks like before launch, the same as for any other feature. “Users clicked the AI button” is usage, not success.

If the answer is yes, great: build it and measure it. If it isn’t, keep figuring it out. Not shipping an AI feature is a perfectly good outcome when the problem is better solved another way. Shipping one that nobody needed is not.

Things to keep in mind

AI costs money every time it runs. Most software has close to zero marginal cost per user. AI features don’t: every request burns tokens, and heavy users cost the most. A feature that customers love can still lose money on each of them. Know the unit economics before you put it on the price page, not after.

AI is probabilistic, and most of your product is deterministic. The same input can give a different answer tomorrow. That’s fine for drafting an email and risky for anything involving money, compliance or data people rely on. Your quality process has to change from “does it pass the test?” to “is it good enough, often enough?” That’s what evals are for, and someone on the product side has to own them.

Building with AI: hell yeah. Use it everywhere you can. Prototypes that took a sprint now take an afternoon, and a rough working version tells you more than a deck. You get to market faster and you fail faster, which is the point. Cheap failure is how you find the thing worth building.

Building AI products: understand the user first. Before you put a model in front of customers, you should be able to explain in one sentence what value it brings them that they don’t get today. If you can’t, the model isn’t the problem. You haven’t found the problem yet.

The same job, with better tools

AI makes building cheaper. That makes the parts it doesn’t touch more important, not less: picking the right problem, deciding with incomplete information and checking whether it worked. When anyone can ship a feature in a week, the advantage goes to the teams that know what to build next. So use the new tools as much as you can. Just don’t let them choose the problem for you.