Vibe Coding and Feature Flags: The New PM Playbook for Faster Product Validation

The traditional product management playbook is changing. For years, PMs have followed the same sequence: research, write a PRD, hand it to engineering, wait for a build, then get it in front of customers. By the time feedback arrives, you've already committed significant resources to an idea that might not resonate.

That's changing—fast.

My honest, yet controversial, saying these days is simple—Prototypes before PRDs. Before you cringe, hear me out.

AI-assisted development tools have given product managers the ability to build working prototypes themselves, in hours rather than weeks. It's called vibe coding, and it's enabling PMs to create functional prototypes, test them with real customers, and arrive at engineering kick-off meetings with validated ideas and actual user feedback.

But speed without control is just chaos. The missing piece that makes this workflow production-safe is feature flags. By wrapping prototypes in flags, PMs can expose experimental features to specific customer cohorts without risking the broader user base. 

As a result, the whole company benefits from faster validation cycles, more confident product decisions, and engineering teams that spend their time hardening proven ideas rather than building speculative features.

What is vibe coding (and why should PMs care)?

Vibe coding is the practice of using AI-powered coding assistants to build software by describing what you want in natural language. Rather than writing code line by line, you tell the AI what you're trying to create—a pricing page, a checkout flow, a dashboard widget—and it generates functional code that you can run, test, and iterate on.

The term captures the intuitive, conversational nature of this approach. You're not debugging syntax errors or wrestling with package dependencies; you're vibing with an AI, refining your description until the output matches your vision. For product managers without deep technical backgrounds, this unlocks something that wasn't previously possible: the ability to build working software yourself.

Why does this matter? Because the bottleneck in product development has never been ideas—it's been the time and resources required to test them.

Research consistently shows that a significant proportion of software features go unused. Pendo/Mind the Product benchmark data shows that only 6.4% of features drive 80% of click volume for the average product, meaning almost 94% of features are untouched and ignored.

That's an enormous amount of engineering effort going into functionality that customers didn't actually want or need. Vibe coding lets PMs test whether an idea has legs before committing those resources.

You can get from idea to product in record speed, which can be genuinely transformative. What used to require weeks of engineering time—building a prototype, setting up a test environment, deploying to a staging server—can now happen in an afternoon. A PM can wake up with an idea, have a working prototype by lunch, and be watching real customers interact with it by end of day. That's not an exaggeration; it's the new reality.

The old way vs. the new way

The traditional product development cycle is linear, which means bottlenecks and blockers occur.

A PM…

1. Identifies an opportunity
2. Writes a detailed product requirements document (PRD) specifying what should be built
3. Negotiates for engineering resource
4. Waits for the feature to be built and tested
5. Gets it in front of users

Even in well-functioning teams, this cycle can take weeks or even months. By the time you have customer feedback, the market may have shifted, your assumptions may have changed, and you've sunk significant costs into something that might not resonate with actual users.

This approach made sense when building software was expensive and slow—if every prototype required skilled engineers and weeks of work, you had to be selective about what you built. The PRD existed to ensure alignment and prevent wasted effort. However, it also meant PMs were forced to make high-stakes decisions based on intuition, inward-looking data, and educated guessing rather than actual customer behaviour.

Even the best PMs made this mistake multiple times. I once spent three months championing a feature I was certain customers needed. It launched to crickets. Zero adoption. No amount of insights analysis, customer interviews, and research can equal the certainty we get from a semi-functional prototype that a customer can actually use.

The emerging model flips this sequence entirely.

Rather than validate ideas through documentation and stakeholder buy-in, PMs can validate through direct customer interaction… before engineering ever gets involved.

Here's how it works:

1. A PM has an idea for a new feature
2. Instead of writing a PRD, they spend a few hours vibe coding a working prototype—it's rough around the edges, and not production-ready by any stretch, but it's functional enough to demonstrate the concept
3. Using feature flags, they release this prototype to a small, targeted cohort of customers
4. They watch how customers interact with it, gather feedback, and iterate

Only after they've validated that the idea resonates do they bring it to engineering. But now the conversation is different. Instead of pitching a concept, they're presenting evidence: "Here's a working prototype, here's how customers are using it, here's the feedback, people like it, now let's build it properly."

This isn't replacing the PRD; it's preceding it. The PRD still matters for specifying how something should be built at production quality. But the question of what to build gets answered earlier, with real data rather than assumptions.

Why feature flags are essential to this workflow

Building a prototype quickly is only half the equation. The other half is getting it in front of real customers without blowing up your production environment. This is where feature flags become non-negotiable.

Feature flags let you deploy code to production while controlling exactly who sees it. You can release a prototype to five customers, fifty, or five hundred—it’s completely your choice. If something breaks or the feedback is terrible, you turn off the flag. No rollback, no deployment, no incident. The flag goes off and the prototype disappears.

This capability transforms what's possible for PM-led experimentation. Without feature flags, releasing an experimental prototype to production is genuinely risky. With them, it's routine.

Here are the three capabilities that matter most for this workflow:

Cohort targeting

