PMs Who Vibe Code: Why Product Managers Should Prototype

An engineer reviews what they expected to be a wireframe. Instead, it's a working app. The data flows. The authentication works. Users have already been testing it. A Product Manager built it over a weekend using Lovable and Claude. The engineer's first reaction isn't admiration. It's: "Who owns this? How do I know it actually works?" Welcome to the most polarising debate in product management right now — should PMs build their own prototypes?

Replit's CEO says product managers are "some of the best vibe coders." Naval Ravikant says "vibe coding is the new product management." Meanwhile, veteran PM leaders are warning that PMs who spend half their week in Cursor are neglecting the strategic work nobody else will do. Both sides are right. Here's why — and where the actual value sits.

In This Post

The debate: should PMs build or should PMs manage?
What changed in 2026: why this is even possible now
The real case for PMs who prototype
The real case against PMs who prototype
The honest answer: when to build and when not to
My workflow: how I prototype as a PM
The tools that make this possible
What changes when you show a prototype instead of a spec
The bottom line

The Debate

This is the most polarising topic in product management right now, and both sides have legitimate arguments.

The "PMs should build" camp: Replit CEO Amjad Masad says product managers are "some of the best vibe coders" because they're trained to break problems into clear steps and communicate them precisely. Naval Ravikant called vibe coding "the new product management." At ProductCon London 2026, the core message was clear: the product leader is becoming a builder, and 2026 is the year of the AI cloud playground. McKinsey reports that generative AI can reduce product time-to-market by 5% and increase productivity by 40%.

The "PMs should manage" camp: Bryce York argues that PMs have many higher-value ways to spend their time than vibe coding prototypes, and that the newfound ability for any PM to code is creating a time sink that fundamentally misunderstands where a PM's value lies. Saeed Khan writes that if PMs are doing other people's work, nobody is doing the product management work — customer discovery, competitive positioning, market analysis, business case development — that PMs should actually be doing.

Here's the truth that neither side says clearly enough: the value isn't in the building. The value is in what the building enables. A PM who spends half the week in Cursor writing code is wasting time. A PM who spends 90 minutes in Claude Artifacts to produce a clickable prototype that replaces a 3-week engineering spike — that's leverage.

The "PMs Should Build" Argument	The "PMs Should Manage" Argument
Prototypes communicate ideas better than specs	PMs have higher-value strategic work to do
Reduces dependency on engineering for validation	Vibe coding is a time sink disguised as productivity
Builds empathy with engineering teams	If PMs code, who does the PM work?
Validates ideas before committing engineering resources	Designers and engineers can prototype too
Speed — prototype in 90 minutes vs 3-week sprint	Everyone can vibe code, so it's not a PM differentiator
PMs are trained communicators — prompt engineering is a natural fit	PM superpower is strategy, not execution

What Changed in 2026

Two years ago, a PM who wanted to prototype had two options: learn to code (months of investment, mediocre results) or build static mockups in Figma (useful but limited — no real data, no real interactions, no way to test with actual users).

In 2026, the equation is completely different. Here's what changed:

AI tools got good enough for non-engineers. Claude Artifacts generates interactive React components from natural language in under 60 seconds. Lovable builds full-stack applications with real Supabase backends, authentication, and deployment from a conversation. Bolt.new generates prototypes in under 15 seconds. These aren't wireframes — they're working software with real databases and real user flows.

The prototype-to-production gap shrunk. The output from these tools isn't throwaway. A Lovable prototype can be iterated into a production application. A Claude Artifacts component can be handed to engineering as a reference implementation. The work isn't wasted — it's the first draft of the actual product.

PMs are natural prompt engineers. This is Replit CEO Masad's key insight: PMs are trained to decompose problems into clear requirements, prioritise features, and communicate precisely. That's exactly what prompt engineering requires. The same skill that makes you good at writing user stories makes you good at describing software to an AI.

The PM-engineer contract changed. For decades, PMs owned the "what" and engineers owned the "how." That contract, as one Medium writer puts it, is now functionally obsolete. When a PM can show up with a working prototype, the conversation with engineering shifts from "here's what I want" to "here's what works — how do we make it production-ready?"

Era	What PMs Could Build	Time Investment	Quality
Pre-2024	Static wireframes in Figma/Balsamiq	Hours	Visual only, no real interactions
2024-2025	Basic prototypes in Replit/v0	A day	Working UI, basic logic, often broken
2026	Full-stack apps with database, auth, and deployment	60-90 minutes	Working software with real data flows

The Real Case for PMs Who Prototype

Let me make the case from direct experience — not theory.

