Technical and Product Risks for Hardware Startups, by @BenEinstein for @BoltVC #ManufacturingMonday
Ben Einstein has a quick read on Bolt.io’s blog about risks to manage and/or mitigate when launching hardware products. The graph below is overly simplistic by design, and is a good matrix to consider where your product falls in the plot lines – are you more or less prone to product, or technical risks, or both? If the latter, watch out!
While first generation products are always plagued with bugs, fail whales, and even the occasional mass-recall, most companies can bounce back from these setbacks. They build great customer support teams, release version two, and turn unhappy customers into believers. So with all the venture dollars and a talented team, why wasn’t Coin able to overcome?
Every startup is a constant struggle to manage and mitigate risk. When it comes to hardware startups, there are two types risk that are manageable on their own, but when combined often spell failure: technical risk and product risk.
Biohacking — Two Blood Meters to Start Your Biohacking Adventure
Get the only spam-free daily newsletter about wearables, running a "maker business", electronic tips and more! Subscribe at AdafruitDaily.com !
It seems to me that the engineering analysis tool “Failure Modes and Effects Analysis”, might lead to some insight as to the ‘riskiness’ of product startup companies.
FMEA is basically a method engineers use to think about how a design could fail, and how bad it would be if those failures happen. To each brainstormed failure mode, an engineer will assign 3 numbers (on a scale of 1 to 10, or 1 to 100): Probability of Failure ‘P’, Severity of Failure ‘S’, and Inability to Avoid (or, if you like, Inevitability) ‘I’. The product of these three numbers multiplied together, is called the Risk Priority Number (because engineers like to make obscure names for things. Maybe a better name: ‘Scariness Number’). A big RPN means a big problem.
In the example of the Coin reprogrammable credit card, there could be many ways of failure, but the big one seems to be ‘rejected swipe’. (‘Dead battery’ is another.) If this failure mode happens often (high ‘P’), totally prevents the transaction ( high ‘S’), and swiping it again doesn’t help (high ‘I’), this would be a Scary Problem.
In contrast, as the article’s author mentioned, a Roomba has a failure mode of ‘missed a spot’. This failure mode doesn’t seem to happen very often (middle-ish ‘P’), doesn’t stop the robot from continuing to clean (low-ish ‘S’), and can be worked around by using the Roomba’s “Spot Clean” mode (low-ish ‘I’). Thus, it’s not a big problem. (I’m guessing that “Spot Clean” mode was in fact created to alleviate this very failure mode.)
I like FMEA because it gets you thinking about what might go wrong, what you should and shouldn’t worry about, and how you could solve problems with your design.
Thanks for chiming in Dave – I was unaware of the FMEA acronym, I’ll read up on it further.