How to Use Your Technical Team to Determine Product-Market Fit

In our business of product development, we have front row seats when clients build successful markets or achieve big exits but those seats also offer a unique vantage point when a product misses the mark. Occasionally the technology can’t be made to work or the product is too costly to make, but most often, the reason for failure is simply a lack of customers for various complex and hidden reasons. In the immortal words of entrepreneur, venture capital investor, and software engineer Marc Andreessen, “the only thing that matters is getting to product-market fit.”

Many years ago, we worked on a product for a client in the radiation therapy space. After spending two years working out all sorts of technical details, conducting tests, creating documentation, and validating manufacturing processes, the client went to market and almost immediately decided to close up shop. Their recently hired CEO surveyed potential distributors and discovered the product’s market fit had some critical shortcomings. There had been a recent shift in the technology landscape and the product didn’t address the change. The client had relied on one doctor as a proxy for the entire market and their sole source of the product requirements, and it turned out that doctor was wrong.

That may be an extreme example—at least in how definitive the market lesson was—but it’s far from unique in its outcome. The question is: How could this situation and others like it have been avoided? Are there approaches to product development that minimize the risk of failure while maximizing opportunity? We’ve been thinking about these things for a long time and have a few insights to share, particularly in the context of incrementally financed startups.

First, get technical people into the field. One way to reduce risk is to engage human factors and industrial design early. We’ve had many experiences where major product definition shifts have happened as a result of sending designers and human factors experts into the actual use environment.

In one example, we were working on a product in the emergency response area that came with a preliminary specification based on our client’s strategic marketing workup. Our designer spent the better part of a week flying around in air ambulances, visiting army bases, and talking to paramedics to see how the device would be used in the field. At the end of that time, he brought back a number of critical insights that dramatically impacted the design. In this case, we were working on a second-generation device so we could gather very real feedback from the original product. It turned out there were a number of usability issues and opportunities that had not been discovered—many of which were the results of specific grounding in the field.

In another case, we worked on a product for use doing intraoperative blood diagnostics. By spending time watching surgeries with the technical founder of the company, our team identified key insights that shifted the target indication and unveiled important usability opportunities. As these examples illustrate, it is by no means sufficient to simply pass along a requirements document to a technical team. We believe it’s important that they get to observe the use environment. It helps that ISO 62304 now requires a lot more human factors work, including formative studies, but the work still has to be formulated wisely to get good value.

Second, get your technical team involved in communicating your vision. While you have the human factors engineers and industrial designers engaged, direct them to produce communication tools you can use to better illustrate the product to investors who may not fully understand or share your vision. For example, immersive virtual reality (VR) simulation experiences are quite easy to put together these days and we’ve been using them often. Through a VR simulation, potential clinical users can try the device and imagine the clinical use case in quite high fidelity. Recently, we created one for an ophthalmic surgery application that allowed the participant to play the part of a simulated surgeon. Similarly, 3D mock-ups, renderings, and partly working technical demos can all go a long way to communicate competence and vision. In addition to investor communication, these tools can also facilitate collecting improved target user feedback and potentially avoiding expensive mistakes.

Third, create incremental outputs. You can mitigate enterprise risks by having your technical team work toward incremental demonstrations. For example, technical teams often believe they should work very incrementally with carefully produced—and definitive—specification documents. They are not entirely wrong but that approach fails to respect the needs of the enterprise to demonstrate interim results to investors and it presumes you know enough to start with for full implementation. A great deal of potential and unnecessary market risk may be left on the table. It’s important to generate a stream of prototypes that allow the value proposition to be probed, which in turn will enable the team to develop a better specification.

Sometimes the use case can be only be validated by using early mock-ups or clinical prototypes. In fact, there is always a complex trade-off to be made between speed, cost, and validity of the results. For instance, the question may emerge about whether a rapid proof of clinical concept should be the next clinical goal or more definitive results should be used for regulatory submission. In many cases, especially with lower risk devices, having early clinical confirmation is the best strategy. Every situation is unique, of course, but sometimes the set of options is more complex than you first realize.

For example, we worked on a minimally invasive stroke diagnostic device and the CEO wanted a rapid proof of concept for the clinical result, even after knowing that more formal trial work would have to be redone later. He knew he could raise money at a stronger valuation if he was able to prove his concept early on.

Another reason in favor of the incremental approach is to aid in choosing between many competing clinical indications. Often, the initially proposed value proposition starts out fairly vague. Sometimes it seems clear until you scratch beneath the surface and realize that all patients or clinical settings are not equal—the value proposition may not fit them all.

For example, we worked on one diagnostic device that could aid in a variety of decisions in the ICU but the client was having trouble choosing the main one to provide real clinical time and labor savings. In that case, they did early clinical work with prototypes to help narrow down the list but there was still quite a lot of uncertainty to be resolved by using the clinical trial prototypes later. Both steps were important. The right question to consider is: What approach will produce the fastest and most cost-effective reduction in enterprise risk? Roughly translated, what knowledge is necessary to get to the next funding milestone?

It’s often said that clinical trial recruitment is a first proxy for the real market reaction to your product. The feedback from your clinical trial investigators can also be crucial to dial in the product’s usability, which in turn will be critical for real adoption.

There is a lot to be gained by leveraging technical teams in a flexible approach to product development. If used well, the teams are essential tools for value proposition clarification and communication. By engaging technical teams—particularly ID and HF in the use environment early—they’ll gain important context and may discover critical design ideas and constraints. You can also generate convincing communication tools at an early stage to reduce investment risk. By engaging technical teams in discussions about venture risk reduction, it may be possible to develop interim prototypes that can be used to garner clinical encouragement or narrow the indication.
Often, a more incremental approach to the product is the most effective balance between progress and discovery of the product-market fit.