A prototype should change the decision
The value of a prototype is not how finished it looks. It is whether the team knows something different after using it.
At Zenklub, defining the MVP for in-person therapeutic consultations became useful when operational constraints forced the scope to become concrete. In Fio, working through the actual path from saved content to audio exposed questions that an abstract roadmap could hide.
That is what I want from a prototype. It should put the uncertain part of the idea in front of the team while the cost of changing direction is still low.
Sometimes the right artifact is a clickable flow. Sometimes it is a live model call, a manual service, or a spreadsheet that makes the economics visible. The format matters less than the decision it is meant to inform.
A polished prototype can still be a poor one. If it only makes the preferred idea easier to admire, it has reduced no uncertainty. The useful question is: what could we learn from this that would make us change the product, the scope, or the plan?
Prototypes are not always better than analysis. Some questions can be answered with customer conversations, existing data, or a careful calculation. I build when making the idea concrete is the fastest honest way to find out what is real.