As engineers we are fundamentally wired to solve problems. Unfortunately, we are often asked to design products based on fundamentally weak problem statements. This leads to wasted time and money, along with frustration for everyone involved. With new and innovative products this is a particular risk—the customer problem statement is generally uncertain, which can result in product development teams attempting to solve a problem they don't fully understand, or one that might not be a problem in the first place.
Frequently, it’s commercial uncertainty, not technical, that should be the initial driver of prototyping efforts. But engineers are not market analysts. Don’t worry, there is still an important role for the engineer even when we are thinking about commercial risk, we just need to expand the definition of the problems that need solving.
The Question of Customer Uncertainty
One of the most interesting and enjoyable experiences in my thirty plus years as an engineer was building and running the Advanced Development (AD) group at the Chamberlain Group Inc (CGI). The AD team developed many successful features and products including the original prototypes for CGI’s groundbreaking IoT products, including the MyQ internet connected garage door operators. In my work, now as Engineer-in-Residence at mHUB, I often find myself reaching back to the lessons I learned during this time.
At AD, reducing the largest uncertainties of any new product idea, whether it was technical or commercial, became a fundamental guiding principle in our approach to innovation. Using this lens, we could minimize the cost of our efforts while maximizing our learnings. This frequently led to developing intermediate prototypes focused on answering questions about how a customer would use or value a product. These ratty prototypes, as we lovingly called them, were often constructed from a mix of repurposed components, or outright mockups.
As EIR, Wayman consults with mHUB members such as AION Prosthetics Co-Founder and Industrial Designer Josh Becker.
An inspiration for our thinking was Lean Startup by Eric Ries. Ries tells the story of the founder of Zappos, Nick Swinmurn, who had a vision in 1999 of a virtual retail experience where consumers could purchase shoes online. At the time, it was difficult to gauge the demand for online retailers, so to answer the uncertainty around whether a venture like this would succeed, Swinmurn conducted an experiment.
Rather than investing in a supply base, warehouses, and distribution partners, he received permission from local retailers to post pictures of shoes available in their stores on his website. When an order was placed, he would go to the retailer, buy the shoes, and ship them out. With this approach he was able to minimize his investment and maximize his learning about customer demand for the service. Ten years later, in 2009, Zappos was bought by Amazon for a reported $1.2 billion.
This experimental approach gave Swinmurn evidence that his unprecedented vision for an enhanced, online retail experience could be a reality. With innovation, not having that evidence can be a detriment to the solution you’re working towards.
Early in my time at CGI we presented an idea to senior management: a prototype for a garage accessory that provided a retractable light, extension cord, and compressed air. What we had not properly established was customer demand for the product. We were all convinced that it was a great product and CGI designed and built tens of thousands of them for the holiday season. Unfortunately, the demand was low, and the accessories closed out at a deep discount.
From this experience on we began thinking from Nick Swinmurn’s perspective of product ideas as a hypothesis. His hypothesis was that customers were ready and willing to buy shoes online. He then devised a test to prove or disprove it. Focusing our early prototypes on testing or exploring an area of uncertainty can drive a different approach to designing and building a prototype than what we will use for the final product.
The Prototype Journey of mHUB Member Zenblen
Zenblen Co-Founder and CEO Tom Xinyuan Zhang and Associate Mechanical Engineer Ben Salazar showcasing their tech-enabled smoothie bar at mHUB's 2021 IIoT Demo Day.
Our fellow mHUB members at Zenblen have provided an excellent example of putting these principles into action. Tom Zhang and his team had a hypothesis that consumers would buy a smoothie from a kiosk. To ensure that an innovative product like a smoothie-serving kiosk would succeed, they needed to test their hypothesis. How would customers approach buying a smoothie from a kiosk? What aspects of the process needed to be visible to drive consumer confidence in the product?
Instead of focusing their initial efforts on all the interesting and nontrivial challenges of food handling and blending, they focused on the customer experience. Many members and staff at mHUB benefited from this approach by partaking in their samples throughout testing.
Zenblen’s first prototypes actually had a person inside to perform the basic function of making the smoothie. Rather than developing that advanced technology early on, these prototypes addressed the uncertainty around consumer demand and provided insight into developing a customer experience that would succeed.
Zhang and his team gained a stronger understanding of Zenblen’s value proposition, as well as a clearer understanding of what to design based on a significantly smaller investment. After, they could focus on solving the technical issues with confidence in market acceptance.
Questions to Ask Before Getting Started
- How well do you understand your customer’s problems and what does your product solve for them?
- How well do you understand how your product fits into your customer’s world? Does your product connect into other systems or products to accomplish the ultimate customer benefit?
- How well do you understand your customer’s preferences for how they interact with the product?
- How well do you understand the overall lifecycle of the product for your customer?
- How well do you understand the barriers to customer acceptance?
- How well does your customer understand when or how to use your product?
If there is significant uncertainty around these types of questions, you should consider an intermediate prototype to better explore your customer’s engagement and use of the product. Think of them as experiments. Can you build a mock-up like Zenblen? Can you provide the customer facing part without all the underlying investment like Zappos?
Whatever your hypothesis, invest only in the part of the prototype that explores the uncertainty. Reducing the design efforts to the critical pieces. Often, we can substitute components or subsystems from other products to support exploring an idea. Ask yourself: is there a readily available building block that I can repurpose rather than design something specific?
At CGI, we put a tablet computer behind a custom bezel to demonstrate the possibilities of an LCD wall control when garage door openers only came with a push button. Can I sacrifice size or form factor to demonstrate performance/behavior? For example, if your product will ultimately have a small built-in processor, can you prototype with a readily available Raspberry Pi in a bigger prototype? If you need a basic heating element, consider taking apart a toaster oven.
The Evolution of a Problem Statement
With this perspective in mind, the problem statement for the engineer evolves to be customer centric.
Commercial Uncertainty: I want to find out if customers will use a feature
Approach: How do we simply and quickly implement or even mockup that feature without developing the whole product?
Commercial Uncertainty: I want to find out if customers prefer X instead of Y.
Approach: How do we simply and quickly create examples of each?
Commercial Uncertainty: I want to find out what level of performance customers need.
Approach: How do we create examples with different performance with minimal investment?
Finally, let’s go back to the concept of a hypothesis and experiment. Part of your plan should be to make sure that you maximize your learning from any prototype you build. What is our thesis about the customer’s needs or behavior with the product? What data or observations would validate that? Define up front what data or observations you plan to collect. What alternatives or variations need to be considered or controlled for. Make it a true test—it may be difficult for your ego, but we learn far more from product failures than from success.
Developing a physical product? See how the mHUB network can help.
If you're an mHUB member seeking product development advice, contact Bob Daniel Wayman.
