Prototype Before You Spec

The power move nobody teaches you

Here's something they don't tell you in PM school: the PM who walks into a meeting with a working prototype gets more leverage, more influence, and more credibility than the PM who shows slides.

I watched this play out firsthand. Two PMs, same company, competing for a $2M feature budget. The first PM brought a 30-slide deck with detailed user research, competitive analysis, and a fully specified PRD. Impressive. It took him three weeks.

The second PM brought a 10-minute prototype. You could click through it, try it yourself, feel the friction. It took her two hours.

Guess who got the budget? Guess who got promoted six months later?

The person with the prototype.

There's something about working software that short-circuits the part of people's brains that wants to debate abstract concepts. You can't argue with a prototype. You can only experience it. And once someone experiences your idea, it becomes real to them. The outcome becomes inevitable instead of theoretical.

This is the actual job of product management in 2026: not writing specs, but rapidly converting ideas into something tangible. The spec is your old playbook. The prototype is your new superpower.

Why specs are the enemy of speed (said with kindness)

Let me be direct: PRDs are theater. Well-intentioned theater, but theater nonetheless.

Here's what happens. You spend a week writing a 40-page PRD. You nail the success metrics. You anticipate edge cases. You feel rigorous and professional. It looks good on the project tracker.

Then engineering reads the first three pages, skims page 4, and asks the same questions they would have asked anyway. Design comes back with mockups that don't match your vision because they interpreted the spec differently. Marketing wants to see it and suddenly we're in a 90-minute "spec review" that creates four new conflicting requirements.

By the time you're done clarifying, you've spent 20 hours on a document that bought you nothing except the illusion of certainty. The document is now wrong because the world changed while you were writing it. Nobody reads it again.

But worse: you've trained your team to believe that talking about building something is the same as building it. That you can design your way out of uncertainty. You can't. Uncertainty doesn't resolve until you build and test.

The spec creates false precision. It makes everyone feel like a problem is solved when really you've just written down your guesses in formal language. And then when reality doesn't match the spec, the team wastes time arguing about who misunderstood instead of adapting.

Prototyping is the antidote. A prototype is honest. It shows you exactly what works and what doesn't. It can't be misinterpreted. It can't be partially read. It forces you to make tradeoffs visible instead of hiding them in strategic ambiguity.

The best part: prototyping is faster. You'll have a working version before you could even finish section 3 of your requirements doc.

The 2-hour prototyping method

This is a system, not a suggestion. Follow it exactly once and you'll see what I mean. Then you'll adapt it to your style.

Frame the problem (15 minutes)

Before you touch any tool, answer three questions in the clearest language you can find:

1. Who has this problem? Not "users" or "the market." Be specific. "Sales reps at mid-market SaaS companies who manage 50+ accounts" beats "salespeople." Specificity matters because different people have different problems.

2. What are they trying to do? What's the job they're trying to get done? Not what you think they should do. What are they actually trying to accomplish in the moment when this problem hurts? "I need to find the top 5 accounts most likely to churn in the next quarter so I can proactively reach out" beats "improve retention."

3. How will we know if we solved it? What changes if this works? Is it faster? Cheaper? Less stressful? "A sales rep can identify churn-risk accounts in under 5 minutes instead of 45 minutes of manual analysis" beats "better retention" because it's falsifiable.

Write your answers down in three sentences total. One sentence per question. If you need more than three sentences, you don't understand the problem yet. Keep going until you can say it simply. This is the hardest part and also the most important part.

Show these three sentences to someone. Anyone. If they look confused, you're not clear. Revise. This clarity compounds through the rest of the process.

Build the core interaction (30–90 minutes)

Now open Claude Code, Cursor, or Claude.ai - your choice based on what you're building. (For web-based prototypes, start with Claude in the web interface. For more complex things, use Cursor.)

Paste in your three sentences. Then describe what you want to build with the same clarity.

Don't describe the interface. Describe the user experience. The difference matters.

Bad: "Build a dashboard with charts showing account health metrics and a filter for churn risk."

Good: "A user opens their account list, clicks an account name, and instantly sees a red/yellow/green churn risk score. They can drill into the factors driving that score (payment delays, declining usage, etc.) and see which accounts have dropped off the most in the last 30 days."

The second version tells the AI what moment of value you're trying to create. It focuses on experience, not implementation. The AI will figure out the how.

Tips that actually work:

