Deep Tech Product development with minimal waste

I spent 8 years of my career in product development of semiconductors and BioMEMS devices. Working in the capacity of an engineer, R&D lead and product development manager, I was able to appreciate the nuanced and sophisticated nature of developing cutting edge deep tech products. Behind every product that makes it to the market are copious amount of hard work, confusion, stress, and waste. Even when we ignore the market considerations of product development, the technological part of product development is already fraught with mistakes, pivots, waste, and even ultimate failure. It is easy for product development teams to, in retrospect, identify what they should and should not have done but most of the learnings are overly specific and thus not transferable to development of other types of deep tech products. When I was leading the development of a bioMEMS platform product for synthetic biology, I recalled searching high and low for resources that provide relevant guidelines on deep tech product development. Perhaps because deep tech is a relatively new field that is nowhere as hot as software tech, books and articles that emphasize on efficient and effective deep tech product development in this area are lacking. Most resources that I came across fall under 2 categories: guides on finding seamless product-market fit or project management process for software-centric product development. I found the information only partially useful since they fail to address the fact that for deep tech, technology development itself is laced with extreme uncertainties. Thus, while market relevance of a product is important, it is equally important to make sure that the product can be created technologically. As an exaggeration, even if the best market-based product management practices and lean principles are applied to the development of a teleportation product, value can only be created if the technology can come together to fulfill the promised product.

Limitations of product market fit, lean practices and agile principles for deep tech development

This is the first of a series of articles that brings the focus back to efficient technology development. To develop deep tech products with as little waste and pivots as possible, I believe that an uncertainty-centric approach is necessary. This article does not discount the importance of product market fit and lean methodologies. Rather, I am trying to answer the question of how best to develop the product despite technological uncertainties to satisfy market feedback.

Value creation depends on both good product market fit and being able to successfully deliver the product

Breaking down the uncertainties

1. Integration uncertainties

Silicon wafer is a product by itself, but so is a fully packaged AI chip. The two products differ in many areas, one of which being the level of integration in the build-up of the product. Silicon wafer is a standalone material which is useful by itself whereas an AI chip is only useful as the sum of its parts. Many deep tech products are assemblies of multiple modules or components linked inextricably together in specific manner to achieve the desired functionalities. It is thus important to recognize that while each module might operate superbly by itself, the final product might still fail if not integrated properly. Returning to the analogy of an AI chip, even with the best GPU, memory and interposer, the performance of the product depends on how well these components integrate. As deep tech products grow in complexity, the number of disparate modules and disciplines that must be integrated together increases too. Uncertainties scale proportionally with the number of modules needed. Integration uncertainties can only be truly resolved with testing of fully assembled modules. Testing results can span the entire spectrum of complete success to total failure.

To perform product development despite integration uncertainties, the first step is to accept that modular success does not equate to product success. This allows the team to constantly bear in mind the importance of integration when developing the product. The second step is to list down the modules involved in no uncertain terms. The definition of what constitutes a module is more art than science but as a general rule, any components which input/output demands can be defined or any parts with significant room for R&D adjustments can be a module. In the sketch below, the boxes are the modules and the arrows heading in and out of the boxes are inputs and outputs. With the modules in place, the next thing to do is to fill in the arrows. Again, it is crucial to be as specific as possible. In the example of an AI chip, mentioning that the GPU module has pads for electrical connections is sloppy. Rather, the number of connection points, their respective functions and electrical and rate requirements etc. should be clearly laid out.

Modules and arrows

The first 3 steps should be executed during the conceptualisation phase of product development. Too often, teams leap into action without properly defining the modules and the input/output requirements of the modules in an attempt to iterate along the way. The idea is to look at the results before deciding on the next step. The common outcome of operating as such is being stuck in a rabbit hole situation of endless R&D as the team is unsure of whether the results are good enough as inputs and outputs for integration. Agile methodologies should not be misconstrued as aimless development.

The fourth and final step is to perform modular integration as soon as possible so uncertainties can be converted into certainties. As soon as the requirements for the arrows (inputs and outputs) are satisfied, integrate the modules. It is not necessary to wait for the internal mechanics of the box to be perfect before integration. Running integration early allows for faster feedback to the product development team so the learnings can be analyzed and used for the next development iteration. In many cases where results are not perfect, input/output requirements from the modules need to be adjusted before the start of the next development cycle. This is another reason why driving the internal mechanics of the box to perfection is unnecessary as the next iteration might require changes to the “arrows” which would definitely affect the mechanism within the module. Once again, make sure that the input/output requirements are clearly described prior to development. Occasionally, poor results after integration result from issues with the connectors. With the AI chip example again, no re-development of the GPU or memory etc. is needed, but better sintering paste and connection process might be required instead.

2. Feasibility uncertainties

Product development of deep tech wouldn’t be so prized if the feasibility of the technology is 100% certain. For many deep tech products, even if the academic world has multiple articles validating general science and principles behind the product, there might still be science and engineering challenges that are insurmountable. The product that Theranos was building was feasible from a science and theoretical standpoint, but the product could not be delivered as it was not feasible at that point in time. Feasibility uncertainties refer to not knowing whether our expected construction of the technology will perform the way we envision it to be. Feasibility uncertainties arise from assumptions and unproven hypothesis. Prior to developing a product, everyone has a mental image of how the product should be and all the mechanisms behind the operation of the product. In our vision, the product would fulfill a set of functionalities should all the technology click together the way we want. Between the dream and the real product, however, lies many assumptions about the technology. If these assumptions are wrong or just partially true, it can severely impact the technological feasibility of the product and might force a pivot.

