4 ms·
Observation due to current venture: not much of the strategy content applies to hardware companies (particularly hardware companies not manufacturing consumer o
by contingencies 6y ago
Observation due to current venture: not much of the strategy content applies to hardware companies (particularly hardware companies not manufacturing consumer or IOT widgets). Similarly, not much of the funding and regulatory advice applies to cross-border startups.
Regarding deep tech hardware, on the one hand you have PG stating his support for from-scratch thinking[0], on the other hand you have this de-facto "ship and iterate" model from the SaaS world which just doesn't apply to nontrivial hardware projects.
I have to say this problem isn't specific to YC: the vast majority of advice liberally distributed to founders by VC and early stage investment world actors can range from irrelevant to dangerously misleading for founders in some of these spaces.
The lesson here is: take what you will and treat nothing as gospel.
[0] https://twitter.com/paulg/status/1172430190401572864 https://twitter.com/paulg/status/1172430190401572864
- tlb 6y agoMost deep tech and hardware projects can also benefit from a ship-and-iterate model. There are always pieces you can show to some customer, even if they're simulations or a tiny component of the whole thing. It creates some work and stress to deliver them, but the feedback you get means you're more likely to end up with something the customer wants at the end of the project.
- contingencies 6y agoI too embrace your perspective but it is unfortunately naive. If you want a tiny plastic enclosure around a simple circuit board, by all means iterate quickly. When producing larger hardware it is common to have parts which require multi-month production and testing cycles and 5-7 figures USD just for the tooling to enable the process (not including design, actual fabrication equipment, outsourced equipment time or stock material). You usually have multiple parts of this commitment level within a larger product. You don't rush out the door when you are dealing with those sorts of realities.
- nojs 6y agoWhat are you building?
- contingencies 6y agoThe consumer view is always available, meaningfully personalized food produced on demand from fresh ingredients as an autonomous urban utility, 10-20× faster than delivery services. Technically, we're building the robotics, R&D and manufacturing capacities to define and dominate that market with a network of just-in-time contactless kiosk-format microfactories. As a consequence of the challenging form factor we've set for ourselves, the regulatory requirements of food handling and so on, let's just say the complexity and BOM length is arguably greater than most vehicles.
- nl 6y agoAs someone who's had some ancillary involvement in a hardware product I have a lot of sympathy with the disconnect between doing hardware and the "ship fast SAAS product" mindset. However, in this case your comment: > As a consequence of the challenging form factor we've set for ourselves does seem to indicate that decisions you have made yourself are one of the factors causing you to slow down here. Something to consider...
- contingencies 6y agoWell, if you survey the space we are looking at you will find good commercial reasons for that form factor. Such as: size of available spaces under typical vending leases, fits through door, fits in lift, fits in corridor, fits in truck, etc.
- nl 6y agoI don't think anyone will ever argue that you know your market well! I think what people are trying to say is that there maybe ways to get a partial solution to a smaller part of your customer base much quicker and for less money.
- mauriziocalo 6y agoTwo observations: 1) Shipping-and-iterating is uncomfortably hard. Putting your product out there in front of users is painful. It's a lot easier to just constantly brainstorm ideas or hide in the coding cave. 2) As a founder, it's tempting to think that your startup is unique: what you're building is uniquely challenging, important and highly non-trivial. Anecdotally, I've seen far too many founders (including my own past self) use 2 as an excuse not to do 1: most of the time, those never even launch. And not just in the hardware space, but also in: health-tech, bio, fin-tech, gov-tech, legal-tech, insur-tech, prop-tech, food-tech, logistics, and even B2B SaaS ("what we're building is hard and needs enterprise-grade robustness / security"). There may be ways to build massively successful companies that don't involve rapid shipping-and-iterating cycles, and in general there may be ways to build successful companies while ignoring or even doing the exact opposite of what YC advises. But YC would know a few things about hard-tech from having funded possibly hundreds of such companies, including several massively successful companies. In fact, the top 3 YC companies of all-time as of 2020 are all in highly-regulated spaces: Stripe, Airbnb and Cruise [1]. Cruise in particular is a hardware company (self-driving cars) whose billion-dollar success was largely due to their ability to ship-and-iterate much, much faster than pretty much every other self-driving car company out there. [1] https://www.ycombinator.com/topcompanies https://www.ycombinator.com/topcompanies
- contingencies 6y agoYes that is great advice for many startups most of the time, but my whole point in the grandparent was that when as a founder you find the hand-me-down wisdom doesn't fit, don't be afraid to leave it alone and think for yourself. PS. If your criticism were right my coding cave is a 1000m2 factory, which has to be some kind of record. /s
- capocannoniere 6y agoIn your parent comment you mention: > not much of the strategy content applies to hardware companies While it's probably a good idea to not blindly follow every single piece of advice (by YC or anyone), saying that not much of the content applies is probably a bit of a stretch. Considering how many successful companies YC has funded in the hard-tech space, I'd be receptive to at least some of their advice / insights. You also mention: > you have this de-facto "ship and iterate" model from the SaaS world which just doesn't apply to nontrivial hardware projects. Again, it may be a good idea to question the advice of "ship and iterate", but saying _it just doesn't apply to nontrivial hardware project_ is again a bit of a stretch. As the above commenter mentions, the success of Cruise is a good counterexample.