Deep Tech Product development with minimal waste (Part C)

In my previous posts, I explored six uncertainties that deep tech product development faces. In this article, I would discuss three more uncertainties related to the operational aspects of deep tech product development. 

Breaking down the uncertainties

7. Resource uncertainties

People are the most important aspect of product development. Assembling the right team is usually more important than having the right product. “Multi-disciplinary team” is a term used rather loosely to describe all product development teams but for deep tech, the chasm between disciplines is always more than just subtle distinctions between front-end, back-end, testing etc. The science involved in deep tech product spans such a wide range of disciplines that technical communication and understanding across disciplines are troublesome. I call this the disciplinary gap, which is a measure of how different one discipline is from another. The disciplinary gap between two disciplines A and B can be measured by the time it would take for an average professional in discipline A to become a professional in discipline B or vice versa. If a person with no data science background can become an entry level data science professional with a 3-months intensive bootcamp session, then the gap is 3 months. Similarly, if a person with no knowledge of chemistry can become an entry level chemist with a 2-year program, the gap is 2 years. Deep tech products characteristically cover a wide range of technologies and are developed by teams with large disciplinary gaps.

Much like creating a dish with many different cuisines, deep tech products involve many different disciplines

Deep tech product development is sometimes like creating a dish made up of multiple different cuisines. The problems posed in trying to mesh people from very different disciplines together are:

• Definition and grouping of discipline: Because of the sheer number of disciplines involved, the commonsense thing that management tries to do is to group disciplines together. Because management is rarely made of experts in every single discipline, identifying the exact discipline and making the right decision about grouping can be challenging. The art of grouping requires both knowledge of the exact name of the discipline and understanding of similarities between disciplines. Biology is a discipline but so is molecular biology. Poor grouping results in skillset mismatch and difficulty with assembling the team.
• Uneven workload distribution: Much like the pie chart above, the product is composed of multiple disciplines but at varying fractions. Resources from some disciplines are only mildly involved but their outputs are nevertheless vital for the product. Hiring a person to plug that 1% work sounds silly but not having that work done results in product failure.
• Communication: Communication issues due to disciplinary gap happen on a daily or weekly basis. This is not to be confused with communication issues due to lack of soft skills etc. The larger the disciplinary gap, the harder it is for parties to see eye to eye on technical subjects. These differences can be due to unspoken assumptions, unspecific instructions, or lack of understanding towards technical jargon. For instance, an electrochemist might be looking for a chip with platinum electrodes on it to run an electrochemistry application. This person approaches a MEMS expert and they came to the common consensus on a simple design with platinum line on silicon oxide. Upon receiving the finished chip, the electrochemist runs his experiment and is appalled by the fact that the platinum line appears to ‘corrode’ quickly during the experiment. He angrily blamed the MEMS expert for poor quality chip. Yet, the MEMS expert revealed that EDX data clearly showed that material was not the problem. One month into troubleshooting, they realized that the culprit was the Chromium adhesion layer between silicon oxide and platinum which reacts vigorously in the electrochemical reaction leading to the “Platinum corrosion” phenomena. This is an example of an unspoken assumption negatively affecting communication which results in unexpected delays. The electrochemist assumed that Platinum lies directly on top of silicon oxide as he is unaware of the need for the adhesion layer. The MEMS expert assumed that everyone knows about the need for an adhesion layer as it is commonsense requirement to all microfabrication experts.
• Task allocation: Depending on the way the disciplines are defined and grouped, there might be product development tasks that do not lie squarely in any defined disciplines. For instance, management might have decided to allocate an electrical engineer, an organic chemist, and a material scientist to the development of a product. Part of the product requires electrochemistry. Who should be assigned to the electrochemistry task for maximum efficiency? Should it be group work or individual effort?
• Resource development: Again, depending on the way the disciplines are defined and grouped, resources might be required to learn and execute tasks outside of their domain. To some, this is a tall order especially if they have dedicated much of their lives honing their understanding in a specific discipline. Disciplinary gap varies from one person to another. For deep tech product development, resources who exhibit lowest disciplinary gap across a multitude of disciplines (adaptable fast learners) are most desired.

