Lessons from a Hardware Startup

10 Sep 2018

In a previous job, I wrote firmware for a startup, Doppler Labs, an early entrant into the still young field of “hearables.” Despite at least a year of head start on the competition, an exceptional team, and $50 million in funding, the company eventually folded. I’ve been thinking alot over the last year on how this happened. On some level, it’s just the vicissitudes of the business– hardware is hard and whatnot. But if I’m being honest, a good share of the blame rests with strategic decisions that we made. I’ve tried to distill my thinking into some lessons. Some of these lessons are specific to young hardware companies, and some apply more generally.

Hardware Specific Lessons

Hard-to-build boards wreck velocity

If your board isn’t extremely difficult to SMT (more on that later), the task with the longest lead time between builds will be spinning the PCBs. In our case, we had a horrendously complicated 9-layer rigid flex board. Only one supplier (a Korean company) could produce it with any consistency, and it took them eight weeks to do so (and they had very high minimum volumes). This made it impractical to experiment with component placement or trace routing. This is especially problematic if you are doing anything involving radios. The time and cost to spin a new board meant that that loop could only be processed once every three months. Unsurprisingly, poor bluetooth performance was one of the most consistent complaints with the product.

Have a board that you can SMT locally

This is a close relative of the above. If SMTing your board involves sending people to a contract manufacturer in China, setting up an assembly line, and getting the finished product through customs, it will ruin your iteration speed.

Avoid 01005 components

Unless your company has years of experience and the resources to hire specialists in the field, avoid anything smaller than 0201 components. Even our Tier 1 CM partner had all sorts of problems with tombstoning and weak solder joints. Avoiding the parts also makes it much more likely that you can find a local company to SMT.

Commercial compiler toolchains can be worth the money

Coming from backend systems at large companies, this one was a bit of a surprise. Well, GDB and Clang toolchains might be free, but using them would have meant a developer solely responsible for build tools, which we could not afford. If you’re looking around, I’d suggest starting with IAR Embedded Workbench for ARM. Their linker alone makes it money well-spent. I’ve also found that it generates somewhat denser code than GCC. Their IDE is terrible, but it’s very easy to integrate their tools with Eclipse and CLion.

Stay away from the CSR867x

If your product is just a speaker hooked up the CSR867x, then go ahead and use it. Otherwise, avoid it like the plague. It’s expensive and extremely difficult to debug. Even apparently simple questions such as “under what circumstances will the chip be in a low-power mode” were impossible to determine. And the support from CSR (now Qualcomm) is atrocious.

General Lessons

Keep teams lean

This is hardly an original insight, but it bears repeating. Payroll is by far the most significant cost for technology companies. $50 million might sound like a huge amount of money, but a company with a headcount of 75 can run through that in a few years. Combine that with at least two years (at the very minimum) between starting work on a consumer electronics product and realizing any revenue from it. The question always should be, “what essential product / feature can we not deliver without this person?”

Maintain high standards for any outsourced work

The original iOS app to interact with our product was written by a freelancer. Despite his high costs, he was obviously mailing it in. It took six months to unwind the mess he had made. We should have done more diligence before hiring him, and been less accepting of subpar work.

Be honest with your scheduling

Again, not an earth-shattering revelation, but I’ve seen this error everywhere I’ve worked. If you allocate 2 weeks to a task, and it takes 4 weeks, you need to update your schedule to take that into account. Saying things like: “we built the schedule a bit conservatively anyway, so we can just compress everything else” is setting you up for failure. After a few missed deadlines, you’ll end up in “schedule hell,” a vicious cycle where scrambling (inefficiently) to make up a missed schedule causes cascading delays.

You have more time than you think

Underlying many of the bad decisions we made was the idea that the product absolutely had to be in the retail channel in time for the 2017 holiday season. We had so much belief in the first-mover advantage that we compressed what should have been a 24 month product cycle into 12 months. Shipping with a more conservative schedule was thought to result in certain doom for the company. In that light, it made sense to hire all of those additional people. We were going “all-in”, so we might as well add all of the headcount we could. Yet the 2018 holidays are approaching, and still nobody in the market is offering a product with the same feature set that Doppler was targeting.