I wish the Harvard Business Review (HBR) had published its article "Early Prototypes Can Hurt a Team's Creativity" one year earlier! I have a financial interest in a startup which may be suffering for having prototyped too soon. I did have the nerve to criticize this with my team, but when I observed the results, it was too late to fix and ultimately money down the drain.
The HBR article made a point which I'll attempt to present in my own words and from my own experience.
Many developers seem to focus on function without having had the opportunity to sufficiently understand what the technology being developed will be solving! There are almost always ambiguities, and that suggests a need for closer interactions with those who originally defined the project. Unfortunately, such an obvious requirement is often passed over with poor results, such as having to spend for do-overs.
Management must be vigilant from the very beginning when involving developers, and of course the developers themselves need to stay in close contact with management. However, developers often work on a heads down basis, whether because of shyness or a belief in their superiority. Yes, too many developers seem to enjoy taking matters into their own hands!
HBR calls this "'innovation blindness' [which] causes conflict and delays and may sink a project altogether." An example it introduces involves arguments over feature details, and even of feature selection. And it points out that whenever a new technologist joins a development group, there's the danger of new superimposed perspectives which create ambiguity. This is especially true when the newcomer is a manager!
To repeat, the solution seems obvious: founders or established management must make sure from the very beginning that the entire team is on the same page at all times with respect to details; and developers must ask questions as the project progresses while management looks over their shoulders.