Build less to learn more
The most valuable prototypes often never become the product.
The situation
I recently spoke with the founders of a medical hardware company developing a new medical device.
After months of talking with clinicians and potential users, they believed they had identified a meaningful problem worth solving. They understood who the product was for, why existing solutions were falling short, and felt ready to begin building.
The next step seemed straightforward: develop a prototype, learn from it, improve it, and continue refining the product until it was ready for larger clinical studies.
The plan
Their expectation was that each prototype would move them closer to the finished product.
They planned to build an initial version, gather feedback, refine the design, and repeat that process until they had confidence they were building the right solution. Like many hardware founders, they assumed prototyping would be a fairly linear progression, with each iteration becoming a more complete version of the last.
They knew there would be challenges along the way, but they expected those challenges to be solved through successive improvements to the product itself.
Where uncertainty remained
The first prototypes answered some questions, but uncovered others they hadn't anticipated. As the project progressed, they found themselves building prototypes that looked very different from one another. Some explored different sensing technologies. Others were simple mockups used during patient studies. They had built well over a dozen prototypes, many of which were never intended to become part of the final product.
Instead of feeling like each iteration brought them steadily closer to the finished product, it often felt as though every answer revealed another unknown. Technical questions led to usability questions. Usability questions influenced manufacturing decisions. Conversations with customers continued to reshape the product itself.
The challenge was that they were trying to solve several different kinds of uncertainty at the same time.
What needed to be proven first
Eventually, their thinking shifted.
They stopped asking, "What's the next version of the product?"
Instead, they started asking, "What's the next uncertainty we need to eliminate?"
A prototype no longer had to be polished or resemble the finished product. It only needed to generate enough evidence to help the team make the next important decision. Sometimes that meant confirming an idea, and other times it meant proving an approach wasn't worth pursuing before investing months of additional engineering effort. Either outcome represented progress because uncertainty had been reduced.
Looking back, they realized they hadn't spent years refining one product. They had spent years systematically removing the risks that stood between an idea and a product ready for their target market.
The pattern
Many founders think of prototypes as early versions of the final product. This conversation suggested something different.
The most valuable prototypes weren't measured by how complete they were. They were measured by how much uncertainty they removed.
As each important risk disappeared, the next decision became clearer, and the product gradually took shape.
If you're in a similar spot
Before deciding what your next prototype should include, consider asking a different question.
What uncertainty is preventing you from making your next important decision?
Your next prototype may not need more features. It may simply need to give you enough confidence to move forward.