Warning: You Must Be Willing To Accept Some Degree of Risk
Developing a new product is inherently risky and hard to predict. Regardless of the number of experienced people involved or how rigorously the process is followed, creating something new is a research and development activity. The research part implies that there are unknowns that are yet to be discovered.
This is even more true when we think about hardware product development. There are anywhere from 3-5 disciples involved, each engaging in some amount of research activities during the process. Additionally, because development cycles can be long in hardware, there are ongoing customer development, supply chain concerns, and market forces that can change the scope and challenge of a project.
But All Hope of Predictability is not Lost!
There are a couple of key areas where risk and unpredictability tend to sneak into a project and wreak havoc on project timelines and budget estimates. If we can manage those throughout the process, we can de-risk a lot of aspects of a project and limit potential pitfalls and hurdles to ones that are directly related to the problem we are trying to solve, rather than ancillary issues getting in the way. I’ve shared my top 5 techniques below.
The List
1. Only Design Custom Hardware for the Problems You Are Trying to Solve.
I can’t count the number of times I have seen hardware issues derail a development process in a hardware project. Developing good, trustworthy hardware is difficult because even a prototype PCB needs to be manufactured in a specialized facility, turnaround times are long and any issues can cascade onto software, marketing, or sales timelines quickly and dramatically. Add in recent supply chain issues and it can become almost impossible to predict when hardware will be “ready”. That’s why, when I am working on a new hardware project, I always like to start with a robust, well-tested, main compute board. This may be a single-board computer running Linux or an MCU carrier board or module. That way, my team and I can focus on figuring out the hardware challenges that are unique to our problem space. Products like Arduino, Raspberry Pi, and the Nvidia Jetson are great initial compute boards.
For example, In a recent specialized sensing project I have been working on, we only developed the hardware that mounts the specialized sensing circuitry in the configuration needed to perform the measurement. By doing this, we have been able to focus on solving the actual underlying scientific problems with the sensor, rather than random hardware gremlins that could come up.
2. Don’t Let the Final Form Factor Concerns Get in the Way of Getting Prototypes into Potential Customers’ Hands
This comes up most commonly with wearables, but can also apply to any type of hardware project. Product owners, whether they are founders, executives, or product managers, often find it easy to picture a hardware product as a thing they can see and touch. The problem is, that vision tends to materialize early in the process and isn’t necessarily informed by the technical and scientific realities of the problem and potential solution, as those haven’t been discovered yet.
I’ve seen this most often with medical wearables I’ve worked on, but also in many other spaces. In the medical wearables space, the most important problem to solve is proving that the medical device does what you intend it to. If you are trying to measure an important vital, it is of the utmost importance that the device being worn can do that. “I have told clients, just make a rig that holds the sensors we need in place. We can put the computing and connectivity hardware in a backpack for now and figure out that portion once we solve the medical case.” Often, clients want to see the final form factor early in the process and it ends up entangling the two problems.
3. Make Sure the Price of your Product is High Enough
Pricing is one of the hardest parts of a business and there are many publications written about it, so I won’t rehash those here. The one thing I’ll say is that decision-makers, especially at smaller firms, tend to chronically underprice their IoT and hardware products. You need to keep in mind that, unless you have ample capital available, the margin of your first product needs to cover not just the unit economics, but all hosting and data costs of the IoT cloud portion of the product, ongoing engineering, and maintenance, the engineering costs of making v2 of the product and the cost of manufacturing v2 of the product. You never want to end up in a scenario where you are making such slim margins on your hardware product that you can’t afford the make the next version because hardware of any kind is a competitive market.
4. Don’t Reinvent the Software Wheel
The hardware space has a lot of really good, really robust, ready-to-go software stacks in it. However, for some reason, many firmware and embedded software engineers exhibit an odd machismo about a lot of these technologies. You’ll see things like “Real Engineers don’t use Raspberry Pi”, “Real Engineers don’t IDEs” or even “Real Engineer write Bare metal embedded C”. I don’t know where this comes from, but I can tell you, this is all nonsense. Don’t fall for it. Real Engineers deliver results and get stuff done. In the web development space, you don’t see engineers only writing vanilla HTML and JavaScript and manually running web servers. They use frameworks like Node JS or Ruby and Rails on the server side and Angular or React on the client side. Why? Because it gets the job done and simplifies the problem space. Just because something is easy and approachable doesn’t make it inappropriate for professional use.
Use Raspberry Pis. Use Arduino. Use Micropython. Use advanced IDEs. Use Frameworks. Use whatever gets the product to market efficiently and successfully.
And to be clear, use bare metal C when appropriate, like for specialized custom sensing applications or high-speed drivers, not business and application logic.
5. Don’t Be Afraid to Use Alternative Manufacturing Technologies for Early Versions of your Product.
Digital Manufacturing technologies have come a long way in recent years. Many hardware teams tend to think that the product is “real” unless all the mechanical parts are injection molded and made offshore. Injection molding has some great advantages once you get to a certain scale, but in early versions, it can have a lot of NRE costs, confounding design limitations, and long turnaround times.
It is much more important to get devices into customers’ hands and retain the agility to change things as you get feedback than to optimize your unit margins by injection molding all your components. As your product scales, you can always migrate to molded parts as the long-term product path stabilizes and you learn what customers want and are willing to pay for.
Conclusion
I hope you find these tips useful and if you have any questions about hardware projects, feel free to email me at kyle@spinnaker.design, comment below, or reach out to me on LinkedIn.