Your Next Feature Will Die in a Meeting. Unless You Do This First.

The fastest way to kill a good feature is to pitch it. Stakeholders don’t buy roadmaps; they buy working software they can touch. This prompt builds a functional “Proof of Intent” prototype that ends alignment debates before they start.

At a previous company, a feature my team had been debating for five weeks.

Two stakeholders, two completely different imaginary versions of the same product. They weren’t disagreeing with each other, they were disagreeing with two things that didn’t exist yet. Every meeting ended with “let’s align on the concept first” and nothing shipped.

Every meeting ended with “let’s align on the concept first” and nothing shipped.

I built a one-screen prototype in 12 minutes and brought it to the next meeting. The conversation shifted in under five minutes from “what should this look like?” to “how soon can we build the real version?”

Twelve minutes of building did more than five weeks of meetings ever could.

The problem is that a written spec forces stakeholders to imagine the product.

Imagination is unreliable. Two people read the same PRD and picture completely different products, then spend 45 minutes arguing about those imaginary versions while nothing ships. A working prototype forces an encounter with reality.

There is nothing to debate about an animation that either works or doesn’t. The moment stakeholders can click something, the conversation shifts from “should we?” to “how do we?” Functional evidence beats verbal explanation every time.

This prompt works because it forces three things in sequence.

First, it makes you name the stakeholder’s specific objection, not a general concern. “Will this scale?” is not the same as “I’m worried users won’t understand the multi-step flow.” Precision here is everything. Vague input produces a vague prototype that answers the wrong question.

“Will this scale?” is not the same as “I’m worried users won’t understand the multi-step flow.”

Second, it instructs the AI to design a prototype that solves that exact objection and nothing more. Most PMs overbuild demos. A single-page React app that addresses one specific doubt is more persuasive than a feature-complete prototype that raises new questions.

Third, it generates talking points grounded in the demo itself, not the concept. “Here is the flow users see” lands differently than “here is what we are planning to build.”

Role: AI Product Architect / Stakeholder Strategist.
Context: I am building a "Proof of Intent" prototype to win over a skeptical
stakeholder regarding [Insert Feature].
Task:
1. Analyze the stakeholder's primary objection [Insert Objection].
2. Design a single-page React prototype using Lovable that solves this
   specific objection.
3. Draft 3 technical "Talking Points" that anchor the demo in functional
   reality rather than aspirational theory.
Input: [Insert Objection and Feature Specs].

Open Claude or paste this directly into Lovable’s chat.

Replace [Insert Feature] with the specific feature you are trying to get approved. Replace [Insert Objection] with the exact resistance you heard in the last meeting, word for word if possible.

Take the output and build the prototype before the next meeting. Don’t schedule a follow-up to “discuss the concept further.” Schedule a demo. The prototype does the persuasion; you just run the screen share.

The checklist is simple:

✅ Identify the one specific doubt stalling the project (not the general category of concern)

✅ Build a high-fidelity prototype that addresses that single doubt, nothing else

✅ Present the working demo instead of a slide deck and move the conversation from “should we?” to “how do we?”

Most PMs spend their week preparing decks for meetings that produce no decisions.

The PM who shows up with a working prototype controls the room, not because the prototype is perfect, but because it makes the decision concrete. Nobody argues with a thing they can touch.

This prompt is the fastest path from “let me think about it” to “let’s ship it.” The Vault has more patterns like this one, built from real builds, real blockers, and real timelines.

If you want help implementing this inside your actual product review process, reach out at hello@elenacalvillo.com.

Elena | AI Product Leader Founder & Builder, Prompt-Led Product