Speed can kill ; the importance of process for hardware

One of the more popular cliches of the startup world is the immortal Zuckerberg’s “move fast and break things.” Even though Facebook has since changed its motto, speed is currency in Silicon Valley. Entrepreneurs constantly promote their agility with phrases like “I built this in a weekend” or “we push five releases per day.” Investors brag about portfolio companies that are “crushing it” with “crazy fast iterations.”

 

But is this really the right focal point for all companies?

https://cdn-images-1.medium.com/max/640/1*n6S9QZu_fVXQmpl7uBxEFg.webp

 

Speed is one of the primary enablers of the startup ecosystem. It allows small, cash-strapped startups to overtake much larger, well financed behemoths. Shortening the build-measure-learn loop is crucial to startup survival and “ask for forgiveness product development” works really well when the friction of making changes is minimal.

Speed is great for software companies but will cripple hardware companies if not managed with caution.

The ‘Long Shadow’ of hardware

Friction in the hardware development process is fundamental to the nature of building things out of atoms. Most first-time hardware developers point to manufacturing as the major pain-point. This is a novice’s misinterpretation. It only seems that way because manufacturing is where the rubber meets the road from the past 6–12 months of product development. Early mistakes often don’t have a measurable impact until first shots are coming off tooling and the manufacturing process grinds to a halt.

My partner Scott calls this the “long shadow effect.” An early decision about which microcontroller to use or the shape of a housing can appear correct until months or even years later during the first production run. Sometimes parts can have exceptionally long lead times, require odd financing terms, demand manual rework, or be entirely un-moldable. None of these problems can be uncovered by moving quickly to get to production.

Shining light on the Long Shadow

There’s really only one way to avoid the debilitating effects of the long shadow of hardware: process. Strong process control is the difference between success and failure when it comes to scaling a hardware business.

Every engineer/manager/company has their own process that works best for them. At the risk of preaching a one-size-fits-all methodology, this is a high-level view of the a process of physical product development that has worked well for me:

https://cdn-images-1.medium.com/max/2048/1*WWWJQzzszUM619tPeEd6Ng.webp

The four phases

I’ve always liked “cowboy engineering” where process takes a backseat to building shit. But after many years of delays and quality issues caused by my boots and spurs, I’ve learned that a little bit of process can go a long way. I think about hardware development in four high-level phases:

1. Ideation

Problem research centers on very basic proof that you’re working on a problem that’s worth caring about. You’re spending time trying to learn more about how users currently deal with the problem you’re trying to solve. You are NOT talking to users to make suggestions on what you think, at least not yet. This phase culminates in a proof-of-concept prototype (sometimes called a ‘duct tape’ prototype) that summarizes your thinking.

https://cdn-images-1.medium.com/max/640/1*CHjOvaJ3m2uj2YNqkoWPTg.webp

Ideation: the first phase of product development

2. Design

The design phase exists to optimize the user experience of the product. It deals with the design of the physical product (industrial design) but also the digital parts of the product (firmware and software wireframes, if you have them). This iterative process culminates in a prototype that looks and feels like the final product (but doesn’t actually work). This is commonly called a looks-like prototype or model.

https://cdn-images-1.medium.com/max/640/1*vntxVnrekXqJVU3pVm6hyQ.webp

Design: the second phase of product development

3. Engineering

The engineering phase is often the most difficult. While many companies choose to omit writing of any kind, I’ve always found it exceptionally helpful to develop a product specification document (sometimes called a product spec or PDS). The spec outlines requirements that your product must eventually meet. The culmination of the engineering phase is to deliver a prototype that demonstrates the full functionality of your product (but looks like crap). This is often called the works-like prototype.

https://cdn-images-1.medium.com/max/640/1*ofWlsJaGu96pEzag1F9vzg.webp

Engineering: the third phase of product development

4. Validation

By far the most frequently omitted phase of building a scalable hardware product is validating that the product you’ve prototyped can actually be made cost-effectively and reliably. This typically involves a series of validation “tests” that confirm your design meets the requirements you’ve decided on. Most rewardingly, it ends with a product in mass-production and hundreds or thousands of units ready to ship out to customers!

https://cdn-images-1.medium.com/max/640/1*LDNyBiFbWcKiwRDwPidc9g.webp

Validation: the fourth phase of product development

This is not to say that hardware startups can’t move quickly; in fact they can move faster than ever before. But the ability to go fast and build good products on time and under budget comes from process, not pure iteration. The fastest companies tend to be exceptionally organized about their product development and manufacturing process. Many people have asked us to cover this in much more detail and we’re working on a 4 part series exploring each of these phases.