Deeptech product roadmapping

Unravelling strategies for bridging the gap between technology and product

One of the first tasks you will do as a deep tech product manager is to facilitate the creation of a roadmap. Established product roadmapping frameworks serve as great mental models for organising and prioritising product initiatives, aligning teams, and ensuring that everyone is working towards the same goals. But do these tried-and-tested frameworks work in the ambiguous and future looking world of deep technology products?

Lets explore a few popular frameworks:

1. RICE (Reach, Impact, Confidence, Effort): RICE focuses on four key factors: reach (the number of users who will be impacted by the initiative), impact (the positive impact the initiative will have on users), confidence (the level of confidence in the success of the initiative), and effort (the amount of effort required to implement the initiative). Each factor is assigned a score from 0 to 3, and the overall RICE score is calculated by multiplying the individual scores. Initiatives with higher RICE scores are typically prioritized higher. In deep tech RICE immediately falls flat because of the ambiguity you’ll face in scoring your Confidence and Effort even if you can extrapolate Reach and Impact.
2. MoSCoW (Must Have, Should Have, Could Have, Won’t Have): In this framework, features categorized into four groups: Must Have (essential features that the product cannot exist without), Should Have (important features that would significantly improve the product), Could Have (non-essential features that could be added if time and resources allow), and Won’t Have (features that are not currently being considered). This framework helps in ensuring that the most important features are prioritized and that the product roadmap is focused on delivering the most value to users. This is partially useful in deep tech to define the first product . However, as products require many years of development so you may have to iterate your MoSCow over this period and will be subject to change.
3. Kano Model: The Kano Model classifies features into five categories: basic (features that customers expect and their absence would cause dissatisfaction), performance (features that meet customer expectations and provide satisfaction, with increasing satisfaction as the feature’s performance improves), excitement (features that exceed customer expectations and cause delight), indifferent (features that have no impact on customer satisfaction), and reverse (features that customers dislike and their presence causes dissatisfaction). This model relies on customer expectation and feedback data. While this might be applicable once your first product hits the market, KANO is not a framework designed for zero to one new technology products.
4. Jobs-to-be-Done (JTBD): The Jobs to Be Done (JTBD) framework has emerged as a powerful tool for understanding customer needs and prioritizing products to address them effectively. Unlike everyday consumer products, where the functional and emotional needs are more readily apparent, deep tech products often address complex, nuanced problems that may not be immediately recognisable to potential users. Furthermore, the target audience for deep tech products is often composed of highly specialised customer personas with in-depth knowledge of their respective domains. This can make it challenging to gather comprehensive insights into their needs and aspirations using traditional JTBD methods, which often rely on customer interviews and surveys. That said, JTBD is a great framework to identify the customer problems that your technology could potentially solve and the existing workarounds or compromises customers are making in the absence of your technology.

If such well established frameworks don’t quite work , how do we approach the creation of a roadmap?

Though there’s no universal solution , consider the following strategies for creating impactful roadmaps, serving as a guiding principle for numerous prioritisation decisions leading to your product launch.

1. Dive deep: Achieving a comprehensive grasp of the technical and contextual elements essential for adopting your technology is crucial. This necessitates collaborating with experts internally and externally in relevant fields. By developing a holistic understanding of the technology’s development timeline, potential barriers to customer adoption, and variables like regulations and competitive landscapes, you’ll gauge the available time for technology advancement. A vital gauge to monitor is whether your technology can be developed sufficiently before your market for this application gains momentum. For example : If your technology solution reduces the overall cost of production of a new augmented reality based consumer electronics device but is not in time before even the panning of the production ramp of these devices , then your product while technically successful will fail commercially because of a bad roadmap timeline.
2. Problem-Centric roadmapping: Identify the underlying technology problems that needs to be solved for the success of your envisioned product. These should form a core part of your roadmaps in the form of technology de-risking projects, proofs of concept or even collaborative trials. Designing the right number of such de-risking project will automatically drive prioritisation of the technology to pursue for your products.
3. User-Centric Validation: Nurture and engage with potential early adopters throughout the product development process to gather feedback and ensure that the proposed solutions align with their roadmaps, vision and expectations. There is a good chance your product will interest customers’ R&D teams who are put in place to look around corners for new technologies that would keep their businesses differentiated in the future. They are a great first port of call for collaboration and form the a perfect bridge to your eventual customers who will not only define your product v1.0 but also help adopt technology in production. This can be a long process. So early engagement and persistence through long technology validation cycles not only builds the trust that is required for a customer to de-risk their investment in your new deep tech product but also helps you refine your product. A product manager’s role is critical here to ensure you take input from customers while not derailing your ultimate vision of the product.
4. Embed your North Star vision in to your team culture: Deep tech products are where innovation usually meets high degree of complexity and ambiguity. One can fall into various rabbit holes trying to solve unsolvable problems or get distracted with new innovations that in itself are ground breaking but might cause delays in your product development. Oversight on all areas of day to day decisions in product development is simply not feasible or practical. Therefore a North Star vision is pivotal and should be established before any roadmapping exercise. A clear North Star vision encapsulates the essence of the product, aligns teams, and serves as a compass for decision-making. Ideally, this vision should become part of the vernacular of the organisation and every decision should be debated against this vision. Product roadmaps should incorporate decision making junctions and demonstrate prioritisation to achieve this vision.

Deep tech product roadmapping is usually a balancing act of achieving your vision and finding leading indicators for product adoption. Are you a product manager who had to adapt traditional frameworks or even create new ones for your deep tech products? I’d love to hear your thoughts.