Leveraging AI-driven exploration to build stronger, clearer product specifications

It can be tempting to think our job as Product Managers is to provide the team with absolute certainty. We want the “perfect” plan before we share it. But if you’ve ever felt like a blank page was staring back at you, you know that absolute clarity is often the enemy of a great idea.

I recently ran a workshop called “Writing Clear Requirements for Humans and AI” that explored a different path: using “Vibe Coding” (rapid prototyping) not to build a final product, but to explore the messy, conceptual space where the best ideas live.

Here is how you can use three specific Gemini Gems to move from a vague “vibe” to a battle-tested requirement.

1. Embrace the “Just Enough Confusion”

In a recent post, I wrote about how creativity requires just enough confusion to actually work. We need to be a little surprised to find something new.

Vibe coding for PMs is exactly that. It isn’t about becoming an engineer; it’s about making your thinking much stronger earlier in the process. It’s about “rubber ducking” your decisions, externalizing your thinking so you can look at it in a more objective way, with a machine before you bring it to your team.

Instead of staring at a template, start with the Spec Brief Coach. This Gem acts like a consultant, interviewing you to extract the “what” and “why” of your project.

• Step-by-Step: It guides you through sections like Goals, Critical User Journeys (CUJs), and “Moments That Matter” — those key points of high emotion where the experience is won or lost.
• Fill the Gaps: If you’re stuck, it can even suggest content to help spark your thinking.
• The Artifact: You end up with a structured markdown spec that serves as the “context” for everything else you do.

2. The Power of the “Bad” Idea

We usually try to hide our bad ideas. But in the exploration phase, a “bad” idea is a gift because it helps you define what is actually good.

The Spec Variation Tool takes your initial spec and generates four different ways to realize it to open the aperture of what you are considering.

• Variation Axes: It tests different assumptions by varying factors like automation levels or interaction paradigms.
• The Provocative Spec: One of these is intentionally a “provocative” or “bad” version designed to highlight anti-patterns and what not to do.
• Learning Outcomes: By quickly prototyping these in tools like Google AI Studio, you can see where a concept falls apart. This helps broaden the aperture of exploration rather than just meandering through a single conversation.

3. Stress-Testing with a “Rude Engineer”

You don’t want the first person to find a flaw in your logic to be your VP during a review. You want to find it yourself, in the privacy of your own AI chat.

The Viewpoint Simulator pressure-tests your spec from multiple, highly biased perspectives.

• The Panel: It simulates voices like a Product Designer, a Privacy Expert, and even a “Rude Senior Engineer”.
• The Benefit: The “Rude Engineer” is blunt and skeptical about ambiguity or over-engineering. Because it’s a machine, the feedback isn’t personal. It’s just a tool to help you find your own blind spots.

The Future: From Static Boards to “Living” Gems

One of the most exciting shifts I’ve been thinking about is the change in how we workshop. We’ve all seen Miro boards full of sticky notes that never get looked at again.

I believe every Miro should be a Gem. The future of workshopping is a system that collects and keeps distributed context up to date. This allows us to distribute context not only about how to do the workshop later but notes from the workshop itself can become distributed context to be used when needed. Almost like a workbench to create future docs based on everything discussed so far.

Instead of a static summary, we need a system that creates constantly updated drafts or “views” for different stakeholders, whether that’s for engineering, design, or legal review. This system of drafts is always in flux as the context is updated, we learn new things, and we make hard decisions.

Conclusion: Taking it Back to the Team

Prototypes and specs are both necessary conversation pieces. The prototype gives the “vibe,” but the spec captures the complexity and nuance that a prototype alone cannot.

When you take these artifacts back to your team, here are the next steps to keep in mind:

• Set Clear Expectations: Make it crystal clear that these prototypes are tests to aid in decisions, not the final product to be built.
• Use Tools Live: Try using these Gems live in meetings. Hearing how an engineer or designer interprets the AI’s feedback can spark valuable discussions.
• Don’t Replace, Collaborate: These tools aren’t meant to replace designers or engineers; they are meant to spark discussion. Use them to say, “Here is what I care about; here is some stuff to look at if it’s helpful”.
• Keep a Decision Log: Document what you decided not to do. This path of exploration helps others understand exactly how you arrived at your final direction.
• Help Write Agent Specs: PMs can better integrate into the development process by helping write the specs that AI agents will use to do work.

Next time you’re starting something new, don’t aim for immediate clarity. Use these Gems to find that “just enough confusion” that leads to a breakthrough.

This article was crafted by the author, with help from Gemini, which drew from the author’s engaging workshop transcript and related materials.

How PMs can vibe code to build stronger requirements was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.