Efficient deep tech product development framework (Part 2)

Published on 15 April 2024 at 18:15

Bad news: Technology development of deep tech is difficult because it is fraught with uncertainties.

Good news: This framework can help to elevate your product development skills so as to maximise your chances of success while reducing unnecessary waste


In my last post, I explored 5 different types of development work and how feasibility stage-gate process can help to minimise product development risk and waste. For products that made it through feasibility study, here is a final model for product development proper.

If the feasibility study phase concludes successfully, the product development can progress to the second stage-gate process, following a typical 5-stage workflow. Ideally, after the feasibility study, the primary focus of the development work should shift to building the product rather than exploring its feasibility.

 

However, due to the inherent uncertainties in deep tech product development, iterations may be necessary during the development and testing stages. New insights gained from these stages might challenge initial product concepts or plans. Therefore, it's crucial to maintain flexibility and be prepared to revisit and restructure the product as needed.

Development stage-gate process with iterative properties

 

Conceptualisation: Charting a clear path

By the end of the conceptualization stage, leaders should be able to answer the question, "What is the product?" This requires them to articulate a concrete idea of the product's nature and its value proposition, convincing both themselves and others of its worth.

  • Value proposition: Justifying the cost and effort of product development involves illustrating the value the product can bring to the market, focusing solely on the Serviceable Obtainable Market (SOM). A clear market scope enhances product definition. For instance, a company working on novel solid-state battery technology shouldn't attempt to capture the entire energy storage market but should target specific applications like city-use electric vehicle energy storage requirements. Clarity in value propositions from the outset minimizes pivots and optimizes resource utilization. Unlike SW products, it is timely, costly and technically difficult to perform demo iterations every month or so to fine-tune market needs. Thus, value propositions should be as clear and as accurate as possible right from the start to minimise pivots and wastes.
  • Identify applications: Applications and value propositions are closely intertwined. Once the value proposition is established, target applications should be clearly articulated, along with consideration of potential future applications beyond the primary value proposition. This strategic planning ensures that the development team has clear direction post-initial product completion.
  • Value chain identification: After the feasibility stage, assuming technical viability, attention turns to the value chain. Scrutinize the value chain to understand existing gaps and explore strategies for ensuring readiness during product launch.
  • Long-term roadmap: Drawing on the established value proposition, list of applications, and value chain map, chart a strategy for the product's evolution over time, anticipating incremental application development and value chain maturation. Acknowledge the dynamic nature of deep tech due to uncertainties around technology, emerging market and technology insights. When roadmap changes, it is called a pivot. It is alright to have pivot as new information about market, technology etc. comes to light. It is not acceptable to jump straight into aimless development and trust that a roadmap would magically surface eventually as this results in scattered development initiatives which are wasteful.
  • Modularisation: Referencing the feasibility stage results and the product's value proposition, break down the product into basic modules using a box and arrow diagram. This high-level understanding of the product fosters alignment among stakeholders.

Planning: Balancing vision with realism

