The room went quiet.
I had walked into engineering standup on a Tuesday morning with a laptop, opened it, and clicked through a working prototype of the feature I had been arguing about for six weeks. Seed data. Real interactions. The thing actually did what I had been describing in PRDs that nobody read past page two.
I had built it the night before, between 9pm and 11:30pm, in my kitchen, with a glass of wine going warm beside me.
Vibe coding for product managers is what happened to me that week. I am a PM at a mid-stage SaaS company. I cannot write a for loop without Googling the syntax. And yet there I was, three minutes into a demo, watching a senior engineer lean forward and squint at the screen.
He spoke first.
"Okay, but the database model is wrong."
That was the best PRD review I had ever gotten. Six weeks of arguments, collapsed into one clean technical objection, because for the first time he was looking at the actual thing instead of my interpretation of the thing. We sketched a corrected schema on a whiteboard in twenty minutes. The feature shipped, in real code, written by him, four weeks later.
This post is about what changed for me, what I think changes for any PM who picks up these tools, and where it absolutely does not work. My co-author Maya, also a PM, is going to take over partway through and walk you through her actual stack. She is the one who taught me most of this.
What vibe coding changes for PMs
The PRD is no longer the artifact. The prototype is.
I do not mean PRDs are dead. I still write them. I write shorter ones now, because the prototype carries the weight a 4-page document used to carry. A working demo answers more questions in two minutes than my best-written spec ever did, and it asks better questions back.
You do not need to learn JavaScript. I want to repeat that because I see PMs trying to take Codecademy courses on weekends and getting depressed about it. You do not need to write code. You need to learn to direct an agent that writes code. Our vibe coding beginners guide walks through the whole process from zero. Those are different skills. The first one took my engineering friends years. The second one took me about two weeks of evening practice to get usable, and I am still getting better.
The bar for the word "validated" goes up. Way up. "I think users want X" used to be a respectable opening line for a roadmap discussion. It is starting to sound flimsy. The question now is "Here is X. Did 10 of them use it? What happened?" That is harder to fake.
And engineers stop being expensive translators. They become the people you consult on the parts that actually require their expertise, which turns out to be the architectural and infrastructural and scaling parts. Not the "what should this button do" parts. That changes the relationship in ways I think most PMs and most engineers are still figuring out.
The four PM use cases that work
I have tried, badly, to use vibe coding for maybe a dozen things. Four of them have worked consistently. The other eight either failed or wasted my time. Here are the four.
a) Prototypes for stakeholder buy-in
This is the use case that won me over.
You can build a working clickable demo, with seed data, in about two hours. It will look rough. The logic will have holes. But it will behave, and behavior is what reveals the things static screens cannot. Figma is brilliant for layout debates and useless for "wait, does this flow actually make sense when you click through it three times in a row?"
Tools I have tried for this: Bolt, Lovable, v0, and Claude Code when I want more control. Our vibe coding tools comparison breaks down the tradeoffs in detail. Bolt and Lovable are faster. Claude Code is more flexible but takes longer to set up.
Real example: a PM I know at a fintech company built a fraud-review interface in one evening, maybe four hours total, to show his head of compliance what the daily workflow would actually feel like. The compliance lead had been pushing back for months on the "speed" requirement. Two minutes into clicking through the prototype she said "oh, this is going to be exhausting, we need to batch these." That batching insight became the actual feature. The PM had been trying to tell her this in writing for a quarter. She figured it out herself in two minutes of clicking.
That is the leverage. Not "I built the thing." It is "I gave the people who decide things a concrete object to react to."
b) Internal tools nobody else will build
This is the one that quietly returns the most value over time.
Every PM has a backlog of small annoyances. I just need to query the database and tag a hundred customer accounts. I just need a form my support team can fill out so the data ends up structured. I just need a tiny dashboard that shows the three numbers I check every morning.
Engineering will not prioritize these. They are right not to. Each one individually saves three hours a week. Bundled into a quarter-long internal-tools project they would save real money, but no PM ever gets to scope a quarter-long internal-tools project, so the savings never happen.
Vibe coding lets you build them yourself. Claude Code plus a backend-as-a-service like Supabase is the stack I use most. Supabase gives you a Postgres database and auth in about ten minutes, which used to be a week of engineering setup.
Real example: Maya (you will hear from her in a minute) built a customer-tagging tool that saved her customer success team three hours a week. Four hours of evening work, total. By napkin math, that team is six people, three hours each per week, fifty weeks per year is 900 hours saved annually. At loaded cost that is something like $90,000 of time freed up, from a tool that took her one Saturday afternoon. Eng would never have built that. The math works only because she did it herself.
c) Customer interview synthesis
This one is more about thinking than building.
Feed transcripts to Claude. Ask it to pull out themes. Ask it to find quotes that contradict your hypothesis, not just ones that support it. Then build a small app, maybe a single page, that lets your team tag interviews collaboratively. The PM stops being the bottleneck for synthesis, and the synthesis itself gets better because more brains are touching the data.
Real example: I had 47 customer interview transcripts sitting in a Google Drive folder doing nothing. Over a weekend I built a quote-tagging tool, basically a list view with checkboxes and a tag input, hooked up to Supabase. I shared the URL with three teammates on Monday. By Friday we had tagged most of the corpus together, found a theme nobody had named before, and shipped a positioning change off the back of it.
The tool was ugly. The findings were good. Nobody on my team cared that the buttons were misaligned.
d) A/B test scaffolds
This is the use case I am still getting the hang of.
The PM builds a scrappy "v2" of a feature. Engineering then ports the working logic into the actual production codebase, with proper data models, tests, and infrastructure. The vibe coded version is the probe that proves the hypothesis is worth productionizing.
Real example: a pricing page experiment I ran last quarter. I built a working mockup of a new pricing structure, with toggles, calculators, and the full purchase flow, in about six hours. I showed it to two existing customers in user interviews. Both bought into the model immediately. I handed the prototype to engineering with a single sentence: "Port this, please." They had a production version live in three engineering days, against a quarter we had previously estimated the project at.
The prototype was throwaway code. The hypothesis it validated was not.
Maya here: the PM toolkit I actually use
Hi. Omar handed me the keyboard.
I have been a PM for seven years and a vibe coding PM for about fourteen months. Here is the stack I actually use, in the order I reach for it on a given week.
Claude Code in the terminal for any prototype I expect to live longer than a week, or anything that touches a database I want to understand. The terminal is intimidating for the first four hours and then it is fine. The Claude Code tutorial got me past the initial setup. The reason I prefer it over the in-browser tools for serious work is that I can read what it is doing, ask it to explain its choices, and intervene before it builds the wrong thing. Our 50 Claude Code tips post is what got me started; I am still working through it.
Bolt or Lovable for "I need to show this to a stakeholder by 4pm and it is currently noon." These tools are pure speed. You describe what you want in a chat box, you get a working app, you share a URL. The output is rougher than what Claude Code produces, but for stakeholder-buy-in prototypes that is fine. The stakeholder is reacting to behavior, not architecture.
Supabase for the database and auth on anything I want to actually use. Postgres in ten minutes. Auth in another ten. I was paying for a different BaaS for the first six months of my vibe coding journey and Supabase has just been better, in my experience.
Vercel for deploys. I push to GitHub, the site goes live. I do not understand half of what happens in between and I do not need to.
n8n or Make for connecting tools together. The "I need a Slack message every time something happens in the database" type of work. These are not strictly vibe coding tools but they pair well, and they save me from building integrations from scratch.
A note on time: two hours per week is the realistic budget for most PMs. Not twenty. We have meetings. We have stakeholders. We have actual product work. The PMs I see burn out on this are the ones who try to make vibe coding into a second job. Two evenings a week, maybe three on a heavy week, is the sustainable pattern.
Time-box ruthlessly. If a prototype is taking more than two evenings, it is not a PM project, it is an engineering project, and I either hand it off or kill it. I have killed three this year. Killing them is a feature, not a bug, of working this way. Cheap death is part of why the model works.
Now back to Omar.
The skills that actually matter
Thanks Maya.
If I were teaching a PM how to do this from scratch, I would not start with code. I would start with these four skills, in roughly this order.
Specification. Can you describe what you want with enough precision that an agent can build it? Our prompt templates collection has starter prompts for common PM projects. This is the biggest gap I see in PMs trying vibe coding for the first time. They write "build me a dashboard" and get something useless. Then they blame the tool. The skill is in writing "build me a single-page dashboard with three cards across the top, each showing a single number, with the cards labeled X, Y, and Z; below the cards a table with these five columns; the data comes from this Supabase table." That level of precision is what separates PMs who get value from this from PMs who give up.
Direction. Can you read the agent's plan before it runs and tell what is wrong? When Claude Code says "I will create a users table, a posts table, and a comments table," can you tell whether that is the right schema for what you asked? This is harder than specification. It is closer to actual product thinking, which is the thing PMs are supposed to be good at.
Acceptance criteria. Can you tell when you are done? Most PMs cannot. They keep tweaking. The vibe coded version of this problem is brutal because the agent will happily keep building forever. You have to be the one who says "this is enough, I am stopping."
Knowing when to stop. Related but harder. Most PM prototypes fail not because they were impossible but because the PM kept going past the point where the prototype was valuable. The point of a prototype is to learn something or convince someone. Once you have learned the thing or convinced the person, stop. Do not productionize it yourself. Do not fix the bugs. Do not add the seventh feature. Show it, get the reaction, and put it down.
I am still working on this last one. I built a prototype last month that I should have shown to my team after three hours and instead I kept polishing for another six. The version they saw was not meaningfully better than the three-hour version. I had wasted six hours making myself feel better.
The mistakes PMs make most often
In rough order of how often I see them.
Building production-grade things and then acting hurt when engineering won't merge them. This is the most common, and it is the most damaging to the PM-engineering relationship. Your prototype is a probe, not a product. If you walk into engineering review demanding they ship your code, you are doing it wrong. If you walk in saying "here is what I learned, what would the real version look like," you are doing it right.
Forgetting that data models matter even in prototypes. This was the engineer's whole point that Tuesday in standup. The button worked, the flow worked, the underlying data structure was wrong, and getting it wrong meant the prototype could not have scaled even if we wanted it to. PMs who learn just enough about data modeling to not make beginner mistakes here get taken much more seriously.
Trying to learn JavaScript instead of trying to learn to direct. I see PMs spending hours on freeCodeCamp when they would get 10x more value from spending those same hours practicing how to write a good prompt. The skills are not the same. Learn the right one.
Hiding the prototype from engineering instead of showing it early. I get the instinct. You feel sheepish. You think they will laugh. They mostly will not. Show them at the rough stage. They have opinions you want.
Treating the prototype as proof the feature is good, instead of as a probe to find out if it is good. A working prototype proves you can build the thing. It does not prove anyone wants it. Confusing the two is how PMs talk themselves into shipping bad ideas. For inspiration on what others have actually shipped, see our roundup of 10 real apps built with vibe coding.
What engineering actually thinks
I asked four engineer friends about this for this post. The answers were less hostile than I expected and more nuanced than the internet would suggest.
Most of them love PM prototypes. They reduce ambiguity, which is the thing engineers hate most about working with PMs. "Just show me what you mean" turns out to be the highest-leverage request engineering can make of product, and vibe coding lets product actually answer it.
The ones who hate it are usually, in their words, "the ones who feel threatened." Specifically: senior engineers whose value to the company has historically been *"I can build the thing nobody else can build." * If a PM with a laptop can build a passable version of the thing in an evening, that engineer's identity is under pressure. The hostility tracks with insecurity, not with the actual quality of the prototypes.
The friction is real, though, when PMs propose architectures that will not work at scale. "This is fine for ten users and impossible for ten thousand" is a sentence I have heard from engineers about my own prototypes, and they have always been right. The relationship gets dramatically better when the PM is the one who says "I built a probe, what would the real version look like," instead of forcing the engineer to be the one to say "actually we need to throw this out."
The shift, in one of my friends' words: "PMs used to bring me requirements I had to translate into reality. Now they bring me reality, and I get to focus on making it real-er."
I think that is right.
Where this fails for PMs
I want to be honest about this, because the boosters are not going to be.
PMs without product taste do not get better at product through vibe coding. The tools amplify whatever judgment you bring. If your judgment is bad, you will ship more bad ideas, faster. Vibe coding is not a substitute for understanding users. There is good thinking on this in Lenny's writing on PM craft, and the meta point is that craft does not arrive in your laptop.
Solo PMs at engineering-heavy companies face cultural resistance that is hard to overcome alone. If your engineering org sees PMs as project managers and not as product thinkers, you walking in with prototypes is going to be read as overstepping, no matter how diplomatic you are. Sometimes the right move is to find a different company.
Some products genuinely require deep engineering. Real-time systems. ML pipelines. High-throughput databases. Anything where the engineering is the product. You can prototype the user-facing layer of these, but the prototype tells you almost nothing about whether the actual product works. Be honest about which category you are in.
Burnout is real. PMs already work too much. Two extra evenings a week of vibe coding, on top of the day job, can quietly become four evenings a week, and then it is not leverage anymore, it is just more work. The PMs I see thriving with this are the ones who treat it as a replacement for some of their existing work, not an addition to it. I write fewer PRDs now. That is what frees the time.
Closing
The job has not changed.
The job is still: figure out what to build, convince the right people, ship it, learn from it, do it again. None of that has gone away. None of it is going to.
What has changed is the leverage you have on each of those steps. You can convince faster, because you have a working artifact. You can learn faster, because you have built the thing the users can react to. You can iterate faster, because the cost of throwing the prototype away is hours, not weeks.
For deeper background on what vibe coding is and how it works for non-developers more broadly, our what is vibe coding explainer is a good starting point. And if you want the bigger argument about how this changes the PM role itself, my colleague's piece on vibe coding as the new product management is the strongest version of that case.
I do not know how this lands a year from now. The tools are moving fast. The norms inside companies are moving slower. Some of what I have written here will look obvious in twelve months and some of it will look naive. That is fine. We are figuring it out together.
If you are a PM staring at this and wondering whether to try, my suggestion is: pick the smallest prototype you can imagine, give yourself one evening, and see what happens. The worst case is you waste three hours. The best case is you walk into a meeting next week with something that quiets the room.
Let me know how it goes. I will be in my kitchen.