These 5 categories of problems make resource management for deep tech product development challenging. Resolving resource uncertainties is about understanding what resources are needed for product development and how resources can be utilized efficiently.

Resource uncertainties have to be addressed right from the conceptualization phase of product development. Square and arrow diagrams and tentative applications/measurement metrics are concepts discussed in earlier posts (Deep Tech Product development with minimal waste). Those should already be done prior to resource planning. For each module, application or measurement, clearly define the discipline needed to develop it. The discipline should be as specific as possible. For instance, if the discipline is electrochemistry, do not simplify it as chemistry or electrical engineering. Being specific places a lot of burden on the planning team but it is a necessary step. When unsure, conduct more study to ascertain the disciplines. If the disciplines are not defined right, resources will not be assembled correctly. This would result in product development delays with multiple white elephants sitting around.

Once all the disciplines are spelt out, decide on whether a single resource should be assembled for each discipline or if disciplines can be grouped together. Consider the disciplinary gap between different disciplines and group closely related disciplines with small disciplinary gaps together. During grouping, also consider the workload of each group. For instance, electrochemistry might have smaller disciplinary gap with chemistry than material science, but if other chemistry already take up an estimated 25% of the total workload while material science stands at just 5%, consider grouping electrochemistry under the material science discipline.

Only begin assembling the team after disciplines are grouped together. When picking out people to join the product development team, focus not only on how the skillsets that they already have fit the specific discipline but also on their ability to work and learn outside of their domain. This can either be reflected from previous experiences of the candidate or identified through interview presentation. For instance, since electrochemistry and material science are grouped together in the previous process, in interviewing a material scientist, I might require the material scientist to run a quick study on certain electrochemistry mechanism as part of 2nd interview round. The test is not about getting the right answer, but about their willingness and ability to venture out of their discipline.

Mid-way into product development, the team might run into technical issues that do not quite seem to stem from any single discipline. This is common for multi-modular products. Set in place an issue escalation process and issue prioritization system so the issues can be brought to light and prioritized for resolution. If the problem is a severe blocker, adopt a multi-pronged approach as much as possible. In such a situation, I recommend solving the issue in parallel by tweaking the problem statement and constraints. Using the same “Platinum corrosion” problem again, the adhesion layer is neither solely a MEMS nor an electrochemical issue but rather a compatibility issue. Using parallel task assignment method, the MEMS expert can be assigned the task of fabricating a device that does not result in “corrosion” given the same electrochemical process. The electrochemist, however, can be tasked with creating an electrochemical system that does not result in “corrosion” given the original device. Parallel development thus takes place and regardless of where the final solution comes from, the entire product development team wins.

8. Timeline uncertainties

With any product development, it is important to provide internal and external stakeholders with time estimates. For novel deep tech products however, timelines are generally wild estimates that err on the side of optimism. The effort to results relationship is poorly established in many deep tech product developments because the technology belongs to a field that is hitherto poorly understood and therefore underdeveloped. Since the amount of effort required to achieve the desired set of results is uncertain, the time required for product development is also uncertain.

Relationship between efforts and results for different types of product development

The most comfortable type of product development utilizes predictable and well-understood technologies. For example, if the goal is to develop a game like Pac-man, an accurate product development timeline can be estimated before any work begins. Results are easily tracked and scale with invested efforts. There might still be delays during product development but even so, it is easy to assess the progress and estimated development time remaining. Note that this is the time it takes for the R&D team to create a product that meets the pre-determined requirements and not the time for product-market-fit to be established.