While the conceptualization stage lays out the vision, planning is about preparing everything necessary to realize the dream product.

  • Details of modules: Like the planning stage during feasibility stage-gate process, the first step is to fill in details of the modules inside the boxes of the box and arrow diagram. Populate the box and arrow diagram with detailed module information, including technological workings and alternative options. Rank different options to prioritize development efforts. The box and arrow diagram should be the one-stop shopping document for acquiring a detailed technical understanding of the product.
  • Assumptions review: Like the feasibility stage-gate process, this step is to conduct a deep dive into the technological assumptions associated with the product. Conduct a deep dive into technological assumptions with as many experts present as possible resulting in a refined list of critical assumptions along with their “risk ranking”. This list should be much shorter than during the feasibility stage-gate process where the greatest uncertainties were tackled.
  • Modules and skill set convergence: Clearly define required skills for technology development within modules or assumption validations. Group skills based on technological gaps to optimize resource allocation. Produce a skill set list and corresponding role description for the required resources once this part is done.
  • Measurement metrics: The goal is to build a product in the deep tech space. Products as such comes with metrics to determine their acceptability and applicability. In this stage, specify product metrics and measurement methods, with provisions for metric evolution based on market and technology feedback. Revisions are acceptable if they are accompanied by comprehensive review process. Develop product to fulfil the metrics and not vice versa. Due to anticipated changes, maintaining a document to describe the metrics and track the evolution of the metrics is vital. The deliverable here is a metric tracking document.
  • Performance requirement: Establish performance targets aligned with measured metrics. The exact numbers to hit are what the development team should strive towards. While the values might be shrouded in mystery at the start of development, put in your best estimate and set the bar. Like measurement metrics, allowing for revisions to the sunset criteria based on evolving market or technological landscapes.. This is again acceptable if due diligence is performed so the bar is not shifting on a whim. For example, if the deep tech is to develop solid state batteries for EV and the amp-hour rating of current lithium ion batteries suddenly doubles, market pressure warrants a change to the development team’s sunset criteria.
  • Development milestones: Long-term development roadmap was determined during the conceptualisation stage but milestones leading up to product realisation should be planned here. Define key milestones leading to product realization and evolution, ensuring alignment with target application needs. Because integration is such a big part of most deep tech products, the first fully integrated product is generally a major milestone. At the end of this step, a Gantt chart with the milestones flagged should be ready.
  • Team segmentation, management and goal: In this step, formulate a plan to divvy up the work to develop the product most efficiently. In deep tech product development, we rarely see a team of individuals all working on the same item all at the same time. If there is a vanguard team and a core team working in parallel, also decide on how both the work allocation and information sharing can be managed. The Gantt chart should be updated with details once this step is done.
  • Scale-up review: Evaluate technologies within modules for production risks, adjusting priorities as needed to optimize scalability. References to the box and arrow diagram is particularly helpful. This can help to re-shuffling of technological priorities within the boxes and might spark a re-design. While there are multiple factors to consider during scale-up, some of the most common ones are: availability of vendors, reliability of production technologies and accessibility of materials. At the end of the review, a report with a brief description of the anticipated scale-up plan, along with a risk level grading for scale-up difficulty is ideal.
  • Operational planning: Plan budgets and timelines with contingencies to handle uncertainties, ensuring realistic project management. Budgeting should also consider the expected value of the target application. Sometimes, the reality of the time or budget necessary for product development might trigger adjustments to the Gantt chart or even the roadmap.
  • Value chain engagement plan: In the conceptualisation stage, the value chain and its gaps were identified. The planning stage, develop action items to address identified value chain gaps, engaging with partners early to synchronize value chain readiness with product launch. Alternatively, companies might pursue joint development efforts. In some cases, the company might try to cover more ground by also developing the value chain in-house. Regardless of the approach, it should be executed early so the value chain doesn’t have to play catch up after the product is ready. The value chain document should be updated with the selected tactic and its execution plan.

Development: Bringing ideas to life

In the development stage, scientists and engineers take the lead, guided by management to ensure meaningful progress and timely issue resolution.

  • Clear development goals: The Gantt chart, along with all the documents prepared during planning stage, act as the map for product development. During development stage, review the goals frequently and keep the team reminded of the objectives. This can be done through quick weekly meeting. Also, management should be the gatekeepers of whether development efforts are completed. A mix of output and outcome progress tracking methods should be used for exploration-based and development-based projects respectively.
  • Quality report and tracking: Take measurements as soon as possible according to pre-defined metrics and record the data. Every prototype that is fully integrated should come with a quality report. A database keeping track of the measurement metrics should be maintained so the progress of development team can be tracked.
  • Frequent technical review: During development, host technical review meeting whenever tasks are completed or when there are delays. The 3 purposes of technical reviews are:
    • Brainstorm and execute problem solving steps in the event of delays. If new assumptions are discovered, add that to the assumption list and decide if the assumption warrants a validation check
    • Make sure the due diligence is done right for tasks that are completed.
    • Scale-up risk reviews
  • Value chain development: Initiate value chain development activities alongside technical development efforts.
  • Timely integration: Integrate modules early, focusing on meeting input-output criteria rather than perfecting internal mechanics. Only focus on perfecting internal mechanics once the arrows and delivered.
  • Parallel problem solving: Leverage interdisciplinary problem-solving approaches for complex challenges, defining problem statements tailored to different disciplines.

