The Product Manager Is Dead. Long Live the Product Builder.

TL;DR

• The traditional Product Manager role is evolving into a "Product Builder" who can prototype with AI, not just define requirements
• Major companies (Meta, LinkedIn) are institutionalising this shift. It's not a trend; it's a structural change
• The new "full stack" for PMs is Prompt, Build, Eval, and the hardest part is evaluation, not construction

---

We are witnessing the most significant shift in Product Management since the Agile Manifesto. It has a name, and it's changing how software gets built: Vibe Coding.

That term gets eye-rolls from engineers, and I understand why. But dismiss the label if you want. The behaviour change underneath it is real, and it's happening at the highest levels of the industry.

The institutional signals are loud

At Meta, PMs are no longer waiting on engineering capacity to test an idea. They're using AI to vibe code functional prototypes in hours and demoing them directly to Mark Zuckerberg. This isn't a skunkworks experiment. It's how product development is starting to work at one of the largest technology companies on earth.

Tomer Cohen, Chief Product Officer at LinkedIn, recently scrapped their traditional Associate Product Manager (APM) program. The APM program, the gold standard entry path into product management for over a decade, is gone. In its place: the "Full Stack Builder" program, designed to teach coding, design, and product strategy as a single, unified skillset.

When Meta and LinkedIn independently arrive at the same conclusion, it's not a coincidence. It's a signal.

What "full stack" actually means now

The old "full stack" meant a developer who could work across frontend and backend. The new "full stack" for product people means something different. It means using AI to own the vertical, from problem identification to working prototype.

1. The Prompt (Describing Intent)

The first skill is the ability to describe intent clearly enough that an LLM can execute it. This is harder than it sounds. It requires you to think precisely about what you want, decompose it into achievable steps, and communicate constraints and edge cases in a way that a model can act on.

This isn't "prompt engineering" in the sense of memorising magic phrases. It's a communication discipline. The PMs who are good at writing clear requirements documents tend to be good at this. The ones who've been hiding behind vague user stories are exposed immediately.

2. The Build (Prototyping)

The second skill is creating the MVP yourself. Tools like Replit, Lovable, v0 by Vercel, and Google's AI Studio have collapsed the distance between "I have an idea" and "I have a working prototype" from weeks to hours.

This changes the dynamics of product development entirely. A PM who can build a functional prototype before the sprint planning meeting has already changed the conversation. They're not pitching an abstract concept. They're showing a working thing. The discussion shifts from "should we build this?" to "how should we improve this?"

That's a different conversation entirely. And it's a much more productive one.

3. The Eval (Quality Control)

This is the part most people underestimate. As OpenAI's Kevin Weil has noted, the new hard skill isn't building. It's writing evals. The hard work is no longer figuring out how to construct something. It's rigorously testing whether the thing you built actually solves the user's problem.

When AI can generate code, the bottleneck shifts from construction to evaluation. Can you define what "good" looks like? Can you write test cases that catch the failure modes? Can you measure whether a prototype is genuinely useful or just superficially impressive?

Product judgment becomes critical at this stage. An engineer might evaluate whether code works. A product builder evaluates whether it matters. I explore the three skills that replace the translation layer (problem shaping, context curation, and taste) in depth.

Why this shift is inevitable

The economics are straightforward. Engineering capacity has always been the primary constraint on product development. Every prioritisation framework, every sprint planning ritual, every roadmap negotiation exists because there are more ideas than there are engineers to build them.

AI-assisted prototyping doesn't eliminate that constraint entirely, but it dramatically loosens it for the exploration phase. The cost of testing an idea has dropped by an order of magnitude. When testing is cheap, you should test more. And the person closest to the customer problem, the product builder, should be the one doing the testing.

This is why the shift is structural, not cosmetic. It's not about PMs learning to code as a nice-to-have. It's about the fundamental economics of product development changing in a way that demands a different skillset.

The uncomfortable part

This is a demanding shift. Not every PM will make it.

The PMs who've built careers on stakeholder management, roadmap theatre, and translating between business and engineering without ever getting their hands dirty are in trouble. Those skills still matter, but they're no longer sufficient.

The PMs who've always been curious about how things work, who've dabbled in no-code tools, who've built side projects, who've pushed to understand the technical architecture: they're about to thrive. The tools have finally caught up to their ambition.

We're returning to a hands-on culture where the person defining the strategy has the tools to execute the prototype. The future belongs to the PMs who can stop waiting for resources and start shipping solutions.

The title on your business card might still say Product Manager. But the job is increasingly Product Builder. Act accordingly. I unpack the full shift in the Product Builder handbook. OpenAI's enterprise data already quantifies the gap between those who've made the shift and those who haven't.

---

Frequently Asked Questions

Does this mean PMs need to become engineers?

No. The point isn't to replace engineers. It's to collapse the gap between idea and testable prototype. Production code still requires engineering discipline, architecture decisions, and scale considerations that AI prototyping doesn't address. But the exploration phase? That's now accessible to anyone who can describe intent clearly and evaluate output critically.

Is "vibe coding" just a buzzword?

The term is provocative by design, and yes, it gets overused. But the underlying behaviour (using AI to rapidly generate functional prototypes from natural language descriptions) is real and accelerating. Whether you call it vibe coding, AI-assisted prototyping, or something else entirely, the capability exists and it's changing workflows at major companies right now.

What should a PM do to start building this skillset?

Pick a real problem you've been wanting to test. Not a toy project, but something connected to an actual user need. Use an AI coding tool to build a prototype. The goal isn't a polished product. It's to experience the full loop: describe what you want, iterate on the output, evaluate whether it solves the problem. That cycle teaches you more about the new skillset than any course or article.