Here is a simplified case study of how feasibility uncertainties and assumptions might be present during the development of a product that changed the landscape of DNA sequencing-Illumina NGS platform. A simplistic idea of the sequencing process is relatively straightforward. The DNA sequence to be read is fixed to a substrate. A/T/C/G bases with reversible terminators are added and complementary pairing occurs with the aid of DNA polymerase. Fluorescence signal is read and assigned to the correct base. Finally, the terminators are removed before the cycle repeats itself. What I just described is the mental image. Successful execution of this product requires that all hypotheses be proven true. Some of the hypotheses involved are: DNA can be tethered to substrate efficiently, DNA polymerase can operate on DNA bounded to solid support and with reversible terminated bases, the signal is strong enough to be observed etc. Each one of these hypotheses, if turned out to be inaccurate, might kill the product entirely or force a wasteful technological pivot.

To develop products efficiently (minimize waste), feasibility uncertainties must be dealt with head-on at the start of the product development process. Such uncertainties are born out of unvalidated hypotheses, so the approach is to methodically convert the assumptions to validated hypotheses. Only after key hypotheses are validated should the R&D team embark on full-fledge product development. For feasibility check, a 3-step process of list -> assess -> validate is the simplest process available.

During the “List” phase, I recommend starting with the mental picture of the desired product and running a brainstorming session to list as many assumptions as possible that might affect the ideal operation of the product. The session should be divergent so adopt an accepting attitude towards all the criticisms and doubts targeted at the technological feasibilities of the product. This list of assumptions should be a living document that can be edited at any time to improve product development flexibility. It is common for assumptions to be missed out during brainstorming sessions that are only discovered midway through development. There is no shame in adding new assumptions along the way. The first “List” session should be conducted during the design or conceptualization phase. Jumping straight into product development before identifying the assumptions generally results in poor resource prioritization and eventual waste.

In the “Assess” phase, rank the listed assumptions to better prioritize R&D efforts. Each assumption should be assigned scores in 3 dimensions: Impact on product, degree of uncertainty and ease of validation. An overall score can then be assigned to each assumption through summation, multiplication, or other complicated equations etc. Prioritization is again more art than science so any reasonable method can work. I tend to believe that impact on product is the most important factor to consider and will rank high impact assumptions at the top. In addition, some product managers might choose to run difficult validations first while others choose the easy ones first. I prefer to mix them together to even out the R&D load but again this is personal choice.

In the final “Validate” phase, actual heavy lifting such as creating a validation plan and testing the accuracy of the assumptions are performed. This is the most time-consuming phase. Some validations are as simple as reviewing literature and resources online. Some can be done with simulations. Many validations, however, are more involved and require experimentation and prototyping. For such, I propose first having an approved validation plan before executing the plan. Regardless of the complexity of the work, results of all validations should be reviewed before being marked and updated as complete on the assumption list.

3. Blind spot uncertainties

The Johari window was made famous by then US Defence Secretary Donald Rumsfeld. Feasibility uncertainties mentioned above are known unknowns. The most troublesome quadrant within that framework is the unknown unknowns, also known as blind spots. Blind spots cannot be dealt with ahead of time. Generally, the more novel the product is, the more blind spots there will be during the product development process. For first-of-its-kind product, blind spots are inevitable. Technological blind spots are assumptions that the product development team was unaware of until it shows up as blockers that negatively affect further development efforts. Thus, they always manifest themselves during the R&D development stage and must be addressed swiftly.

Here, I draw on my own experience to illustrate an example of a technological blind spot. When I was leading the development of a device for single cell trapping and release, I had a comprehensive picture of how the different modules and materials can come together to achieve the desired functionality of dielectrophoresis trapping and release. Multiple assumptions around the actuation mechanism, Poisson distribution of cells, stickiness of cells etc. were carefully laid out for feasibility validation. Right when everything was going smoothly, the team realized that cells were not expressing the way they usually do. Suddenly, in the middle of R&D development, we realized that there was an unidentified assumption – cells will express as per usual despite dielectrophoresis manipulation and being confined in a chip’s microchamber. This newfound assumption requires urgent attention.

To develop products despite the unknown unknowns, we have to put in pre-emptive measures to be as omniscient and prepared as possible. The most effective prevention approach is to allow for comprehensive assumption brainstorming sessions with as many experts as possible. I cannot stress enough the importance of having this done early during the development cycle (conceptualization phase) and also multiple times during the R&D development phase itself. One’s unknown might be another’s known. Thus, having as many people and experts involved as possible is important. In addition, our ability to project into the future evolves with the product so multiple sessions can elucidate previously unknown unknowns.

While we cannot know for sure the exact technological blind spots we have, we can set aside time contingencies and blind spots discovery plans to deal with the situation should they arise. Time contingency is the most important tool in managing unknown unknowns. There is no golden formula for how best to set aside buffer time for blind spots, but as a general rule, the more innovative a product is, the more time should be set aside for blind spots. This additional time is used for product pivots and additional validation work. For instance, if a pivot is expected to represent a quarter of the product, then an additional quarter of product development time should be allocated as contingencies. The same math can be used for validation work. If unplanned assumptions are expected to be 10% of the total assumptions, allocate an additional 10% time for validation. Implementing systems such as development delay analysis can help to identify blind spots as early as possible.