Why I Prototype as a Product Manager

I've always used prototypes in my practice for all kinds of reasons: to communicate, explore ideas, elicit requirements, and more. My prototyping menu includes everything from manual, analog, and low- or no-tech right up through high-fidelity functioning and styled prototypes. Selecting and using appropriate methods fluently is central to how I work as a PM. (And now thanks to AI I can do this faster, better, easier, and more independently. I’m adding AI to my “menu.”)

Some of the reasons below deserve a little more discussion. For today, I’ll just offer this list. These are all things I need to as a PM. Prototyping of all kinds helps me do it.

Here’s the list:

Operational independence aka PM self-sufficiency. Clarify my own thinking. Record an idea. Communicate more effectively. Talk with someone about concrete examples. Elicit requirements by getting reactions to the prototype. Validate technical feasibility early. Get early input (pre-review) from auditors or legal. Get new team members caught up. Seek funding. Build stakeholder alignment. Shift decisions left. Resolve uncertainty. Get market feedback. Get user feedback. Help someone understand what I’m talking about – something I’ve learned, a vision, or an idea. Share an idea for discussion. Bring a concrete example to the table so we can talk about it constructively. Get input from designers and developers that might affect scope or identify trade-offs. Learn. Speed or enable discovery. To socialize a concept. Make decisions more easily. Use for an MVP. Share with customer success team and tech writers for training materials, in-app help, on-boarding/feature tours, and other documentation. Preview new functionality for Support and Sales Create placeholder or temporary visual assets for product marketing. Explore alternatives. Work out different ways to achieve the same user goal. ?