Unlike software, hardware iteration is slow and costly. A better approach is to resist building immediately and instead spend the majority of time on deep problem discovery. This allows you to "one-shot" a much better first version, minimizing wasted cycles on flawed prototypes.

Related Insights

The goal of early validation is not to confirm your genius, but to risk being proven wrong before committing resources. Negative feedback is a valuable outcome that prevents building the wrong product. It often reveals that the real opportunity is "a degree to the left" of the original idea.

Don't wait for a prototype to get traction. Hardware founders should first engage potential customers and demonstrate a profound understanding of their specific problems. This expertise builds the necessary trust for customers to commit, even before a physical product is ready.

To de-risk innovation, teams must avoid the trap of building easy foundational parts (the "pedestal") first. Drawing on Alphabet X's model, they should instead tackle the hardest, most uncertain challenge (the "monkey"). If the core problem is unsolvable, the pedestal is worthless.

For ambitious 'moonshot' projects, the vast majority of time and effort (90%) is spent on learning, exploration, and discovering the right thing to build. The actual construction is a small fraction (10%) of the total work. This reframes failure as a critical and expected part of the learning process.

A visionary founder must be willing to shelve their ultimate, long-term product vision if the market isn't ready. The pragmatic approach is to pivot to an immediate, tangible customer problem. This builds a foundational business and necessary ecosystem trust, paving the way to realize the grander vision in the future.

Moving from a science-focused research phase to building physical technology demonstrators is critical. The sooner a deep tech company does this, the faster it uncovers new real-world challenges, creates tangible proof for investors and customers, and fosters a culture of building, not just researching.

The misconception that discovery slows down delivery is dangerous. Like stretching before a race prevents injury, proper, time-boxed discovery prevents building the wrong thing. This avoids costly code rewrites and iterative launches that miss the mark, ultimately speeding up the delivery of a successful product.