1. A Prototype Communicates What a PRD Cannot

I've written hundreds of product specs in my career. Not once has a stakeholder read a spec and fully understood the product I was describing. But every single time I've shown a working prototype, the conversation changed immediately. Questions become specific. Feedback becomes actionable. Buy-in happens faster because people can see and touch the thing instead of imagining it from a document.

As the ACM Communications piece on vibe coding puts it: PMs build functional prototypes that demonstrate exactly what they mean — not wireframes that leave room for misinterpretation.

2. It Kills the Spec-to-Sprint Translation Loss

The biggest source of wasted engineering time in most product teams isn't bad code. It's building the wrong thing because the spec was ambiguous. A prototype eliminates that ambiguity. The engineer can open it, click through it, and see exactly how every interaction should work. There's no "I interpreted the user story differently" conversation at the end of the sprint.

3. It Validates Before You Commit Resources

This is the highest-leverage use case. Before you add a feature to the roadmap, before you pull engineers off other work, before you write a detailed spec — build a 90-minute prototype and put it in front of 3 users. If they hate it, you've lost an afternoon. If you'd built it the traditional way, you'd have lost a sprint.

4. It Changes the Dynamic With Engineering

When you can show an engineer a working prototype instead of a Jira ticket, two things happen. First, the conversation becomes collaborative instead of directive — you're solving a problem together, not handing down requirements. Second, you earn technical credibility. You don't need to be a great coder. You need to be a PM who understands what's technically possible and has enough empathy for the engineering process to have informed conversations about tradeoffs.

5. It Makes You Faster at Everything Else

Once you can prototype, you stop over-specifying. Your PRDs get shorter because the prototype carries the detail. Your design reviews get faster because there's a working reference. Your stakeholder meetings get more productive because people respond to demos, not decks. The prototype doesn't replace PM work — it accelerates it.

The Real Case Against PMs Who Prototype

The critics aren't wrong. Here's where prototyping becomes a trap:

1. The Time Sink Problem

Bryce York's warning is real: he's seen PMs spending half their week in Cursor. That's not prototyping — that's playing developer. A prototype should take 60-90 minutes, not three days. If you're spending more time than that, you've crossed from "PM who validates quickly" to "PM who's avoiding the harder strategic work."

The rule I follow: spend as much time vibe coding as you used to spend wireframing. Not more. It should replace wireframing, not replace strategy.

2. Nobody Else Does the PM Work

Saeed Khan's argument is the strongest one against PM prototyping: if PMs are building, who is doing customer discovery, competitive analysis, market positioning, business case development, and roadmap strategy? Engineers won't. Designers won't. These are core PM responsibilities, and they're already under-invested in most organisations. Vibe coding shouldn't cannibalise time that belongs to discovery and strategy.

3. When Everyone Can Build, Building Isn't a Differentiator

When PMs, designers, engineers, sales engineers, CEOs, and a 91-year-old church volunteer can all vibe code, the ability to build a prototype isn't a competitive advantage. It's table stakes. The competitive advantage is still knowing what to build, for whom, and why — the strategic work that AI can't do for you.

4. Prototype ≠ Product

A working prototype that impresses stakeholders can create dangerous momentum. I've seen vibe-coded prototypes get pushed toward production without security review, without performance testing, without architecture consideration. The prototype works for 5 users. It breaks at 500. The gap between "impressive demo" and "production-ready software" is real, and PMs who build need to be honest about where that line is.

The Honest Answer: When to Build and When Not To

Both sides of this debate are right — about different situations. Here's the framework I actually use:

Situation	Should You Prototype?	Time Budget
Validating a new feature idea before committing to the roadmap	Yes — highest-value use case	60-90 minutes
Getting stakeholder buy-in for a concept	Yes — prototypes persuade better than decks	60 minutes
Communicating a complex interaction to engineering	Yes — replaces ambiguous specs	30-60 minutes
Building internal tools for your own PM workflow	Yes — dashboards, trackers, automations	2-3 hours
Building a user-facing feature for production	No — hand off to engineering after validation	0
Spending a full day iterating on pixel-perfect UI	No — that's design work, not PM work	0
Replacing your customer discovery and strategy time	No — that's the work only you can do	0
Trying to prove you're "technical"	No — build credibility through product judgement, not code	0

The pattern: prototype to validate, not to ship. Prototype to communicate, not to impress. Prototype to save time, not to fill time.

My Workflow: How I Prototype as a PM

Here's the actual process I follow. It takes 60-90 minutes for a typical feature prototype.

Step 1: Define the Problem (10 minutes)