You don't want your rough prototype going to every customer. Feature flags let you define precisely who sees what.

Maybe you target users who've expressed interest in beta features, or customers in a specific market segment, or just your internal team for initial testing.

The cohort can be as narrow or broad as you need.

Instant rollback

Things will go wrong.

A prototype might have bugs you didn't catch, or it might confuse users, or it might just not work as expected. When that happens, you need to remove it immediately—not in the next deployment cycle, but now.

Feature flags give you that kill switch.

Separation of experimental and production code

The prototype lives in your codebase but only executes when the flag is enabled. Your production users see the stable, tested version; your test cohort sees the experiment. The two don't interfere with each other.

This isn't about A/B testing in the traditional sense—you're not measuring which button colour converts better—it's about validating whether an idea is worth building at all.

The feature flag is what makes that validation safe to run in production, with real customers, without risking the experience for everyone else.

Safety and control: experimenting without risk

The natural objection to this approach is obvious: "Isn't this risky? We're putting half-baked prototypes in front of real customers?"

It's a fair concern. Prototypes built through vibe coding aren't production-quality software. They might have edge cases that break, performance issues under load, or UX rough edges that confuse users. Releasing them to your entire customer base would be irresponsible.

But that's not what we're suggesting. Prototypes were always meant to be throw-away code.

The feature flag infrastructure is specifically designed to contain the blast radius of experimentation.

This isn’t hypothetical, we practice this ourselves. We just got back from a company offsite where we ran a 1-day hackathon. The rule was simple: in order to win, the new feature must be in production and behind a feature flag. It was a great success that would have been very risky without feature flags, but all teams shipped on that day, and everyone was able to demo their work in our production environment without risk.

Start small. Really small. Release to five customers who've agreed to participate in early testing. Watch what happens, and if it works, expand to fifty. If something breaks, turn it off.

At no point does a bug in your prototype affect the majority of your users, because they never see the prototype in the first place.

The same principle drives canary releases in software engineering: expose new code to a small percentage of traffic, monitor for problems, and only expand once you've built confidence.

Feature flags let PMs apply this same discipline to product experimentation.

The control also extends to what happens when an experiment succeeds. Once you've validated that a prototype resonates, you don't just flip the flag to 100% and call it done. You hand the validated concept to engineering to build properly—with production-grade code quality, security considerations, performance optimisations, and all the things that make software reliable at scale.

The prototype was never meant to be the final product. It was meant to answer a question: is this worth building? Feature flags let you answer that question safely.

Why this benefits the PM-engineering collaboration

This shift might sound like PMs are cutting engineering out of the process, but the opposite is true.

A common frustration for engineering teams is building features that customers don't want. Every developer has stories about spending weeks on something that never got used, or building exactly what the PRD specified only to discover the PRD was wrong. These frustrations aren't anyone's fault—they're inherent in a process where validation comes last.

When PMs arrive with validated prototypes, engineering conversations become fundamentally more productive. Instead of debating whether customers will want something, you're discussing how to build something customers have already demonstrated they want. Instead of speculating about edge cases, you have real usage data showing how customers actually interact with the feature.

The nature of engineering work fundamentally changes: Engineers spend less time building speculative features that might not ship, or rebuilding things that missed the mark, and more time applying engineering excellence to proven ideas.

It also accelerates decision-making: When a PM says "customers love this prototype—here's the data," the path forward is clear; when a PM says "this prototype flopped—customers found it confusing," the decision to pivot or abandon is easier. Both outcomes are better than building something to completion before discovering whether it was right.

For this new process to work, there needs to be a shared understanding about what vibe-coded prototypes are and aren't. They're not production code and they're not meant to scale, they're experiments—and engineering's role is to take successful experiments and make them real.

I’m not encouraging low-quality code, or blindly trusting coding platforms such as Cursor and Windsurf—these developments must be treated as experimental, and may require a complete re-write to reach a truly production-grade state, but when both product and engineering realise that they now have the power to gain real feedback faster than ever before, magical things can happen.

That's not a diminished role; it's a focused one.

Flags as experimentation infra

The ability to go from idea to customer feedback in hours—rather than weeks or months—changes what's possible in product management.

Vibe coding gives PMs the power to build working prototypes themselves, while feature flags make it safe to test those prototypes with real customers in production.

The result is shorter validation cycles and more confident product decisions. You're no longer betting significant resources on educated guesses about what customers want, you're testing, learning, and iterating before those resources get committed.

This isn't theoretical. Product managers are already working this way, using AI-assisted development to prototype and feature flags to control exposure. The teams that adopt this approach gain a meaningful advantage: faster feedback, less wasted engineering effort and cost, and products that actually match what customers need.

What we’re seeing is a shift in how and what feature flags are used for—organizations are moving from “flags as safety kill switches” to “flags as experimentation infrastructure”.

The teams that figure this out will build better products. The ones that don’t will keep shipping excellent features that nobody asked for.

The ability to release confidently—to the right users, at the right time, with instant rollback when needed—is what makes rapid experimentation practical rather than reckless