There is a particular meeting every product manager knows. You have an idea. Engineering has a capacity constraint. Design has a queue. And the only thing you brought into the room is a slide with a hypothesis on it.
You lose that meeting. Not because the idea was bad, but because a hypothesis on a slide is the weakest possible artefact. It costs nothing to produce and it costs nothing to dismiss.
For the last two years I have stopped bringing slides to those meetings. I bring the thing.
What actually changed
Cursor, Claude Artifacts, Replit, v0 — the specific tool matters far less than the shift they enable. A PM who is fluent in these environments can go from “I think users are struggling with X” to a working, clickable, occasionally-ugly artefact in an afternoon. Not a Figma prototype that mimics behaviour. An actual thing that runs.
That sounds like an efficiency gain. It isn’t. It’s an epistemic one.
When I built an AI-driven discovery agent at iCIMS to automate user-insight extraction, the goal was never to ship my code. My code was never going to ship — engineering rewrote it properly, as they should. The goal was to answer a question no amount of analysis was going to settle: does automated insight extraction actually produce insights a human researcher would trust?
The prototype answered it in a week. The debate would have taken a quarter. We cut the discovery cycle from 60 days to 40, and the reason we could commit to that number is that we had already watched it happen at small scale.
The distinction that matters
Vibe coding gets dismissed as PMs playing at engineering. That criticism lands when the PM confuses the prototype with the product. It misses entirely when the PM understands what the prototype is for.
A prototype is not a head start on the build. It is a cheap experiment that converts an unfalsifiable opinion into a falsifiable one.
Consider the difference in how these two statements land with an engineering lead:
“I think an AI copilot would drive adoption.”
“I put a rough copilot in front of eleven users. Seven of them used it unprompted a second time. Here’s the recording of the four who didn’t, and here’s why.”
The first is a request for faith. The second is a request for engineering time backed by evidence. When we ran the AI Copilot initiative through rapid experimentation and beta testing, the 200+ installations we ended up with were not a surprise — they were the predicted outcome of signal we had already gathered.
Where it goes wrong
Three failure modes I’ve watched teams fall into, including my own:
Prototyping the easy half. AI features are trivially easy to demo and brutally hard to make reliable. A prototype that only handles the happy path tells you nothing about whether the feature is viable. Deliberately prototype the ugliest input you can think of.
Falling in love with your own artefact. You built it, so you want it to be right. The prototype’s job is to be killed cheaply. If you find yourself defending it rather than testing it, you have stopped doing discovery and started doing advocacy.
Skipping the handoff conversation. Nothing corrodes trust with engineering faster than a PM who shows up with working code and an implied “so just ship this.” The framing has to be explicit: this is evidence, not architecture. You own how it gets built.
What this means for the role
The PM job description has always included “translate business problems into technical roadmaps.” What’s changed is the bandwidth of the translation. You can now round-trip an idea through a working artefact before committing anyone else’s time to it.
That advantages a specific kind of product person — one comfortable being hands-on, comfortable being wrong quickly, and disciplined enough to throw the artefact away. It disadvantages the PM whose primary output is documents about work rather than the work itself.
I don’t think that’s a temporary shift. The cost of testing an idea has collapsed. Anyone still arguing from opinion is competing against people arguing from evidence, and they will keep losing that meeting.