Most of the startups we think about can fit quite neatly into the asset-light, fast-iterating, lean mold– easily pivotable from spin to spin of an idea until stakeholders’ patience runs out (ala Yabbly). Hardware startups have a lot more to worry about — such as the much greater difficulty of creating functional prototypes, iterating, translating from prototype to production, and then the whole range of traditional logistics challenges (lead times, demand forecasting, manufacturer relations, packing, shipping, warehousing, customs duties, etc.), the last of which is often the most problematic. Failing fast, failing often thus seems a lot more challenging for hardware startups, and the high-profile failures of several crowdfunded hardware projects has shone a spotlight on the challenges involved.
Yet, interestingly, many of the lessons that founders of failed hardware startups list are similar to those we see elsewhere. The founder of KOLOS, a crowdfunded iPad accessory for racing games, for instance, listed the following as his top lessons:
1) Scratch your own itch
2) Make sure there’s competition
3) Build an MVP
4) Talk to customers
5) Don’t ignore the product
6) Avoid tackling too narrow of a niche
7) Take a good look at the market and its potential
8) Spend your funding carefully
9) Don’t be naïve
10) Fail fast
These are all general lessons, applicable to most startups, yet the relative weights are perhaps different for hardware. #1 and 5 are critically important, as hardware tends to introduce complexity that makes it more difficult to change the basic idea, and thus a resolve and investment in the idea (#1). Hardware also necessitates extra creativity to come up with a useful MVP (#3) for testing purposes — this is tricky because the surface details that differ between an MVP and a later version may be the very things that matter most to users (how would one usefully MVP a new smartphone, for instance, beyond a styling buck?). #8 becomes important because of the inherent cost and time bloat that accompanies the space.
Hardware doesn’t present an entirely different ballgame– the same principles we normally discuss for software or other areas still apply. Yet the differences necessitate additional planning to accommodate the lesser flexibility for later changes.