A PM talks through a feature with an AI voice app. By the time the thought is coherent, one agent has turned it into a decent spec and another is building it. Someone reviews the work, fixes the weird parts, and ships it before lunch.
It doesn’t work perfectly or on every team, but it happens often enough that a lot of old product assumptions no longer hold. Work that used to wait in a backlog for an engineer can become a prototype in an afternoon. Engineers can run several agents while designers test ideas without negotiating for a week of implementation time.
It feels great. I spent enough years in product organizations to remember how much energy went into getting things built at all. The problem is that shipping more was never the business goal. Implementation was a constraint, but because it sat in front of us for so long, we started treating it like the goal.
Now implementation is getting cheaper and the results aren’t automatically following. Revenue can stay flat while deploys go up. Customer satisfaction can move sideways while the product changes every week. A team can ship five reasonable ideas and end the month with a product that feels more confusing than it did before.
The old friction was doing more than slowing us down
For years, engineering capacity explained a lot of product behavior. A designer might wait weeks to put a rough flow in front of customers. PM backlogs filled with ideas that had no plausible path to production. Leaders tried innovation squads, planning rituals, no-meeting days, new ticket formats, and whatever else might squeeze a little more output from the same team.
Some of that was necessary, and some was ceremony built around scarcity. But scarcity also forced choices. When a feature required several engineers and a meaningful chunk of the quarter, someone had to argue that it was worth the cost. The argument might have been slow, political, or wrong, but it existed because a team couldn’t pursue every plausible customer request at once.
AI weakens that filter. If an agent can knock out a respectable version this afternoon, the easiest response is: sure, let’s try it. The first PR may be cheap; the product decision isn’t.
Once a feature ships, customers have another thing to understand, support has another path to diagnose, and the team owns the behavior six months from now, after the person who requested it has moved on and the context has disappeared. It may also interact badly with the next three equally reasonable features. None of those costs show up when the prototype appears in an hour and everyone gets excited.
We’re treating the implementation estimate as the price of the idea when it was only ever the part we knew how to see.
AI is very good at the work surrounding a decision
A lot of product management is coordination: turning a messy conversation into requirements, routing work, summarizing meetings, updating tickets, asking three teams for status, and writing a long document that makes a decision look more official than it is.
AI is good at this work, or getting good quickly. I’m happy to see much of it disappear. I’m not nostalgic for the 30-page specs I saw early in my Microsoft career, and I don’t want PMs using their new capacity to maintain a larger backlog or produce nicer status updates.
But automating the work around a decision doesn’t make the decision better. It can just increase the number of decisions a team is capable of acting on.
When people say “PM is dead,” they’re often describing the coordinator version of the job. That version is in trouble, and probably should be. A person who mostly converts information from one format to another is now competing with software that can do it instantly, keep doing it all night, and never complain about the seventh revision.
The harder part of product work is deciding which customer problem deserves the team’s attention, which customer you’re actually building for, and what you’re willing to ignore even though implementation is suddenly cheap. AI doesn’t remove that responsibility. When almost any option can become real, capacity stops making the choice for you.
More options create a coherence problem
Give a team twenty landing-page variations and it can test twenty variations. That doesn’t mean it should.
A few will be mediocre, some will contradict what the company wants the product to become, and one may improve clicks while making the brand feel cheaper. The experiment can report what happened to the metric it measured. It can’t decide whether that’s the product you want.
The same thing happens across a product. The homepage change made sense when it shipped; so did the customer request that became a setting and the extra onboarding step needed to explain a new feature. Six months later, each decision is still defensible on its own, but nobody can explain who designed the whole experience. Nobody did. The product accumulated.
This happened when shipping was slow too. AI increases the pace and removes some of the discomfort that might have caused someone to say no. Every decision can make sense on its own while the product gets less coherent.
A product vision only helps when it’s specific enough to reject something. If every plausible feature can fit inside it, it isn’t doing much. And if the vision lives in a strategy deck nobody has opened since last quarter, the agents certainly aren’t going to save you. They’ll build from the context they have and optimize the task they were given.
Someone still has to hold the product in their head and notice when a good local decision pulls it in the wrong direction.
Product leaders need to spend the saved time differently
If AI gives PMs time back, spend it on the decisions we were rushing through before. Running the old product process faster would waste the opportunity.
Spend more time with customers, especially when their requests point in different directions. Use agents to explore ten approaches, but don’t pretend generating ten approaches is the same as choosing one. Make the product direction legible enough that teams and agents can use it. Kill ideas that are easy to build but don’t matter. Keep a record of why, because the same idea will come back two months later wearing a new hat.
Stop rewarding output as if it were the result. This will be uncomfortable because shipping is visible: a deploy happened or it didn’t. A good rejection leaves less evidence. The feature that would have added complexity never appears in a demo, and the quarter spent clarifying the right customer problem may look slower than the team releasing something every Friday.
If AI keeps making implementation cheaper, product leadership has to spend more time on judgment, taste, conviction, and coherence. Those words can sound soft until you see what happens without them: a very productive team building a product that gets busier without getting better.
For years the defining product question was, “How do we get this built?” We can answer that one much faster now.
So should we build it at all?