The Product Builder
How Generative AI collapsed the distance between idea and shipped product by turning product managers into builders
Something interesting is happening. The distance between “having an idea” and “shipping a product” is collapsing fast. And this changes what it means to be a product person.
For years we had this clean division of labor. PM thinks, designer designs, engineer codes. It made sense when each step was expensive and slow. You needed the specialization because the tools were hard and the iteration cycles were long.
But that world is gone now. AI tools let you prototype in minutes what used to take weeks. You can talk to an AI and get working code for ideas you just had. The bottleneck shifted from “can we build this” to “should we build this” and “what exactly should it be.”
This is creating a new type of product person. Not quite a PM in the traditional sense. Not quite an indie hacker. Something in between. Let’s call them Product Builders.
What changed?
Before, a PM’s leverage came from coordinating people. You had an idea, you convinced your leader and then designers and engineers to build it, you managed the process. Your output was limited by how many people you could coordinate and how fast they could work.
Now? A Product Builder’s leverage comes from tools and judgment. You can design the interface yourself with AI. You can code a prototype yourself with AI. You can even ship a functional MVP yourself. Your output is limited by how good your judgment is and how fast you can learn.
This is not about replacing the team. It’s about changing when you need the team. You compress the early messy part where you’re still figuring out what to build. You get further before you need to involve other people. This massively de-risk desirability and usability for new features and makes it much easier for designers and engineers to build it right.
The actual workflow
Here’s how it works in practice:
You start with strategy, but strategy now means something different. It’s not just “what should we build in the next quarter.” It’s “what can I test this week that might change what we build next quarter.” The cycle time collapsed.
You have a conversation with a user or you notice something weird in the data. You get an idea. Old world: write a spec, have meetings, wait for design, wait for eng. New world: open Claude, design a quick prototype, maybe even code a rough version yourself. The idea stays fresh because you’re not waiting weeks to see it.
You talk to users again. Instead of just showing a prototype, then they actually get a product to use either as a small MVP or feature flagged in their product. Get real feedback on something tangible, not a concept. You get real product analytics on larger experiments to take informed decisions. Iterate fast because you’re not blocked on anyone’s calendar.
When it works, when users actually want it, then you bring in the team. But now you’re bringing them a validated idea with proof, not just a concept. You scope it properly with engineers because you already built a version yourself. You understand the edge cases because you hit them. You know what’s hard because you tried it.
A Product Builder in action
Recently in my current work as a Product Manager I was in a customer call, someone mentioned they were struggling with how we organized a specific feature. They had this contrarian perspective, completely different from how we built it. The way they described it made me think, wait, what if we’re wrong and they’re right? The opportunity seemed huge if this was a real pattern.
Problem was, this wasn’t on the roadmap. No designer available. No engineering resources. Old way would be to write it up, add it to the backlog for a future discovery. But I couldn’t get it out of my head.
So I did something different that afternoon.
I exported real data from our database into a Google Sheet and opened a tool called Magic Pattern and started vibe coding. Built a React front-end where you could actually interact with the data, see it organized the way the customer described. Ugly as hell but functional. Deployed it to its own link.
The whole thing took maybe 3-4 hours total.
I scheduled a call with the customer the next day. Sent them the link. “Hey, I built something based on what you said. Can you click around and tell me if I understood you right?”
And this is where it got interesting.
The customer started using it in front of me. Real data, real interactions. Because the design was so ugly, there was nothing to distract from the core value. It worked like those old school wireframes but better, because the data was real and the functions actually worked. They could click, filter, see what happened.
Within 30 minutes I learned more than I would have from three more interview calls. The customer showed me what was needed and more valuable, what did not work at all. I had included some features thinking they mattered. They ignored them completely.
I recorded the session. Shared it with the leadership team. The customer’s reaction was clear. They got excited about features we never considered. They were confused by things we thought were obvious.
This changed our strategic direction for the next quarter. Not because I wrote a compelling strategy doc. Because leadership watched a customer use a real thing and saw the potential themselves.
What made this work
The prototype was terrible from a craft perspective. The code was messy. The design was ugly. An engineer would need to rewrite it completely for production. A designer would need to start from scratch.
But none of that mattered.
What mattered was speed and validation. I compressed what would have been a couple of weeks of back and forth into one afternoon of building and one call for validation. The ugly design actually helped because it forced everyone to focus on the core value, not the surface.
This is what AI prototypes are. Wireframes on steroids. They show the functionality without the design distraction. But unlike wireframes, they work with real data and real interactions. You learn faster because customers react to real things differently than they react to concepts.
The mental model shift
The old PM mental model was about influence. You don’t have direct authority over designers and engineers, so you influence through vision and logic and data.
The Product Builder mental model is more like specific knowledge. You’re building a unique combination of skills that’s hard to teach and hard to replace. Strategy plus design plus code plus data. Not expert level in each, but good enough to be dangerous.
This matters because specific knowledge is what makes you valuable in a world where AI can do the commodity work. Anyone can ask AI to write code now. But knowing what code to write? Understanding what users actually need? Having taste about what’s good? That’s the specific knowledge.
It’s also about ownership. When you can build things yourself, you think different about what to build. You’re not just delegating work, you’re doing the work. This changes your relationship to the problem. You feel the pain points directly. You learn faster.
What enables this?
Great tools lower the barrier. Tools such as Claude Code, Cursor, v0, Lovable, Replit etc makes this much more efficient and it can feel like the real leverage enabler. But the real enabler is mindset.
You have to be willing to learn new things. Many PMs get comfortable in their role. They know how to write specs, run meetings, manage stakeholders. Learning to vibe code, even with AI’s help, means being bad at something again. Being a beginner. That’s uncomfortable.
You also have to be okay with “good enough.” Your prototype won’t be as polished as what a designer would make. Your code won’t be as clean as what an engineer would write. But it’s good enough to learn. Good enough to get user data on! That’s the point.
The Product Builder accepts this trade off. They give up perfection in each domain to gain speed and ownership across domains.
Why this matters now
We’re seeing this pattern everywhere. Engineers are doing more design. Designers are writing code. The boundaries are blurring.
That’s changing because the leverage is too big to ignore. If you can test 10 ideas in the time it used to take to test 1, you win. If you can ship MVPs without a full team, you learn faster than companies that need consensus for every experiment.
This is especially true for new products or uncertain markets. When you don’t know what to build yet, speed of iteration matters more than polish. The Product Builder excels here because they can iterate without coordination overhead.
The tension
There’s a question you need to think about though. At what point does the Product Builder need to become a traditional PM again?
When you’re validating ideas, building prototypes, testing with early users, being full stack makes sense. But when you’re scaling, when you need production quality, when you have a team of 10 engineers, does it still make sense?
Maybe the answer is you don’t scale. You stay small, ship lots of experiments, some become real products. More indie hacker than PM. Or maybe you transition, you use your building skills to validate, then you switch to coordinating to scale.
I don’t think there’s one answer. But it’s worth thinking about what you’re optimizing for. Speed and learning? Or scale and polish?
Why this matters now
Here’s what most people miss. This is not just about individual PMs getting faster. It’s about what happens to companies that figure this out versus companies that don’t. The companies that get it are running a different operating system. They’re not arguing in meetings about whether an idea is good, they’re testing it. Their PMs bring validated prototypes, not PowerPoint decks. The decision shifts from “should we invest resources to find out?” to “here’s what we learned, should we scale it?” This creates an advantage that compounds. You test more, so you learn more, so your judgment gets better, so you know what to test next.
But here’s the contrarian part. This only works if you’re okay with being wrong a lot. I have seen this mindset-issue with corporate innovation before. Most companies say they want to “move fast” but they actually want to move fast and be right. Those are different things. The Product Builder approach means shipping ugly prototypes that go nowhere and customer calls where you completely miss the mark. That’s uncomfortable if your company culture values “being right” over “learning fast.” So the companies that win with this are not just the ones with PMs who can code. They’re the ones that redesigned their culture around rapid validation instead of consensus-driven planning.
If you want to become a Product Builder:
Start building prototypes yourself this week - Pick an idea, use Claude or Cursor to design and code a rough version. Accept it will be messy. The point is learning, not perfection.
Compress your validation cycle - Stop writing specs for everything. Get working prototypes in front of users fast, before you involve the full team. Learn from real reactions to real things.
Be willing to be a beginner - Learn to design even if you’re a PM. Learn to code even if you’re a designer. It’s uncomfortable being bad at something again, but that discomfort is where the specific knowledge comes from.
For vibe coding tools then I recommend the following:
You can check a full list of them here on PRD2Prototype