This is part of a series discussing some key high-level challenges of the hardware product development process and how to tackle those problems so that you can mature your design to be ready for manufacturing. Product development is a deep and challenging topic. This series focuses on hardware development engineering, and does not address some critical topics like defining the minimum viable product (MVP), assessing market fit, the value of development partners, etc.
Lesson 1 – Proof of Concept Is Not Proof of Product
Simplexity has had many startups come to us stating “we have a working prototype, all we need are the manufacturing drawings”. If this were only true! If a working prototype meant a working product, then every engineering undergrad would be launching a company with their senior design project.
First prototypes are often constructed with 3D printed parts and hobbyist grade electronics like Arduino. There’s been little thought towards the manufacturing processes needed to enable a viable cost structure or to deal with the tradeoffs those processes require. The “happy path” behavior works, but rarely can these prototypes deal with errors or unexpected user behavior; things like pushing a button at the wrong time or dropping the product on a concrete floor. On the electrical side, issues like battery life or EMI compliance have not been addressed. In short, the prototype demonstrates the desired behavior when everything goes right, but cannot stand up to real world abuse, would cost too much to produce as-is, and may not even be legal to sell.
The cold hard truth is that the first prototype is not a product prototype, it is a proof-of-concept prototype. It proves that your idea can work. It does not prove that you can repeatably build a functioning, reliable product, and that you can do that with a cost structure that is required for a profitable business. I do not want to diminish the value of that prototype: coming up with a novel idea for a product people would actually buy, and getting one prototype working is incredibly difficult. However, it’s just the first step down a long road towards the manufacturing launch.
Model: NASA.gov Technology Readiness Levels
Readiness Levels
For large engineering projects, the sort of projects that NASA and the Department of Defense engage in, the concept of a Readiness Level has been created. NASA created a Technology Readiness Level (TRL) model for space systems, which has since been standardized into ISO-16290. The Department of Defense created the Manufacturing Readiness Level (MRL) model for weapons systems, and Steve Blank, an adjunct professor at Stanford University created the Investment Readiness Level (IRL) model to map the TRL and MRL into something that could guide investors as to whether a startup was a good bet for investment.
In most cases, a proof-of-concept product exists at about TRL 4-6 out of 9, MRL 1 of 9 and IRL 4 of 9. The product is based on existing, commercially available technologies, and is combining these in a novel way. It demonstrates the key product defining value add behaviors and can generate data on some areas of product performance in a controlled environment/situation.
There is one critical bit of the TRL that is often missed by startups, and I’ve seen this lead to the demise of companies. These companies move forward, progressing their product into TRL 5 or 6 without completing a critical portion of TRL 4: understanding their product’s performance through the operating range of all critical performance parameters. If you go too far before you understand the knobs that can be turned to affect your product’s performance, and the sensitivity to those knobs, your company’s risk profile goes up tremendously. Here are two real world case studies about understanding product operating windows.
The Bad
Simplexity had a client that was developing a product that would execute a specific chemical process. Before engaging Simplexity, they created a lab system to develop their process. Using that system, they demonstrated their process working. However, after generating their first working recipe, they halted process development work and came to Simplexity to start product development. They did not understand the operating window of their key parameters.
Once the first full product prototype was created, we were all surprised to find that the process did not work. The product could execute the process with the exact parameters used in the recipe created with the laboratory system. Since the full prototype was the product intent design, those parameters were baked into the design. Varying parameters required updating designs and was thus slow and expensive. Due to investor schedule pressure, this company did not go back to the lab phase to understand their process window, rather they plowed forward, exhausted their funding and went out of business.
HP PageWide Pro 500-sheet Paper Tray
The Good
When I worked at Hewlett-Packard, the team was designing a new paper input tray for what would become the HP PageWide Pro. This was the first input tray that the division would design that could support a full ream of paper (500 sheets). Reliable paper pick and singulation (picking a single sheet instead of multiple sheets) is a notoriously challenging problem over the range of paper types in the market and humidity ranges in which printers must operate.
To address the challenges of this design, the team created dedicated testbeds that allowed them to easily modify materials, pick forces, and paper stack lift angles. They used the testbeds to perform studies across a wide range of these critical performance parameters, including running tests in environmental chambers. This allowed them to optimize the design to work robustly before starting the detailed design for the product, and before committing to the large financial investment of plastic injection molds.
Honestly, assessing the readiness level of your product against the TRL, MRL, and IRL models are critical to reducing the risk of the development process for your company. I’ve seen companies skip steps to their detriment many times. Use the models to your advantage. Figure out where you are, what the next steps need to be, and if you need help, reach out to a company like Simplexity to help guide you along your product development journey.
Software: Design Complete
Hardware: Pre-production units for design verification
MFG. Readiness: CM schedule and budget, Unit build tracking