Speaking purely to the experiences of building a new software product, I've seen this exact story play out countless times. Everyone (except maybe the engineers

Speaking purely to the experiences of building a new software product, I've seen this exact story play out countless times. Everyone (except maybe the engineers themselves) seems to think that designing a software product is part of the "planning phase", and thus should happen before any time is "wasted" on development: > "That product planning led to an immense series of wireframes and comps (visual designs of what the product would look like and how it would function) that numbered into the hundreds of screens..." The biggest contributor to this I've seen is the dozens (hundreds? thousands?) of small ways that a design (done in a vacuum, without simultaneous prototyping) will differ from established development patterns, frameworks, and other pre-packaged solutions that engineers use daily to avoid reinventing every wheel. And engineers respond with timelines that expect to be able to leverage those frameworks. Thus the dissonance begins. One example: a design calls for a form to be broken across 4 pages. There may be great aesthetic rationale or even user testing to support this, but that means that in all likelyhood any framework (e.g. Rails/Flask/Play/etc, not to mention native apps) will have to have additional modification to support sessions, changes to validation, changes to the auth domain, persistence changes, etc. And it's not necessary for an MVP. And many times these differences are much more subtle and deeply entrenched, and would require rethinking much of the wireframes/designs to align with development patterns. /rant I'm not sure what the answer is here, except maybe that this is one more point in favor of having a "technical founder" or in general a technical person with decision-making authority, to avoid going down a road without proofing out your ideas or timelines.