I like quick prototypes more than most managers I know, and I have also watched more of them go wrong than most managers I know. I think both of those are true for the same reason. A prototype is the cheapest way to answer a real question, and the cheapest way to accidentally start a product.
Why I like them
A prototype answers a question. Will this approach be fast enough. Can this integration actually be done. Will anyone use this. A few days of code can settle those questions in a way that a design document, however good, cannot, because the document is a prediction and the prototype is a result.
I also think prototypes are good for teams. They let an engineer try something without the weight of production standards, which is where a lot of the best ideas come from. And they give a team something to look at together, which changes the conversation from opinions to observations.
How they go wrong
The prototype works. Someone with influence sees it. The question it was built to answer gets answered yes, and the obvious next step is to ship it, because it is right there. And so the shortcuts that made it fast to build become the foundation of something that now has to last: no tests, no error handling, a data model that was right for a demo.
I do not think this happens because anyone is careless. It happens because a working prototype looks like a product to everyone except the person who built it, and that person is usually outnumbered.
The rules I think keep them honest
Name the question first. A prototype without a written question is a project without a scope. If the team cannot say what they will know at the end that they do not know now, I think it should not start.
Time-box it. Days, not weeks. A prototype that is still going after two weeks is a product with a worse name.
Throwaway by default. I think the code should be assumed to be discarded, and anything that survives should be rewritten into the real codebase on purpose, with the real standards. Saying this out loud at the start is what makes it possible to say it at the end.
Demo the learning, not the code. When the prototype is shown, the thing being shown is the answer to the question. The code is evidence. If the demo is about how good the prototype looks, the question has already been lost.
Decide what happens next before the demo. If the answer is yes, what is the real project, who owns it, and when does it get planned like any other work. That decision belongs on the roadmap through the normal door, and I think making it in the demo meeting is how prototypes become products.
Where this stops being true
Sometimes the prototype is the only path. A deadline that cannot move, a market moment, a situation where a rough thing now is worth more than a good thing later. I think that is a legitimate choice, and the honest version of it is to say so: we are shipping the prototype, we know what it is, and here is the plan to pay for that. The failure is not shipping a prototype. It is shipping one without admitting it.
Photo source: https://photos.robertstowe.com/cumberland-island