• Use real scenarios. "A sales rep named Alex has 67 accounts. She wants to know which 5 are most likely to fire her this quarter." Real names, real numbers, real friction. This creates better prototypes than abstract descriptions.
• Describe the happy path first. What happens when everything goes right? Build that. Ignore error states, edge cases, and nice-to-haves. You can add those in iteration 2.
• Tell the AI to use real data if you have it. Fake data creates fake confidence. If you can grab a CSV of actual customer accounts, accounts health metrics, or whatever real data exists, feed it into the prototype. Real data surfaces real problems faster.
• Iterate conversationally. "The chart is good but I need it to show percentages too" is better than starting over. Each tiny improvement takes 30 seconds. Have a conversation with your tool. That conversation is where the actual design work happens.
• Don't polish. This is not a design exercise. The prototype's job is to answer a question, not look beautiful. Ugly works. Shipped ugly beats unpublished perfect. If your prototype makes someone uncomfortable because the design is rough, great. That's the point. The question isn't "do people like how this looks?" It's "does this solve the problem?"
• Deploy it somewhere real people can access it. A prototype on your laptop is just a demo. Host it on Replit, Vercel, a simple Google Sheet, a Figma prototype, whatever. Make it live. Send them a link. Watch what happens when they don't have you sitting next to them explaining.

The whole phase should take 30 to 90 minutes depending on complexity. A simple interactive prototype: 30 minutes. Something with data and multiple screens: 60-90 minutes.

Test immediately (30 minutes)

Here's the non-negotiable rule: watch someone use it without explaining anything.

Find a customer if you can. If you can't, find someone on your team who wasn't involved in building it. Show them the live prototype and ask them one question: "What would you do first?"

Then step back. Watch them click. Watch them hesitate. Watch them look for something that doesn't exist. Watch where they get confused.

Don't help. Don't explain. Don't defend. Just watch.

You will learn more in 30 minutes of observation than in 30 days of meetings and surveys combined. You'll see what people actually do vs. what they say they'd do. You'll spot the moment when your idea doesn't work because they'll look lost. You'll see the accidental feature nobody planned for because someone will instinctively try it.

Take notes. Lots of notes. Not on what they say but on what they do. Did they understand the core idea immediately or did it take explanation? Did they find the churn risk score or did they look for it in the wrong place? Did they try to do something the prototype doesn't support?

That's your raw data. That's your market feedback in its purest form.

Decide: kill or iterate (15 minutes)

After you've tested, you have exactly two decisions:

Option 1: Kill it. The core idea doesn't work. Users don't understand it, or they understand it and don't want it, or something more fundamental is broken. That's okay. You just spent 2 hours instead of 2 months finding out. Celebrate this. A killed prototype saves 10 weeks of engineering time. Kill often.

Option 2: Iterate. The idea has legs but needs refinement. Users got the core concept but needed clearer labeling. Or they wanted it but with one key feature you didn't build. Go back to Step 2. Have the AI add that feature. Build iteration 2. Test iteration 2. Decide again.

Repeat three times maximum. By the third iteration, you should know if this is real or not. If you're still uncertain after three cycles, the problem isn't the prototype. The problem is you haven't identified who the real user is or what their real problem is. Go back and talk to more customers.

Vibe coding is not coding

Let me be clear about what "vibe coding" actually means. It's not that you become a developer. It's that you become fluent in the language of building.

You learn to translate a feeling, a hunch, a market insight, into working software without the traditional handoff ceremony. You stop writing specs to engineers. You stop losing meaning in translation. You build a direct pipeline from intuition to artifact.

This requires exactly four skills:

1. Describe what you want in clear English. Not pseudo-technical language. Not bulleted lists of features. Story language. "When Sarah opens the app, she sees her 10 riskiest accounts ranked by likelihood to churn." If you can describe it clearly, Claude can build it.

2. Iterate conversationally. This is easier than you think. "Can you make that interactive so I can click to see more details?" That's it. That's the whole skill. You can improve anything in seconds by asking questions.

3. Know when something works. You don't need to know code to feel when a prototype solves the problem. Your intuition gets better every time you build.

4. Deploy it. Use Vercel for React, Replit for anything, Google Sheets if it's data. You need people to be able to click a link and experience your idea. That's the whole game.

You're not becoming an engineer. You're becoming a builder. There's a massive difference.

The barrier to entry here is totally artificial. You're not writing production code. You're not managing database architecture. You're describing ideas and refining them through conversation. If you can write an email clearly, you can do this.

