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.
Adafruit publishes a wide range of writing and video content, including interviews and reporting on the maker market and the wider technology world. Our standards page is intended as a guide to best practices that Adafruit uses, as well as an outline of the ethical standards Adafruit aspires to. While Adafruit is not an independent journalistic institution, Adafruit strives to be a fair, informative, and positive voice within the community – check it out here: adafruit.com/editorialstandards
Stop breadboarding and soldering – start making immediately! Adafruit’s Circuit Playground is jam-packed with LEDs, sensors, buttons, alligator clip pads and more. Build projects with Circuit Playground in a few minutes with the drag-and-drop MakeCode programming site, learn computer science using the CS Discoveries class on code.org, jump into CircuitPython to learn Python and hardware together, TinyGO, or even use the Arduino IDE. Circuit Playground Express is the newest and best Circuit Playground board, with support for CircuitPython, MakeCode, and Arduino. It has a powerful processor, 10 NeoPixels, mini speaker, InfraRed receive and transmit, two buttons, a switch, 14 alligator clip pads, and lots of sensors: capacitive touch, IR proximity, temperature, light, motion and sound. A whole wide world of electronics and coding is waiting for you, and it fits in the palm of your hand.
Have an amazing project to share? The Electronics Show and Tell is every Wednesday at 7pm ET! To join, head over to YouTube and check out the show’s live chat – we’ll post the link there.
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.