Most innovative deep tech products utilize at least one piece of poorly developed technology. Development of such technologies are characterized by breakthroughs. If breakthroughs are necessary components of the product, then product development timeline cannot be estimated since breakthroughs are unpredictable. Imagine this stretched example of a product that relies on room temperature superconductor as a critical module. This requires a scientific breakthrough which might happen in a month’s time or after 10 years. Such products might encounter early breakthroughs if the development team is lucky, but it is equally possible to face situations of late breakthroughs or no breakthroughs.

Clear timelines, however, are important for a variety of reasons. To internal development team, clear timelines help with task management and resource allocations while to the company at large, clear timelines help to align ancillary development initiatives with other business units. Development time is also an important factor to consider for financial and strategic calculations as firms need to know the required runway and ROI. To the external world, timelines are used by investors, partners, and customers to prepare for their engagement with the company. With novel deep tech product, all of these benefits are in jeopardy.

Strategies to deal with timeline uncertainties falls under either of these two categories: uncertainty minimization or loss reduction.

Uncertainty minimization refers to incorporating actions and plans to reduce the intrinsic uncertainties of the product. The clearer the effort to result relationship is, the better the timeline estimates are. This can be done by positioning the team closer to the breakthrough point or transforming abrupt breakthroughs into predictable technologies. A common tactic to achieve this is to divide the technology into tiny chunks to simplify the problem. Building a rocket is complicated but creating a heat shield is somewhat simpler (albeit still challenging during re-entry). For deep tech products, modular development is key as it is the most effective tool for cutting down uncertainties (Deep Tech Product development with minimal waste). Even after modularization, timeline uncertainties might still persist for modules with underdeveloped technologies. Another tactic to employ is uncertainty avoidance by using established technologies as much as possible. For instance, perhaps the original plan for a biotech product was to use self-developed reagent kit alongside self-developed device. Consider reducing the uncertainty involved by using existing reagent kits instead if those pair well with the device. There is no prize for creating a final product where every single component was developed from scratch. Utilizing short-cuts by incorporating existing technologies as much as possible allows for more reliable time estimates and quicker market feedback after product launch. Lastly, keep in mind that one’s uncertainty might be another’s certainty. If budget and planning allow, consider building a team to plug large uncertainty gaps. Instead of groping around in the dark for the elusive breakthrough, hire someone who has already made similar breakthroughs. If the goal is to develop a Pac-man game, a software engineer who has previously developed snake attack game can likely provide a much better timeline estimate than a graphic designer can. Lastly, it is always helpful to perform feasibility studies before actual product development or during the early phases of product development. Feasibility study should not be confused with prototyping. It should be focused on addressing modules with the greatest uncertainties so the breakthrough point can be reached before a full-blown development effort gets underway.

Loss reduction is a technique used to limit the damage imposed by timeline uncertainty so that in the absence of breakthroughs, the time and resources spent on development are limited. A cap on effort or time investment is a good start. When developing novel technologies, it is often fairer to measure output instead of outcome. For instance, if the development team tried 10 different unsuccessful approaches to solving the problem, that is an output of 10 trials but the outcome is unsuccessful. On the other hand, if the last approach turns out to be successful, the output stays the same but now the outcome is a successful one. Since novel technologies run on breakthroughs, which are unpredictable, a good mindset to adopt is to measure the output and accept the outcome. This transition in mindset provide better product development time estimates since one can predict the time required for 10 trials with relative accuracy, but it is difficult to estimate when the next breakthrough will come. Product development waiting on the breakthrough to happen might be endless, but product development based upon N number of trials before making a kill/switch decision has a predictable timeline. In many cases, different technologies can be utilized to create the same product. Putting a cap on the number of trials per technology means that N number of attempts will be invested in a technology to find a breakthrough within the defined timeline, but in the absence of desired results, the same approach will be adopted for the next technology.

9. Scale-up uncertainties

