Wesley Chang

April 11, 2017

Troubleshooting Your Hardware Product’s Technical Risk

Troubleshooting Technical Risk

Almost every new hardware product has some possibility of technical risk. That inevitably means there’s a chance that your hardware startup won’t be able to deliver a product because of some type of malfunction, engineering issue, or even a manufacturing complication.

I’m sure many of you have been in this situation. Maybe a charging module began to overheat, or perhaps you needed to cram 10 different components into a 0.76mm thick PVC.

Managing technical risk is one thing, but to mitigate it? That can be a totally different beast. Successful startups manage and mitigate technical risk very well. But a differentiating factor in hardware startups is one’s ability to tackle both. So let’s discuss what it means to manage technical risk as a hardware startup.

Managing technical risk as a hardware startup

Managing technical risk is simply a means to ensure risk is kept at a minimum at all times. Since bringing a new product to market is extremely risky and costly, many hardware startups focus their efforts in minimizing risk by lowering development costs early on.

That makes sense, right?

But exactly can you do, as a hardware startup, to minimize risk?

Plan for project development risks

Your hardware startup can’t reduce technical risk if you don’t have a plan. Reducing development costs may sound easy, but the question isn’t what to do, it’s how to do it.

For this part, I’m going to hand it off to John Teel. The man behind Predictable Designs, guest writer for Entrepreneur, and former senior design engineer at Texas Instruments where his electronic designs are now used in millions of portable devices.

Let’s take a look at his article, “4 Ways for Hardware Startups to Reduce Risk,” where he says,

“One of the best ways to lower risk, and increase your chance of success, is by hiring at least two engineers. This is especially true when it comes to developing your product’s electronics.

I recommend that you hire one engineer to actually develop the electronics, then hire a second, independent engineer to review the design before you produce prototypes.

You can be sure that any new hardware gadget developed by a large company has been reviewed by multiple engineers. To be competitive you need to emulate these successful companies to some extent.”

Mistakes are inevitable. That’s why design reviews are such an important process. Any engineer can make a mistake during development and not realize it. It doesn’t matter if they have 20 years of experience under their belt or they graduated from MIT with a Doctorate at the top of their class. Design reviews manage these mistakes before your concept hits prototyping or worse, production.

What about hardware complexity though?

With any hardware product that requires WiFi, Bluetooth, or even GPS, you’re bound to run into multiple technical issues. So, what can you do?

Many hardware founders would say that in order to manage such a technical risk, you should instead skip the custom circuitry and custom microcontrollers and jump straight to electronic modules.

Yes, this means that you’re also reducing cost. Electronic modules are pre-built self-contained assemblies that perform a particular function, right? So you’re probably wondering why not just build an entire product with these?

The answer is simple, build a product made entirely of electronic modules would be a lot more expensive than building out custom circuitry.

Duh, that would also increase technical risk

 

But don’t take my word for it, listen to John Teel’s. In the article, “Electronic Hardware Startups: How to Save Money and Reduce Risk,” John says,

“When designing an electronic function there are two main ways to go: a custom circuit, or a module. Most products are either fully custom circuit designs, or a combination of custom circuits and modules.

Rarely can a product be taken to market using only modules. However, early proof of concept prototypes, based on a development system like Arduino or Raspberry Pi, are many times 100% module based.”

And while all this sounds like a great plan to reduce future risk, there’s still the chance of running into complications during the actual product development. What are you actually going to do when your plan to manage risk fails? What can you do when your charging modules begin to overheat out of the blue?

Mitigating technical risk as a hardware startup

Yup, mitigating and managing are two different things my good friend.

You can manage risk by taking precautions and putting in certain processes in place. But what are you going to do when some component of yours suddenly fails?

I’m not saying that’s absolutely going to happen. I’m just saying that it’s still possible even with the precautions mentioned above.

So let’s talk about it!

DFMEA

Design failure model and effective analysis.

What's DFMEA got to do with technical risk?

A methodology for identifying current problems and future problems on a technical level to help you understand the actual risk of component failure.

Let’s look at what happened to Flo Labs, out of Highway1. A simple startup that focuses on taking advantage of technology in order to reconnect with the outdoors. They created a connected device for surfers. It learns their habits and preferences from each usage in order to recommend places to go and when to go for the best surf.

A real world example

During their product development phase, Flo Labs experienced a charging module overheat. And like most other startups, they wanted to identify the why and how this happened.

So instead of just swapping out the module for a new one, or redesigning it with a different component, they went through an entire process backed by DFMEA. In their case, it was a document submitted to the FDA that listed all of the components of the design and their failure modes as well as resulting effects.

“We found that our inductive charging module was heating to a point that we thought might affect battery life or cause some sort of failure. So we went through a series of different processes to understand the actual risk of overheating, using a methodology called Design Failure Modes and Effects Analysis (DFMEA), something I have some experience with from working on medical devices. Most of the time, it takes the form of a document you have to give the FDA that captures every component of your design: what are the failure modes and the resulting effects? You list every possible outcome and rate each based on severity of the effect, and based on those factors, you come up with mitigating actions. When we’re doing less-rigorous benchtop troubleshooting, that’s what I’ve got going through my head: a DFMEA”

But just a piece of paper alone won’t solve your problems. You’ll have to question this problem as much as possible in order to test for the right cause. Ask yourself,

  1. Was the module defected from the start? Swap it out with a new one and compare.
  2. Was the circuitry functioning properly? Test voltage measurements, wiring polarity, etc.
  3. Were any of the surround components the cause? Check the nearby components for malfunctions.

Taking action on technical risk

After a thorough investigation, you may or may not be able to move forward with development. By comparing the spec sheet of the component in question with the results you discovered after DFMEA, you can take the appropriate action.

Take action on technical risk

In Flo Labs case, they found that their inductive charging module differed by only 2-3º from a well known, certified brand. After seeing the side-by-side comparison, they were able to confidently move forward with their beta program without needing to make any serious changes to their design.

It’s not the end of the world

Technical risk can put your product at a stand still. Yet, companies like Coin were able to overcome immense scrutiny and technical risk.

But technical risk is just a part of hardware startups as the actual hardware itself. Any hardware startup is bound to run into some sort of complications. With a process like DFMEA, however, you can easily identify what went wrong, why, and how to move forward.

Leave a Reply

Your email address will not be published. Required fields are marked *