I’ve learned this the hard way. Great ideas don’t build great products. Action does.
Early in my career, I worked on a project where we spent months planning. Countless meetings. Detailed specs. Beautiful workflows. Everything looked perfect… until we launched. And users? They didn’t care for it. That moment stung. I realized assumptions, no matter how carefully we make them, are still just guesses. What really moves the needle is experimentation. Nothing beats the clarity that comes from putting something in front of users fast.
Prototyping Isn’t Just for Designers
When people hear “prototype,” they often picture polished Figma screens or glossy design mockups. But as a PM, I see prototypes differently. They’re decision-making tools.
It doesn’t matter if it’s a clickable mockup, a scrappy Wizard-of-Oz demo, or even a paper sketch shown to five users. Each one gives you a chance to learn. To see what works, what falls flat, and what users actually want before a single line of code is written.
Take one project from our app as an example. We wanted to build a personalized recommendation engine. Instead of jumping straight into development, we mocked up a simple prototype with sample recommendations. Then we sat back and watched.
Users weren’t interested in having more options. They wanted better ones. Contextual. Relevant. That one experiment saved weeks of engineering time and gave us confidence in what we were building.
Rapid Experiments = Confident Decisions
In building products, while speed matters, so does feeling confident in our decisions. Prototyping allows us to test our hypotheses quickly. Testing our assumptions with rapid experimentation reduces uncertainty, reduces risk, and leads to informed product decisions.
In another project, we tested three different onboarding flows using a clickable prototype. In just one week, we discovered a version that improved retention by 25%. Imagine if we had learned that only after launch. That’s the cost of skipping experimentation and the power of testing early.
How Polished Should a Prototype Be?
A question I hear all the time: “How detailed does a prototype need to be?”
Here’s my take. It depends on what you’re trying to learn.
If you’re exploring ideas, go low-fidelity. Sketch it. Wireframe it. Click through it. Move fast. If you’re validating a specific flow or UI detail, then sure, invest in higher fidelity. As PMs, our job is to find that balance between speed and depth. Enough polish to test the right thing. No more.
Building a Culture of Experimentation
Prototyping isn’t about a tool. It’s a mindset.
Teams that experiment often learn faster. They adapt. They stay curious. My role as a PM isn’t just to build products. It’s to build that culture. I push my team to share rough ideas early, to test before they’re “ready,” and to see mistakes as data, not failures. Every prototype starts a conversation and brings us one step closer to something users will truly love.
Closing Thoughts
The best products don’t come from endless planning or top-down decisions. They evolve through learning, testing, and listening.
A prototype is not just a design artifact. It’s your shortcut to truth. It’s a decision-making tool. Test early, learn fast, and let real user insights guide your next move.