AI made the code the easy part. Everything around it still costs what it used to.
Lately I've caught myself asking an uncomfortable question about my own job: if execution is cheap now, why do we need a product manager at all?
Before AI, deciding which idea to work on took time, and a lot of that time was the PM's. Talking to customers, aligning stakeholders, running discovery, writing specs, defending priorities in planning. It was slow on purpose. Building was expensive, so getting it wrong was expensive too. There wasn't much room for mistakes.
Now a coding agent can build a first version of almost anything in days. So the natural reaction is: why spend weeks deciding? Just ship it and watch. If it works, great. If it doesn't, drop it and move on. In that world, the PM looks like a step you can skip.
I get the appeal. I've felt it myself. But I think this line of thinking misses something important.
The code was never the whole launch
Here's a real example. We're considering an integration checklist: a page inside the merchant's admin that shows what's working in our integration and what's missing. Our merchants use a very flexible ecommerce platform, and their customizations can quietly break parts of our integration. The goal is trust and transparency, so merchants stop wondering what's wrong.
The engineering estimate came back at 84 hours. A few years ago, that number alone would have started a long debate. Today it feels small. With AI, maybe it's even smaller.
But the 84 hours is only the code. Launching the checklist to 300 to 400 merchants means a lot more than that:
- Customer success needs to understand it and explain it to merchants.
- Support needs to know how to answer "my checklist says something is missing, what do I do?"
- Documentation and help articles need to be written.
- Marketing needs time to understand it and decide how to announce it.
- Other stakeholders need to review it, agree on it and approve it.
None of that got cheaper with AI. Each of those is a team with its own priorities, schedule and limited time. And it doesn't stop at launch. Once the checklist lives inside the merchant's admin, every change and every bug touches all of those teams again.
"Just try it" can cost more than before
This is the part I think gets missed.
If a team takes the "just ship it and see" approach, the expensive part doesn't disappear. It moves. The engineering cost goes down, but every experiment that reaches customers pulls in support, customer success, docs, marketing and whoever needs to approve it. Ship ten experiments instead of two, and you've pulled those teams in ten times.
And if the experiment fails, you pay again to undo it. You tell merchants it's going away, update the docs, retrain support and answer the confused tickets.
So a company that "just tries things" can end up spending more than it did before AI. Not on writing software, but on all the people and processes that have to move every time something reaches customers. In B2B, where every change touches real customers with real workflows, that cost adds up fast.
Building is cheap. Launching isn't.
Watching and seeing isn't fast either
There's a second problem with "ship it and monitor."
With 300 to 400 merchants, I can't launch five versions of the checklist and see which one wins. I barely have enough merchants to compare two. And the thing I want to measure, trust, doesn't show up next week. It shows up slowly, in fewer anxious tickets and calmer conversations, over months.
So "launch and see" isn't even fast. It's an expensive launch followed by a long wait.
Find out before the launch starts
So what's the alternative? You could say: don't launch to everyone. Put it behind a flag, release it to 20 merchants. And that's exactly the point. A launch doesn't have to involve the whole company, but only if someone makes the first version small enough on purpose. For me, that means moving the learning to before the real launch, when only a few people need to be involved.
For the checklist, one idea I keep coming back to: the cheapest version might not be a dashboard at all. It could be a script that runs the checks for 20 merchants, and an email to each one saying "here's what's working and what's missing in your setup." An agent could write that script in an afternoon. No launch, no docs, no announcement, no support training.
Then two questions. Was the report right? Support could compare it with what they actually see. And did it help? Did those merchants stop asking "is it working?" and fix things on their own?
If the answer is no, we've learned it with a small group, in a few weeks, without pulling in the rest of the company. If the answer is yes, then the full launch, with everyone it involves, is worth it. It's only an idea for now, but it's the kind of test I'd want before building.
The difference is who has to be in the room. A test before launch involves the few people who can answer the question. A launch involves everyone who has to live with the answer.
So why do we still need a PM?
I don't think the answer is "because someone has to decide what to build." AI is making that part of the job smaller, and I think we should be honest about it. Maybe teams will need fewer PMs.
But someone still has to count the cost of a launch before it starts. Not the 84 hours, but the support time, the docs, the announcements and the cleanup if it fails. Someone has to ask "how will we know this worked?" while the answer is still cheap to get. Right now, that's the part of my job I think matters most.
The 84 hours used to be the hard part. Now it's the easy part. The hard part is everything that happens after the code is done.
I'm curious how other teams are handling this. What did you ship recently that turned out to cost a lot more than the code?