There is a distinction I have come to think of as the most important one in product management: the difference between a PM who describes products and a PM who builds them.
Both types write PRDs. Both types run user research. Both types manage roadmaps and stakeholders and sprint planning. But they have fundamentally different relationships with the products they work on.
The PM who describes products works through language. They articulate the problem, define the requirements, specify the behavior. They are good at this. They are precise and thorough and they produce documentation that engineers can work from.
The PM who builds works through prototypes. They articulate the problem, then immediately try to build something that solves it: not to ship, but to learn. The prototype is not the product. It is the question.
What Building Teaches You That Describing Does Not
When you describe a product, you work with abstractions. "The user should be able to filter by category." "The system should display results in real time." "The interface should be intuitive."
These abstractions feel precise. But they are not. "Filter by category" does not tell you how many categories there are, how they are organized, whether they are mutually exclusive, or what happens when a user selects multiple categories. "Real time" does not tell you what latency is acceptable, what happens when the data source is slow, or how the interface communicates loading state.
When you build a prototype, you have to answer those questions. Not in the abstract, but in the concrete. You have to decide how many categories, how they are organized, what the interaction looks like. And in making those decisions, you discover the questions you did not know you had.
That discovery is the value of prototyping. Not the prototype itself: the questions it surfaces.
The Five Products as Prototypes
When I built NatureFirst, Anertia, C-4 Command, NexusStream, and Talox, I was not trying to build shippable products. I was trying to answer questions.
NatureFirst answered: "Is AI-powered plant and animal identification delightful enough to create a habit?" The answer was: yes, for casual nature enthusiasts; not quite, for serious naturalists who already have better tools.
Anertia answered: "Will people share more honestly if the incentive structure rewards resonance over engagement?" The answer was: yes, but the articulation gap makes it hard to grow organically.
C-4 Command answered: "Can a scoring model built on life event signals meaningfully improve dealer marketing ROI?" The answer was: yes, but only if the data infrastructure is clean enough to trust the signals.
NexusStream answered: "Can a data lake architecture solve the PromoStandards integration ceiling?" The answer was: yes, but the schema design is harder than the pipeline.
Talox answered: "Can a SaaS platform for heavy equipment shops create enough value to justify a subscription?" The answer was: yes, if the workflow automation is deep enough to replace manual processes.
Each of those answers is more valuable than any PRD I could have written. Because they are based on evidence, not speculation.
How to Build as a PM
You do not need to be an engineer to build prototypes. You need to be willing to work with the tools that exist: no-code platforms, AI-assisted development, rapid prototyping tools: and to accept that the prototype will be imperfect.
The imperfection is fine. The prototype is not the product. It is the question. And a rough question is better than a polished description that does not surface the hard parts.
The habit to build is: when you have a product hypothesis, do not write a document about it. Build the minimum thing that tests it. Then look at what you built and ask: what did I learn that I did not know before I started?
That question: what did I learn?: is the whole point. And the answer is always more interesting than the prototype.
