"If you're a PM who likes building, this is the best moment of your career. If you're a PM who likes managing PMs, it's a harder conversation." - Elena Avramenko, AI builder and founder of Modaal.dev
Elena Avramenko is an AI educator, founder of Modaal.dev, and host of the Vibe Jam podcast. She has run 25+ vibecoding workshops with over 1,000 participants across Europe.
What vibecoding is
Vibecoding is the skill of translating ideas into software via AI-driven execution loops. More practically: you describe the outcome you want, steer the AI through rapid iterations, and keep going until the result matches your intent.
Two things most vibecoding content skips over. First, the reality check: you don't need to be a developer to vibecode, but you need to learn how software behaves, what's easy, what breaks, and why.
Second, the mindset: think of yourself as the director rather than the actor. You describe what success looks like, test against that vision, and iterate until it is right. For product managers, both should sound familiar: defining outcomes, testing against a vision, iterating on feedback.
Where it works and who it is for
"Most of the value from vibecoding right now is being extracted by non-developers, because developers could already build. Non-developers had a roadblock, and vibecoding removed it." - Elena Avramenko, AI builder and founder of Modaal.dev
The most common use cases Elena sees across workshops are internal dashboards, productivity apps, landing pages, and early SaaS prototypes. They are usually practical and unglamorous, solving a specific problem rather than building a platform.
There are three ways to start, depending on what you have:
- Spec driven means starting with written requirements and letting the AI generate from scratch. It’s best when you know what you want but have no visual assets yet.
- Design driven means providing wireframes, screenshots, or mockups and asking the AI to match them. Most useful when the visual direction is already decided.
- Data driven means defining the schema and providing sample data first, which gives the AI structure so the UI and logic stay coherent.
Most beginners start spec driven because it feels natural, but data driven is often faster and produces more coherent results because it establishes the foundation first.
Product managers naturally gravitate toward spec driven, and it is a solid starting point. Writing out what you want before touching a tool is what PMs do every week, and that habit translates directly into better prompts.
We have been exploring this angle in Is AI killing or reinventing product management?, the PMs who do well in this shift are the ones who bring their existing craft to it.
The vibecoding loop
The core loop is simple: plan, prompt, test, fix, repeat. Most people underinvest in the first step.
"Planning isn't really planning, it's validation. The first question is: am I willing to spend two to three months of my life building this? If yes, give yourself a week or two before you commit." - Elena Avramenko, AI builder and founder of Modaal.dev
In that week, run two tracks in parallel: talking to people in your target audience, and building the cheapest possible artefact (a landing page, a Figma flow) to put in front of them. The goal is to disprove your own hypothesis before investing real time. The PRD comes after that week, built from real observations rather than assumptions.
"The most common mistake is that people skip even the basic validation week and write the PRD from imagination." - Elena Avramenko, AI builder and founder of Modaal.dev
This is what we share in Before you build: problem clarity before solution investment is good product practice in any context. Vibecoding makes skipping it more tempting because a working prototype can appear in hours, creating the illusion that the validation step was already passed.
Three real cases
Elena shared three real projects in the webinar, chosen because they differ in goal, background, and outcome.
Deb Gallo, VP of Talent Development at Mews, faced a recurring calibration problem: her team was going into performance review meetings with 30 to 50 reviews and no efficient way to assess quality or spot patterns. She used ChatGPT and Claude to structure the idea, then built a dashboard in Lovable that turned Workday exports into review quality scores and org-wide patterns. A few weeks later, her internal engineering team decided to implement what she had built at company level.
What made the difference was Deb's clarity about what she was building: a demonstration, not a product. The engineering team adopted it because the argument was compelling, built from real data and a clear problem statement.
Dheeraj Pershad, a product manager at Booking.com, built a LinkedIn job application tracker as a side project. The problem was personal: multiple applications across platforms with different CV versions, no way to track stages or follow-ups. He started with ChatGPT, prototyped in Lovable, and added n8n for automation. The product now earns him over a thousand euros per month in subscriptions, and he is preparing to bring in a developer to make it more secure and scalable.
Felix, Head of Design at GetSafe, wanted to prove he could ship a native iOS app without a developer. He built Steel, a minimal daily reflection app, using Claude Code to generate and iterate the Xcode project screen by screen. He never opened Figma. As a designer, he prompted differently from how a PM would, he knew exactly how to describe visual outcomes to get the result he wanted. The app shipped to the App Store.
"If you build something for profit or for many users, at a certain point you need a developer. The marketing message that you can build without one is just marketing." - Elena Avramenko, AI builder and founder of Modaal.dev
How to plan before you build
Before writing a single prompt, Elena uses what she calls the MVP Triangle: one audience, one pain, one action.
The MVP Triangle is the scoping tool to use before writing a single prompt. The rule: one audience, one pain, one action. The narrower the scope, the smaller the gap between where you are and where you need to be.
Elena’s build workflow for web apps runs in four stages:
- build a functioning but visually rough prototype first,
- bring in a designer or a tool like Stitch to improve it,
- validate with real users,
- then check with a developer before release.
"Build ugly first" is deliberate: the goal at stage one is to confirm the product works as imagined, not to look good.
On whether you still need a developer: "You don't need a developer if you know how to prompt like a developer."
PMs who have spent years writing clear acceptance criteria are already practising that kind of precision. The skill is the same, just with a new context.
What the prototype is for
A prototype is a presentation you can click through. It replaces the slide deck, not the codebase.
Most vibecoded prototypes are throwaway artefacts that exist to tell a specific story or earn internal support. The engineering team almost never picks them up as-is, and they should not.
The question worth answering before building: are you building to demonstrate, or building to ship? The answer changes what you build, how rough it can be, and what success looks like when you are done.
Who ships and who does not
"It's not technical tolerance, not clarity of idea, not background. It's intent. How badly does this person want the thing to become a real product?" - Elena Avramenko, AI builder and founder of Modaal.dev
After more than 25 workshops, the pattern is consistent. The ones who ship are not smarter or more technical, they just have a reason that's strong enough to keep building until the end.
Stopping a project is not failure either: people should be allowed to try something, drop it, and come back six months later when something has shifted and the intent is higher. For PMs considering vibecoding: start with a problem you personally experience. A real friction in your daily work or team's workflow. Starting there, the intent tends to take care of itself.
When not to vibecode
Vibecoding is a poor fit for anything touching financial or health compliance regulations, applications with heavy security requirements, complex permission systems across multiple user types, or any public product that launches with payments and authentication from day one. The pattern is consistent: start private. Enormous value can be shipped to yourself or a small trusted group before the hard constraints need to be tackled.
GDPR deserves a specific mention. A web application built in Lovable and deployed publicly does not become compliant automatically. The PM who built it is responsible for the data it collects, regardless of which tool generated the code.
What this means for the PM role
"In two years, most product managers will be solo builders. They'll spend their day in Claude Code or Cursor, shipping 70 to 80 percent of the product themselves. An engineer steps in for the last mile. And I think the Group PM role mostly disappears. When every PM is an individual contributor who can ship, the coordination layer thins out." - Elena Avramenko, AI builder and founder of Modaal.dev
Whether the timeline is right or not, the direction is already visible. As we explored in Scaling product organisations in 2025, the question of what product leadership looks like is changing faster than most organisations are tracking. AI moved the work from typing to thinking and steering. For product managers that is an opportunity if they bring their discipline into the tools, not just their enthusiasm.
Want to go deeper? Is AI killing or reinventing product management? · The PM guide to NotebookLM in product discovery · Before you build
