There's a lot of dramatic commentary about what AI means for product teams. Some say product managers (PMs) are no longer needed. Others say PMs with tools like Claude Code and Lovable don't need designers or engineers anymore. Having spent over a decade in product management, I think both takes miss the point. The more interesting question isn't which role disappears, but how AI-assisted prototyping is changing the way all three roles work together.
How It Worked In The Past (At Its Worst)
The old process often had a kind of painful, predictable rhythm to it.
- A PM would gather requirements from the customer, then hand off design tickets to designers.
- Designers would build mockups in Figma, only to hear "that's not what we asked for."
- After several cycles, the designs would finally get handed off to engineers, along with hours of story mapping or Shape Up sessions just to transfer enough context for them to get started.
- Then came "that's going to take forever," triggering another round of design rework to cut scope.
- When the build was done, design would flag that it didn't look or behave right.
- Then the PM would say it didn't match the requirements.
- Then the customer would say it didn't match what they meant.
- And the whole thing would start over. Sound familiar?
What made this so costly wasn't any individual failure of judgment. It was the structure itself. Feedback that could have been gathered in days was instead gathered in months, after significant resources had already been committed.
How AI-Assisted Prototyping Changes Things
The most meaningful shift enabled by today's AI tools is not the automation of any single role. It is the compression of the feedback loop. A PM, designer, and engineer can now collaboratively produce a functional, interactive prototype in hours. The PM contributes customer context and business framing; the designer ensures visual quality, UX coherence, and adherence to best practices; the engineer validates technical feasibility early enough to actually influence the design, rather than simply inherit it.
What matters here is that this prototype can be placed in front of customers before any production code is written. Iteration happens at the cheapest possible stage. Only once the concept is validated does engineering effort shift toward productization: scalability, configurability, security, testability, and codebase integration. The rework that previously consumed engineering cycles moves to the prototyping phase, where the cost of change is far lower.
Could One Person Do It All?
It's a fair question. The skills involved are: deep customer discovery informed by business strategy, wireframing and rapid prototyping, visual design and UX judgment, engineering scope assessment, and production-ready software development. That's a rare combination, even in a market that has long rewarded generalists. I've met very few developers or PMs who produce truly high-quality design. Very few designers who write production-ready code. And very few designers or engineers who can also navigate the business context needed to gather the right customer requirements in the first place.
Could someone cover two out of three? Maybe! And I expect we'll see more of those hybrid roles emerge. But the most likely outcome isn't one role swallowing the others. It's all three roles becoming dramatically more productive, shipping more and better features with smaller teams and faster cycles.
What changes is not who does the work. It's how quickly, and how collaboratively, the work gets done.
Agree? Disagree? I'd be curious what practitioners in each discipline are seeing on the ground.