Before opening any tool, I write three things: the user problem (one sentence), the success metric (one number), and the hypothesis (if we build X, users will do Y). If I can't write these clearly, I'm not ready to prototype — I need more discovery.

Step 2: Describe the Solution in Plain English (10 minutes)

I write a natural language description of what the prototype should do. Not a spec — a conversation. "I need an app where school administrators can browse science lab equipment by category, add items to a cart, and submit a purchase order that goes to the finance team for approval." This description becomes my prompt.

Step 3: Build in Claude Artifacts or Lovable (30-45 minutes)

For quick UI concepts and interaction validation, I use Claude Artifacts. It generates interactive React components instantly, and I can iterate through conversation. For prototypes that need a real database, authentication, and deployment, I use Lovable — it connects to Supabase and gives me a full-stack app I can share via URL.

I iterate 3-5 times through conversation. Each iteration takes 2-3 minutes. By the end, I have a clickable prototype with real interactions.

Step 4: Test With Users (20 minutes)

I share the prototype URL with 3-5 real users — the target audience for the feature. I watch them use it. I note where they get confused, where they try to click things that don't exist, and whether the core flow makes sense. This is not a usability test — it's a concept validation. Does this solve the problem?

Step 5: Decide (5 minutes)

Three possible outcomes: kill it (users didn't respond — saved a sprint of engineering), iterate (promising but needs changes — back to Step 3), or hand off (validated — write a lightweight spec with the prototype as reference and hand it to engineering for production).

Step	Time	Tool	Output
Define the problem	10 min	Pen and paper / Notion	Problem statement, metric, hypothesis
Describe the solution	10 min	Text document	Natural language prompt
Build the prototype	30-45 min	Claude Artifacts / Lovable	Working interactive prototype
Test with users	20 min	Prototype URL + video call	User feedback, validated or invalidated hypothesis
Decide	5 min	Your PM judgement	Kill, iterate, or hand off to engineering

Total: 75-90 minutes from idea to validated decision. Compare that to the traditional process: 2 days writing a spec, 1 week waiting for design, 2 weeks waiting for engineering, then discovering users don't want it.

The Tools

Here's what I actually use, matched to the type of prototype:

What I'm Building	Tool	Why This Tool
Quick UI concept or interaction demo	Claude Artifacts	Instant React components, iterate through conversation, no setup
Full-stack app with database and auth	Lovable	Real Supabase backend, deployable, shareable URL
Fast throwaway prototype	Bolt.new	Fastest generation time, good for exploring multiple approaches
Multi-agent or complex flow prototype	Emergent	Multi-model coordination for complex AI features
Internal PM tool or dashboard	Claude Code + Supabase	When I need more control and the prototype might become permanent
Presentation or pitch	Gamma	AI-generated presentations from a single prompt
Design handoff reference	Google AI Studio	Free, quick experimentation with different AI models

What Changes When You Show a Prototype Instead of a Spec

This is the part nobody writes about. The practical, day-to-day impact of being a PM who can prototype:

Stakeholder meetings get shorter. Instead of 45 minutes explaining a feature, you spend 5 minutes demoing it and 40 minutes discussing strategy.

Engineering estimates get more accurate. Engineers can see exactly what you're asking for. The "we thought you meant..." conversation disappears.

Design collaboration gets better. You're not handing designers a vague brief. You're showing them a working version and saying "make this beautiful and accessible." They improve something concrete instead of interpreting something abstract.

You kill bad ideas faster. The prototype either works or it doesn't. Users either respond or they don't. There's less room for political features — ideas that survive because someone senior likes them, not because users need them.

Your career accelerates. In every PM interview I've studied, candidates who can demo a working prototype outperform candidates who can only describe one. In every stakeholder meeting I've been in, the PM with a prototype gets the resources. This isn't fair — strategic thinking should matter more than demos. But demos are tangible, and humans respond to tangible things.

The Bottom Line

The debate over whether PMs should vibe code misses the point. The question isn't "should PMs build?" The question is "what should PMs build, when, and for how long?"

Build to validate — not to ship. Build to communicate — not to impress. Build to save engineering time — not to replace engineers. And never, ever let the dopamine hit of "I built a thing" replace the harder, less visible work of understanding your users, positioning your product, and making the strategic decisions that only a PM can make.

The PM who can prototype has a new tool. The PM who can think strategically has a career. The PM who can do both has an unfair advantage.

Don't be the PM who vibe codes all week. Be the PM who vibe codes for 90 minutes, validates an idea, and then spends the rest of the week on the strategy that makes it matter.