There are two narratives ongoing for Product Managers in the industry:
PMs, UX and Engineers all three would be able to do each other’s jobs. This means that each of these roles will be expected to be horizontally skilled across both designing and building.
The other narrative is that AI will force multiple each role. This means AI will help PMs, UX and Engineers to focus on more important things, as AI takes over more repetitive tasks, bringing more productivity.
Today we focus on the second camp.
Before we get intoxicated by the magic of vibe coding, there’s a real question Product Managers need to wrestle with:
How do we use these tools without stepping on the toes of designers, engineers, and business leaders?
PMs would need to think about upgrading how they communicate, validate, and iterate, with the help of AI.
Your UX team still owns the design system.
Your engineers still own the architecture and production code.
Your business stakeholders still own the strategic bets.
What changes? You now show instead of tell.
Instead of shipping lengthy PRDs that get misread, you spin up an interactive prototype. Instead of waiting weeks for feasibility checks, you vibe a quick integration test. Instead of selling a “vision deck,” you demo something that clicks, scrolls, and actually works.
That’s the happy path of vibe coding for PMs: faster conversations, tighter alignment, fewer lost-in-translation moments.
Before you read the rest of today’s newsletter, consider reading Vibe Coding and The Illusion of Progress and AI will reveal Real Product Managers to get more context on the how AIs will change the role of Product Manager.
Understanding the PM Angle
For PMs, it’s less about the code and more about what it unlocks: collapsing the messy handoff layers between idea → design → engineering → business case.
But let’s be clear: vibe coding isn’t a substitute for discovery, research, or scalable engineering.
It’s a force multiplier for the PM’s real job — understanding needs, prioritizing what matters, and aligning teams around the why.
The Use Cases That Actually Work for PMs
Here’s where vibe coding shines for PMs, with some real-world happy/unhappy paths.
Happy Path: How you, as PM, should use these tools
Unhappy Path: A path you shouldn’t take, and lose track of actual PM role
I am also quoting a tool with each example so you can try these use cases out.
1. Rapid Concept Validation (with Lovable)
Happy Path: You vibe a quick prototype of a new flow. Stakeholders play with it, argue less about hypotheticals, and give sharper feedback.
Unhappy Path: You treat the prototype as final and forget to run it through UX for accessibility, design polish, or actual research.
Step 1: Define the Core Concept
Start by writing a clear, concise description of the feature. For example: "Create a task management interface where users can add tasks, set priorities, mark items complete, and filter by status. Include a dashboard showing completion statistics."
Step 2: Initial Prototype Generation
Input your description into Lovable. The AI will generate a working application with basic functionality. The initial version might include task creation forms, a list view, and simple filtering options.
Step 3: Iterative Refinement
Use Lovable's conversational interface to refine the prototype: "Add a priority indicator using color coding" or "Include a progress bar showing completion percentage." Each iteration builds upon the previous version.
Step 4: Stakeholder Demonstration
Present the working prototype to your cross-functional team. Unlike static mockups, stakeholders can interact with the actual functionality, leading to more concrete feedback about user experience and technical requirements.
Step 5: Documentation and Handoff
Use the prototype as a reference specification for your UX team to create the proper design system implementation and for engineering to understand the required functionality and user interactions.
2. Feasibility Checks (with Bolt)
Happy Path: You quickly see whether that “dream dashboard” even pulls data the way you think. Engineers get a head start on complexity, and business sees the cost early.
Unhappy Path: You assume your test = production reality. Spoiler: it doesn’t. Bolt is a compass, not a contract.
Step 1: Define Integration Requirements
Clearly articulate what needs to be connected: "Create a dashboard that pulls data from our CRM API, displays customer engagement metrics, and allows filtering by date range and customer segment."
Step 2: API Connection Testing
Use Bolt to create a basic application that connects to your existing APIs (using test credentials). The tool can generate code that demonstrates whether the data access patterns you envision are technically viable.
Step 3: Data Visualization Prototype
Instruct Bolt to create charts and visualizations using the actual data structure from your APIs. This reveals any data quality issues or structural challenges early in the process.
Step 4: Performance Assessment
Test the prototype with realistic data volumes to understand potential performance constraints. This information is invaluable for engineering planning and infrastructure considerations.
Step 5: Engineering Consultation
Share the working prototype with your engineering team to validate the approach and identify potential optimizations or alternative implementations.
3. User Hypothesis Testing (with v0)
Happy Path: Spin up two flows (list view vs. card view), put them in front of real users, and get directional signals.
Unhappy Path: You over-index on prototype data and skip the deep research. v0 gives you hints, not gospel.
Step 1: Hypothesis Formulation
Define specific hypotheses to test: "Users will engage more with a card-based layout versus a list view for product discovery" or "Simplified checkout flow will reduce abandonment compared to detailed step-by-step process."
Step 2: Variant Creation
Use v0 to generate multiple interface variations. For the product discovery example, create both card-based and list-based layouts with the same underlying functionality and content.
Step 3: Interactive Prototypes
Generate working prototypes for each variant that can be shared with test users. v0's React component generation makes these prototypes feel like real applications.
Step 4: User Testing Setup
Deploy the variants and set up basic analytics to track user behavior patterns. While not production-ready, these prototypes can provide meaningful insights into user preferences and interaction patterns.
Step 5: Research Integration
Share findings with your UX research team to inform more comprehensive user studies and validate assumptions before full development begins.
4. Stakeholder Alignment (with Cursor)
Happy Path: Instead of another abstract roadmap session, you demo a living scenario. Execs see the onboarding flow. Engineers see the data handling. Everyone argues from something real.
Unhappy Path: You tweak live in front of execs and suddenly scope explodes because “AI can just add that, right?”
Step 1: Audience Analysis
Identify the specific concerns and interests of your stakeholder audience. C-suite executives might focus on business metrics, while technical leaders care about implementation complexity.
Step 2: Comprehensive Prototype Development
Use Cursor to build a more sophisticated demonstration that includes multiple user personas, realistic data, and key business metrics. The tool's ability to work with complex requirements makes it suitable for executive-level presentations.
Step 3: Scenario-Based Demonstrations
Create specific user scenarios that resonate with stakeholder concerns. For executives worried about user adoption, demonstrate the onboarding flow. For technical stakeholders concerned about scalability, show data management interfaces.
Step 4: Real-time Customization
During stakeholder meetings, use Cursor's conversational interface to modify the prototype based on feedback: "Show what this would look like with our enterprise customers" or "Add a reporting dashboard for operational metrics."
Step 5: Strategic Alignment
Use the demonstration to facilitate discussions about resource allocation, timeline expectations, and strategic priorities based on concrete functionality rather than abstract concepts.
5. Workflow Automation (with Make)
Happy Path: You demo an automated reporting flow, proving time savings before asking engineers to rebuild it properly.
Unhappy Path: Teams rely on the hacky Make workflow too long, and one day it snaps under scale.
Step 1: Process Mapping
Document the current manual workflow: customer support ticket creation, data entry processes, reporting generation, or cross-platform data synchronization.
Step 2: Automation Design
Use Make's visual interface to design automated workflows that connect your existing tools. For example, automatically create support tickets from customer feedback forms, or generate weekly performance reports from multiple data sources.
Step 3: Pilot Implementation
Create working automations using Make's extensive integration library. Test with real but non-critical data to validate the process and identify potential issues.
Step 4: Impact Measurement
Track time savings, error reduction, and process consistency improvements. Document these metrics to support the business case for engineering investment in production automation.
Step 5: Scaling Strategy
Work with engineering to determine which automations should be rebuilt as custom solutions and which can continue running through Make or similar platforms.
The Collaboration Rules of the Road
If you’re going to vibe responsibly as a PM, here are the guardrails:
Set expectations: Always frame your prototypes as explorations, not solutions. You’re opening a conversation, not closing one.
Respect boundaries: A prototype ≠ accessibility. A prototype ≠ production code. A prototype ≠ research. Keep the humility.
Invite collaboration: Share with a “What am I missing?” not “Here’s the answer.”
Document debt: Call out what your prototype ignores — security, scalability, design polish, etc. These are not free; they’re just deferred.
Avoiding the Unhappy Path
Tool bloat: Pick one or two vibe coding tools and master them. Don’t try to chase them all.
Feature creep: Just because it’s easy to add a feature doesn’t mean you should. Scope still matters.
Validation debt: The biggest one. Skipping discovery because “we can just build and see” is still a trap.
Measuring If It’s Working
Don’t just vibe for the sake of vibes. Track impact:
Are decisions getting made faster?
Are stakeholders aligned with fewer cycles?
Are engineers spending less time re-explaining feasibility?
Are you exploring more ideas without burning months?
The Balanced Path Forward
Vibe coding is not about PMs becoming mini-engineers or rogue designers. It’s about reducing the friction of alignment.
It gives you a sharper language to speak with UX, engineering, and business. But like all new languages, misuse leads to misunderstandings.
The future PMs who thrive won’t be the ones vibing the most features. They’ll be the ones vibing responsibly: pairing speed with discipline, empathy, and respect for their teammates’ expertise.
Because AI may accelerate the build, but it still can’t do the hardest PM job for you: figuring out what’s worth building in the first place.