Are We Ready to Ship?

Sometimes the work of a startup seems overwhelming – especially as the moment of truth of shipping a new product for the first time approaches. When that happens, it is time to break down and characterize the problem(s) – and then systematically work for acceptable solutions. 

It is a classic startup problem.  As the time approaches to ship a new product for the first time, the product development team sometimes seems to get stage fright. Every possible risk seems to loom large. The unknown unknowns as well as the known unknowns begin to feel overwhelming. The endless worrying begins and, as CEO, if you have established a culture of openness, you will face a steady stream of visits from well-intentioned team members who want to warn of possible failure modes. It can become quite a challenge to sort through. Which risks are likely? What is the potential severity of a particular failure mode? What does minimum viable product really mean in this case? Where is the right balance between the risks of shipping the product versus the risks of delaying entering the market?   These decisions are complex, nuanced, and consequential.  

Here are some of the strategies I have used to navigate this type of threshold season:

Know Your Risks by Defining, Assessing, and Working the Problem(s)

Assuming you are not the most knowledgeable technologist, you need to help bring the objective facts to light so you have the information you need to assess the relative risks of different paths.

When evaluating product risk, look from the point of view of the customer.  It is tempting to just focus on the aspects of the problem that you know about or have control over.  However, it is essential to think about the totality of the problem from the customer’s point of view, from the beginning of the inputs to the process until the logical concluding point, even if your solution only covers some middle portion. The rationale for this is that your customer does not draw artificial boundaries so to maximize customer satisfaction, you need to think broadly. 

To get the overwhelmed and uncertain feelings of the team under control, work with your most knowledgeable team members and start brainstorming the dimensions of the problem(s) that remain. Get it all down in writing. What DO you know.  What don’t you know.  Where are your risks, failure modes, uncontrollable factors?  Bucket the dimensions of the problem by type or cause, if possible. Make the list MECE (mutually exclusive and collectively exhaustive).  Get it all out there.  Any remaining concern has a right to get on the list for evaluation. 

Then start characterizing the problem types.  That which you measure you can improve. How often does the problem occur? How severe are its consequences when it does occur? Are there any controllable factors? Uncontrollable factors? What is the ideal desired state? Is there a minimum acceptable failure threshold? Can you mitigate the risk? Will your customers tolerate the consequences of a particular type of failure? Not every risk needs to be mitigated. By getting it all down on the list, you can divide and conquer the questions and get away from amorphous worries. Assign. Investigate. Learn. Assess. Decide.

Test Your Solution with Real Customers

To confirm your understanding of the readiness of your product, do alpha or beta testing directly with customers to assess the adequacy and value of your solution. Customer testing can reveal unexpected problems when the way customers use your product differs from the way your product development team builds and tests its prototypes.  I remember vividly when we put our beta prototype instrument into an advisor’s lab for initial real-world testing – and discovered that our instrument overheated when the lid was closed. We had not realized this risk that was so obvious in retrospect because our engineers never shut the lid when they were testing.

Real-world testing can be tricky with regulated medical products, but at the very least, you should be collecting lots of customer feedback on your designs along the way and looking for opportunities to deploy in test scenarios. When we will building a scientific instrument, we did nine months of beta testing with customers – and we knew we had worked our problems down to an acceptable level when the beta testers wanted to buy the beta instruments rather than give them back. For our medical device software, we conducted retrospective clinical testing and pilot testing in addition to informal and formal human factors testing.  

Remember to Assess Both Sides:  The Risk of Waiting May Outweigh the Risk of Going Forward

There is always the temptation to add one more feature or make the product just a little bit better, however, for a startup, the threat of running out of money if getting the product to market takes too long is a real risk. So, as you are assessing what else you can do to make the product better, you also need to be evaluating whether you have actually done enough to deliver real value to customers. If you have, then move ahead and get the product in the market. You will learn a great deal – and be able to continue to make improvements for the next generation based on real-world feedback as well as developing your startup’s commercialization and manufacturing capabilities. These are the foundational building blocks of a business – and you need to take the leap and ship the product to achieve them.