When prototyping works (and when it doesn't)

Prototype when:

• You're testing whether an idea resonates with real customers. Before you build for real, see if the real problem is what you think it is.
• You need to align a divided team on vision. Nothing ends a debate faster than a working prototype. People who disagree about abstract concepts agree when they can interact with something.
• You're validating demand before investing engineering time. "Would you use this?" is theoretical. A prototype with a signup link is data.
• You're exploring a UX concept and you're unsure about the optimal flow. Users will show you the right flow instantly.
• You need to demonstrate technical feasibility. Can it be done? Prototype it and answer the question.
• You're onboarding a new engineer and need them to understand the vision. A prototype is faster than any document.

Don't prototype when:

• You already know exactly what to build and engineering is waiting on you. The prototype phase is done. Time to spec and build the real thing.
• The problem is purely backend/infrastructure. You can't prototype database architecture or API design with a user-facing prototype. (Though you might prototype the backend separately with different tools.)
• You're optimizing an existing feature for speed or efficiency. If the feature already exists and works, use analytics and user testing instead. Prototyping a 10% faster version of something people already use is the wrong move.
• You're building something where mistakes are expensive. Medical devices, financial systems, infrastructure - these need rigorous engineering from the start. Prototyping doesn't replace that.

The continuous discovery thread

This is the piece most PMs miss: prototyping doesn't exist in isolation. It connects directly to your discovery practice.

You talk to customers and learn that churn is their #1 problem. You prototype a churn-prediction feature. They love the prototype. You ask them, "If we shipped this, what would you do differently?" They tell you exactly. That answer informs the spec.

Then you ship it. Customers use it. Their usage pattern is slightly different from what they said they'd do. You iterate. That iteration teaches you about the next problem. You prototype that.

This is the discovery loop: Customer insight → Prototype → Test → Learn → Next insight → Prototype again.

The teams that win are the teams that move through this loop fastest. They're not the teams with the most rigorous specs. They're the teams that build, learn, and adapt continuously. Prototyping is how you move fast through that loop.

The organizational friction point (and how to move through it)

Here's where it gets hard: you work in an organization that loves specs. Maybe it's a mature company. Maybe it's an organization where people have spent 15 years getting really good at writing requirements documents. Maybe your executives think a 40-page PRD means you're doing serious work.

They will resist prototyping. You'll prototype something amazing. You'll show it around. And someone will ask, "Where's the spec?" Or they'll say, "This is interesting but we need a proper requirements document before engineering can start."

This is where most PMs back down. They shouldn't.

Here's your move: don't fight the culture directly. Leapfrog it with results. Prototype. Test with real customers. Get data. Then write a short spec that reflects what you learned from the prototype. You're not replacing the spec. You're replacing the three weeks of speculation with three hours of learning first.

The spec gets better because it's based on reality instead of guesses. The team gets more excited because they saw the prototype work. Engineering starts faster because they understand the problem, not just the requirements.

One successful prototype-first cycle changes the conversation. By the third one, your organization won't ask for specs upfront anymore. They'll ask for prototypes.

How this connects to your career

Here's the real reason you should care about this beyond the cycle time savings:

The PMs who get noticed, who get promoted, who become go-to people at their companies - they're the ones who make things real. Not on paper. Actually real.

They walk into a room and say, "I built something. Let me show you." That's a different energy than "I wrote a spec. Here's what I think we should do." One is theory. One is evidence.

People follow the PMs with evidence. People argue with the PMs with theories.

When you start building before speccing, you move faster than everyone else. You accumulate data faster. You learn faster. You look like you have better instincts because you have more data to back them up. You become the PM other teams want to work with because you actually know what you're asking for, not just what you wrote down.

This compounds. The PM who shipped five prototypes in the last three months has more credibility, more seniority, more career momentum than the PM who wrote five PRDs. That's not fair. That's just how influence works.

Your first prototype this week

You should pick something small, something you're genuinely unsure about, and something that, if it works, matters to your business.

Here are some ideas depending on your context:

• If you're at a B2B SaaS company: Pick the #1 problem your most frustrated customer segment complains about. You know it's real. You don't know if a specific solution would work. Prototype it.
• If you're at a marketplace: Pick a friction point you suspect is losing transactions (hard to find sellers, hard to coordinate, shipping complexity). Prototype a fix.
• If you're building internal tools: Pick a report someone is constantly asking for and prototype a self-serve version so they can build it themselves.
• If you're at an early-stage startup: Pick the feature you're least confident about. The one where you've had the most customer conversations and still aren't sure what to build. Prototype that.

Block two hours tomorrow. Or this Friday. Tell no one. Open Claude. Describe what you want to build. Deploy it. Send the link to a customer or a colleague.

Watch what happens.

I promise you: you'll learn something in two hours that a month of meetings wouldn't have taught you. And you'll feel different about your work. You'll feel like a builder instead of a document writer.

That difference is everything.