AI has product managers cosplaying as engineers. But writing code isn't the mistake.
The mistake is building without a question. Product managers writing code without testing an assumption. Engineers redesigning screens without knowing what's failing. Both look busy. Both produce something you can demo. And you can build faster and still learn nothing about what customers need.
AI made building so cheap that a team can build an idea faster than it can judge it. That is the real shift, and it changes what a good product experiment looks like.
The standoff: whose job am I doing?
When anyone can generate code, screens or plans, the lanes blur. Everyone starts watching everyone else and asking the same question: "whose job am I doing?"
It's a Mexican standoff, and it is the wrong argument. The better question is "what does this help us decide?" That question works whatever your title is. A product manager writing a prototype to test a pricing assumption is doing the job. An engineer reworking a screen because the funnel data shows where users drop is doing the job too. The work earns its place by the decision it informs, not by whose lane it sits in.
If you want the other half of this argument, why the call about what to bet on still belongs to the product manager, see /vault/role-confusion.
Speed up the whole loop, not just the build
The people pulling ahead aren't just building faster. They're finding out what works sooner. Building is one step in a loop, and the loop is what you are trying to speed up.
If the steps look familiar, they echo the observe, orient, decide, act loop from military strategy. In product work it runs in five steps.
Observe what's happening
Start with what is in front of you. Usage, support tickets, a sales call that went sideways, a metric that moved when nothing shipped. Observation is cheap, and it is often where the useful surprises show up.
The trap is skipping straight to a fix because building one is now so easy. A fix built before anyone has looked closely at what is happening is still a guess, just a faster one.
Orient on what it means
Observation tells you what happened. Orientation is deciding what it means for your product, your customer and your strategy. Two teams can look at the same drop in activation and read it two different ways.
Orientation is where judgement does most of its work. It is also the step AI can help with least on its own, because it depends on context only your team holds: why you picked this customer, what you already tried, what you are not doing this quarter.
Decide what to test
Turn the reading into one question worth answering. Not "should we redesign onboarding?" but something you can check, with an answer that would change what you do next.
A good test question names the assumption under the plan. If the assumption turns out wrong, the plan changes. If no result could change the plan, the test is only for show.
Build just enough to find out
Now build, and build the least you can. Code, a prototype, a customer call. Use whichever tool gets you the evidence you need fastest.
Sometimes that is a working prototype, because AI made one cheap enough to put in front of users this week. Sometimes it is a conversation, because one call with the right customer answers the question before a line of code. The tool is a means. Make the smallest bet that answers an important question.
Use the result to choose the next bet
The loop only pays when the result changes something. Use what you learnt to judge what deserves more investment, what should stop, and which question comes next.
It is an easy step to skip when building is cheap. A prototype ships, people like it, and it rolls straight into the roadmap without anyone asking what it proved. Then the next bet is chosen the same way as the last one.
Building got cheap. Guessing never did.
Cheap building is good news for product managers who use it to learn. It means more questions answered per month, smaller bets, and less time defending a plan nobody has tested. It is bad news only for teams that measure progress in things built.
So the next time someone asks whose job you are doing, change the question. Ask what the work will help you decide, and whether there is a smaller bet that would answer it sooner.
If you want to see where you stand against other product managers on building to learn, the scorecard at martongaspar.com/scorecard asks whether you are AI naive or AI native.