The relationship between product managers (PMs) and engineers is due for an upgrade.
The division between these personas is responsible for a healthy, if laborious, collaboration when envisioning and building new products. A PM generates the vision; engineers translate it into an architectural approach, raising the technical questions that sharpen it along the way. This back-and-forth eventually produces tight alignment, a solid PRD, and functional code.
Many PMs have correctly hypothesized that there’s a lot of time to be saved on the way from vision to prototype. I know firsthand that they’re right, and I also know that PMs can go even further in their AI-fueled pursuit of a more efficient collaboration with engineering.
Yes, Claude can write a PRD more quickly than you can. On the engineering side, Claude can also read a PRD and point out areas most in need of critical feedback. Many PMs are already using Claude to write, read, and debate product requirements (if you’re not, you should be). My contention is that, in addition to this, PMs should be using Claude to build a strawman spike, an elemental prototype, of the product itself.
Why Vibe-Code A Prototype?
Critically: The prototype is a conversation starter, not an architecture decision. There are three main reasons I think this will expedite the PM-engineering collaboration:
1. Fidelity Of Communication
PRDs are incredibly valuable representations of the PM-engineering collaboration. Their key limitation is in the realm of visual communication: A lot is lost in translation when you translate a conceptual vision into and out of language.
The idea is not to throw out the PRD, but to replace its visual communication layer with a prototype. A picture is worth 1,000 words; prototypes likewise. They more losslessly translate what the PM has in her head and provide a better basis for iteration than ideas expressed verbally.
2. Sheer Velocity
The other reason prototyping is a good idea is because it increases the velocity of the collaboration. When engineers only have verbal ideas to work with, they have to translate those words into an abstract product and then envision the issues with that abstraction.
On the other hand, a working prototype is an actual product using actual code. It will be imperfect by definition; this is good, as it gives engineers concrete areas to critique, making it easier to both find issues and communicate them to their PMs.
PMs and engineers are not the only ones who learn in this process. Their respective agents learn as well, cataloging common errors and learning to avoid them in the future. The more integrated Claude is in this process, the more the efficiency benefits will compound over time.
3. Proof Of Concept
The third reason — and this one comes directly from one of CloudZero’s principal engineers, Matt Yellen — is that working prototypes prove the fundamental viability of a new idea.
“When PMs come to me and suggest an idea without a prototype, there are some fundamental issues that can get missed,” Matt said. “But with a prototype, the PM can do those first few steps of research that I’d otherwise have to do, and I can focus on some of the more difficult aspects of building out the concept.”
Does he think adding prototypes to the design process speeds things up?
“I do. Of course we’re not going to use the prototype in the final design. But it doesn’t matter if the prototype works in a suboptimal way; if it works at all, we know it’s possible, and we can iterate without worrying that we’re wasting our time.”
Research Report
FinOps In The AI Era: A Critical Recalibration
What 475 executives told us about AI and cloud efficiency.
A Prototype’s Worth 1,000 Minutes (Or So)
The wrong way to frame this: “I’m going to vibe-code a product that engineering can tweak to perfection.” A poorly framed prototype can introduce tech debt and pressure engineers to preserve bad assumptions. Engineers know this, and need to know that you’re aware of and trying to avoid it.
The right way to frame this: “I’m going to vibe-code something that clearly depicts my vision and that engineering can use as a strawman.” It’s critical that you frame the prototype not as a firm technical basis for the product, but as an accelerant for engineering creativity.
We’ve already seen this process work at CloudZero. One of our PMs was recently envisioning a telemetry collector that would let CloudZero ingest all usage data from Claude Code to help with AI cost allocation and unit economics analysis. This required writing net-new software.
The PM wrote a set of requirements for a collector and built a prototype using Claude. He brought both the prototype and the design.md file to the engineering team for review. The time it would have taken to align over the PM’s vision instead got spent on engineers’ architect-level questions — e.g.: “How can I make this solution more performant?” and, “How can I integrate it with our underlying billing system?” — which accelerated the development of the collector, which is now up and running in CloudZero.
If you’re a PM who’s not at a place where this idea at least seems plausible, it’s a good sign that you need to catch up. Make it clear that your goal isn’t to generate code that will wind up in the final product, but to more clearly express your vision and accelerate the iterative collaboration with engineers. Encourage engineers to scrap the prototype if that’s what they believe is called for. If a picture’s worth 1,000 words, a prototype’s worth a precious few hours.
FinOps In The AI Era: A Critical Recalibration
What 475 executives told us about AI and cloud efficiency.