One of the final tasks of product development on the engineering side is production scale-up. The key goal of scale-up is to increase production volume while reducing cost without any compromise to quality. In fact, through continuous improvements, quality should only improve after scale-up. For deep tech however, the scale-up process poses unique challenges since novel technologies generally also require innovative apparatus for production. In extreme cases, development of scale-up facilities can by itself be another deep tech product development except that in this case, the “market” and requirements are much clearer.

In almost all product development, prototypes and beta products are initially created in small batches or in small-scale production facilities. In this phase, the focus is on making the product work without much consideration for scaling-up. When developing products in small volume, many of the methods used for fabrication are extremely time and manpower consuming. In this stage, I like to think of each product as a boutique product handcrafted for the final application. For some technologies, the apparatus used during development can be readily scaled-up to handle large volume production. As an example, if centrifugation is a required step during production, simply selecting a suitable rotor can result in a 50x increase in production volume without excessive operational overhead. For other technologies, production apparatus during product development were cobbled together or operationally intensive. Scale-up is thus problematic since hiring more hands to deal with higher volume is not a sustainable solution. In some unfortunate cases, the product itself is simply not scalable from a production standpoint and this might then require a product redevelopment. For example, if the product is a wearable device made up of 5 different layers of foldable materials, each with a different form factor and method of connections with adjacent layers, it might be an incredible feat to assemble the product by hand during the development phase but production scale-up will be an arduous task. In fact, scale-up challenges for deep tech products are why wizard of oz or concierge prototyping do not work. These tactics are useful for products with little to no scale-up challenges whereas for some deep tech products, a well-received product might not be production friendly.

Product cannot be scaled-up without excessive development efforts such that it is more economical to redevelop the product instead

Other lesser challenges with deep tech product scale-up are production volume estimates and minimum production volume requirements. With many deep tech products, the market is not validated and therefore, the optimistic and pessimistic estimates for the product might vary wildly. In such situations, it is difficult to determine when to scale-up and how much to scale-up. Thus, allocating the right amount of investments into production is tricky. Even if the desired production volume is well-defined, it might be below the minimum acceptance threshold for vendors and contractors. Perhaps the demand for the product is a hundred devices per month for the entire year which might translate to 1 full 12-inch wafer per month. No vendor would go into a contractual agreement to fabricate products at such low volume.

Since the most crippling problem is product redevelopment, having in place a proper check-and-balance system to ensure scale-up feasibility evaluation at every product design and pivot session is very important. The purpose of this review is to put a stop to employment of specialised techniques even during prototyping and beta product fabrication stage. Avoid using pulsed laser deposition when it is possible to use CVD or sputter for example. This prevents the development team from kicking the can down the road.

To address demand issues, consider boosting internal demand for the product so product volume estimates can be both higher and more predictable. Many deep tech products can be applied to a wide range of applications and so towards the end of product development lifecycle, product application development should be initiated to validate the usefulness of the product in various applications. Products should never be consumed internally for the sake of creating demand. Rather, it should be used to validate applications that can improve the marketability and value proposition of the product. The other advantage of internal demand is its flexibility. Internal demand can be scaled-down if there is a sudden spike in external demand which puts pressure on product inventory.

It is generally impossible to do just-in-time production for deep tech as production technologies are too immature to be that efficient. To ensure that products are ready when they are demanded, and to have order volume that fulfil the minimum acceptance requirements from the vendor side, it might be necessary to maintain a stockpile of the product. However, stockpiling might be an issue if product shelf-life is short or if product is quickly replaced by newer revisions. Thus, stockpiling should go hand-in-hand with internal demand planning to ensure useful applications can be validated without excessive warehouse hoarding. To extend the shelf-life of the product, consider fragmenting the product into shelf-life resistant and shelf-life sensitive modules and see if final product assembly can be executed only upon demand. For instance, perhaps the chemistry is the most time-sensitive component of the product. If the chemistry can be injected or activated in the product upon demand, then the shelf-life of other components of the product can be dramatically increased.