Image courtesy of Revolve Robotics, used with permission.
Image courtesy of Revolve Robotics, used with permission.

“Move fast and break things”—the gospel of Mark Zuckerberg, the battle cry of the modern-day agile software ninja. Failing often and early is great when you don’t have to worry about tooling and established assembly lines. Failing at all on a hardware product can bury a company. But modular, agile software practices can be applied to hardware, entailing real, physical iterations, testing different ideas as they coalesce into a product. Just like in software, the process is twofold: the religious, modular discipline, and the implementation or engineering of the process.

The first part is all in your head. Instead of “move fast and break things,” let’s call it, “I don’t know and you don’t know either.” This requires a level of humility on the part of the designer. In hardware, we are taught to design something as completely and as thoroughly as possible before we build it (of course, in many disciplines this is necessary—let’s not have any bridges collapsing). Realistically, the startup world does not allow for such clarity.

For early-stage startups, core things like the target audience for the product can easily change, and that’s OK since this is where we discover more about what we are doing. At this point as the designer, you have not had your product in a customer’s hands (assuming you even know who the customer is), and you will change things based on what you learn. Knowing and being honest that the thing you are building is not the final version, or even close, lets you plan accordingly. You’ll need to adopt a modular approach, designing so you can switch out components as you test and gather feedback. Knowing you are most likely wrong also helps in ditching bad ideas faster and not getting attached to a solution. Build it, try it, keep the good, throw out the bad. Nothing is sacred.

The second part is the implementation of this process. A modular approach allows you to nail down one part or subassembly and move on quickly to the other things you haven’t finalized. It’s like locking in an experimental variable while testing for others. This approach, especially initially, also lets you use more off-the-shelf parts, saving time. Sparkfun pioneered this with their breakout boards.

I have often judged the experience of a mechanical engineer by how much they buy off the shelf: the more experienced they are, the more they know how to find and adapt existing solutions. Even custom parts designed in-house should be as generic and reusable as possible. Recently, car companies have adopted this practice with parts that were typically custom made on a per-model basis—components ranging from hinges to exterior body panels—now used across several models and model years. In the case of a startup, where initial product volumes are low, reusing the same custom-molded part across several products breaks up the capital investment and earns better volume discounts.

The last critical bit to keeping hardware agile is to leave out the hardware all together. Sorry, had to say it. More and more of our products are software wrapped in plastic, and that’s great. Designing as much of your hardware as possible to be software controlled leaves a lot of wiggle room. Of course, the degree to which that’s possible varies: a robotic product is harder to modify through code than a fitness monitor, for instance.

A fitness monitor is a single printed circuit board with the right combination of sensors, battery, and processor. Once those are chosen and packaged correctly (they are modules, in their own way), the hardware is done. Now it’s up to the embedded, mobile, and Web software developers to make this pile of parts a great user experience. Most of the customer-facing features aren’t even on the device itself. It’s no wonder there has been such an explosion in these devices—even pets get their own.

Even on a complex robotic product, though, a lot of things can be changed. LED light behaviors, motor motion profiles, sequencing of actuations can all be updated through software. The autonomous driving feature on the Tesla Model S came in the form of an over-the-air software update. We’ve seen the same level of flexibility in new products connected to mobile app platforms—everything from thermal cameras to stethoscopes.

It’s easy to be spoiled by the state of the art in hardware development, with overnight PCB assembly services and in-house 3D printing at our fingertips. Taking this modular, agile approach to the next level is an exercise in design and project management.

Article image: Image courtesy of Revolve Robotics, used with permission.