Testing: Showcasing product excellence and application viability

During testing, the roles of marketing and field service teams expand, while technical teams concentrate on optimizing quality and processes. Field service teams should engage deeply in the value chain and application development. The marketing team should progressively become more involved by crafting clear product messaging that positions the product as delivering turnkey solutions.

  • Quality: Externally, quality is judged by batch consistency and adherence to specifications. Internally, teams must establish checks to detect defects early, enabling swift implementation of rework or scrap protocols. Development teams should focus on:
    • Developing in-process checks that reliably predicts final product performances based on mid-processing data.
    • Eradicate superfluous processes to reduce unnecessary defects.
    • Begin tracking quality metrics to monitor reliability.
  • Application testing: Another critical aspect of testing is evaluating how well the product performs in real-world applications. This testing should encompass a mix of internal and external assessments, closely mimicking actual use cases. For products designed for diverse applications, testing should be comprehensive.
  • Metrics finalisation: It's common for development teams to discover during testing that existing metrics are inadequate or irrelevant for assessing product performance in real-world applications. This stage involves continuous feedback between application testing and metric tracking. The final performance metrics list should accurately describe the product's behaviour in application scenarios.

Launch: Bringing products to market and into production

  • Resource reallocation: During product launch, the original development team may find themselves in a transitional phase. While their technical expertise may not be as directly applicable, they remain valuable contributors to company growth. The vanguard team should continue exploring cutting-edge technologies, while the core development team can shift focus to application development or work on new/upgraded products.
  • Showcasing peak performance: At launch, it's crucial to communicate the product's capabilities accurately. Rather than overstating specifications, highlight values that reflect the product's reliable performance. For example, if a DNA sequencing device has a capacity of 1 million sequencing spots but typically achieves 90% efficiency, it's prudent to advertise a throughput of 900k..
  • Tech transfer: Tech transfer involves transferring technological knowledge from the development to the manufacturing team. Essential handover documents prepared by the development team typically include:
    • Standard Operating Procedures (SOPs)
    • Historical quality and metrics reports
    • Product specifications
    • Experimental records
    • Theoretical descriptions
  • Value chain development: It's acceptable to launch a product even if the market value chain is still evolving. Often, value chain development accelerates with the presence of mature products in the market. Product managers should proactively engage with upstream and downstream partners to expedite value chain development as it is a win-win situation for both parties.
  • Internal application development: Product can only improve with sufficient viable feedback. Feedback can be provided by the market but in the case of deep tech, demand is generally low in the first few years. To enhance product quality and bridge the gap between early adopters and the broader market, internal application development is crucial. Product managers should drive the development of applications aimed at addressing market challenges, leveraging feedback to refine and improve the product.

In deep tech, product development requires a delicate balance between flexibility and rigidity. Trying out numerous routes or alternatives (agility) can be prohibitively costly and time-consuming. Yet, being overly rigid is impractical due to the myriad technological and market uncertainties that often necessitate pivots based on new insights.

With this framework, we aim to strike a balance that avoids misled rigidity and wasteful agility, enabling the efficient development of deep tech products.

I hope this article has been useful in providing a robust framework for deep tech product development. Feel free to leave a comment or reach out to me as product development is, arguably, a subjective practice.

Add comment

Comments

There are no comments yet.