There is a specific kind of meeting I have stopped attending: the one where four people argue about how a feature should behave, and nobody in the room has used it, because it does not exist yet.
The argument is unresolvable by design. Everyone is describing a different imaginary product, and the person with the strongest opinion usually wins. That is not a decision process. It is a debating society.
The cost of specifying
A written spec is a promise that everyone reading it is imagining the same thing. In my experience that promise almost never holds. Engineers read constraints, designers read intent, business stakeholders read outcomes, and each of them fills the gaps with something reasonable and different.
The spec is not useless — it is just the wrong tool for the earliest question, which is usually not how should this work but is this worth working on at all.
What changed
Building a rough, working version of an idea used to be expensive enough that a product manager could not justify doing it themselves. That has genuinely changed. A single HTML file with some JavaScript, written with AI alongside, gets me to something clickable in an afternoon. Not production code — a prototype whose only job is to be wrong in front of a real person.
I made a video walking through exactly this, because it is the part of the job I would most like to hand to people who do not consider themselves developers.
Where the discipline goes
The obvious objection is that this produces a lot of throwaway software of poor quality. It does, and that is fine — but only if you are ruthless about which corners you cut.
The corners I cut in a prototype:
- Error handling beyond what is needed to demo the happy path
- Persistence, unless the idea is persistence
- Anything about scale, security or performance
- Code structure that anticipates a second developer
The corners I do not cut:
- The actual interaction being tested — if that is faked, the prototype teaches nothing
- Real data, or something close enough that it exposes the messy cases
- A clear statement, before I start, of the one question the prototype is meant to answer
That last one matters most. A prototype without a question is just a demo, and a demo will tell you what you want to hear.
The part that transfers
The habit came from somewhere else. Before product management I spent years in operations and supply chain analytics — building simulations of inventory policies, routing networks, production lines. The whole point of a simulation is to settle an argument you cannot settle by reasoning about it. Run the model, look at the distribution, stop arguing.
A prototype is the same instrument pointed at a different problem. Build the thing, hand it to someone, watch where they hesitate. That hesitation is worth more than a quarter of opinions.