Over a decade ago, when I began my PhD, I knew I wanted to move into industry to create science-based products. I envisioned a straightforward path: invent intellectual property (IP), persuade the university to patent it, and spin out a start-up. However, joining a spinout formed by my PhD advisor revealed that IP creation is only the beginning of the commercialisation journey. The real challenge lay in Product Management—the discipline of validating customer needs, aligning stakeholders, and delivering viable products.

Early Days at the Spinout

Bridging Science and Business

Our spinout licensed several pieces of IP, including the one I developed during my PhD and Postdoc. We aimed to build precision diagnostics, but we lacked foundational Product Management practices: product–market fit, minimal viable products, and systematic voice-of-the-customer research.

Build vs. Buy: A Hard Lesson

We dedicated a year of precious angel funding to setting up a BSL-2 lab and implementing a quality system to legally sell our next-generation sequencing (NGS) cancer test. However, we neglected to consult oncologists about which biomarkers they truly needed. Instead of focusing on a small set of actionable biomarkers, we developed a 1,000-gene panel that didn’t address their immediate needs. Additionally, we built our own Laboratory Information Management System (LIMS) from scratch instead of evaluating proven third-party tools. These oversights stretched our timeline and budget by approximately 100%.

Transitioning to Product Development

Recognising the delays, the company decided to accelerate our path to accreditation by moving me from the lab to product development. I inherited the LIMS project midway and adopted a lean, agile approach—focusing solely on the essential features required for certification and deferring "nice-to-haves" for post-accreditation. This strategic pivot halved our time to launch. Although our product wasn’t a traditional software offering, I was managing complex decisions and orchestrating cross-functional teams of scientists, engineers, and external stakeholders.

Joining a Public Med-tech Company

Partnering Under the Science-Led Structure

When I joined a public med-tech company developing cutting-edge gut-health diagnostics, the company was still operating under a science-led structure. Product and engineering teams worked in separate business units, making cross-functional collaboration challenging. To bridge this gap, I actively partnered with engineering squads by attending their stand-ups, understanding their workflows, and building trust. I saw this outreach as a way to align product and engineering efforts even before we moved to a product-led model.

Embracing Agile and Software Collaboration

Through my collaboration with engineering teams, I deepened my expertise in agile practices such as sprint planning, user story mapping, and backlog grooming. These approaches enabled us to iterate more effectively, incorporate customer feedback faster, and maintain better alignment with business objectives. My background in hypothesis testing and data-driven decision-making naturally complemented these practices, allowing me to bridge the gap between the rigorous demands of biotech and the flexibility of software development.

Driving a Product-Led Transformation

The arrival of a new Chief Product Officer (CPO), formerly from Uber, marked the beginning of a radical shift toward a product-led operating model. I was assigned a dedicated product squad, complete with engineering resources, and tasked with defining our squad’s principles, setting OKRs, and shaping the roadmap. This transformation unified previously siloed teams, enabling us to align more effectively with the company’s growth targets and innovation goals.

Implementing and Driving OKRs

While the CPO introduced Objectives and Key Results (OKRs) at the company-wide level, I played a crucial role in driving their adoption within my squad. By translating strategic objectives into actionable goals, I ensured that our efforts were measurable and directly tied to company outcomes. This shift gave our teams clarity and focus, fostering a stronger culture of accountability and collaboration.

My Key Takeaways

1. Customer Discovery is Crucial
   Whether in biotech or software, understanding customer needs early prevents building the wrong solution.

2. Build vs. Buy
   Re-inventing the wheel is rarely worth it. Evaluate off-the-shelf options before investing heavily in custom solutions.

3. Science + Product Synergy
   Hypothesis testing, data-driven decisions, and rigorous experimentation—core to scientific work—translate well into product strategy.

4. OKRs and Agile Execution
   Clear, measurable objectives and short iteration cycles help cross-functional teams stay aligned and deliver tangible impact.

Where I’m Headed

Reflecting on my journey from wet-lab science to product leadership, I recognise how each stage—from building a diagnostic start-up to consulting for diverse med-tech companies, and finally leading product squads has equipped me with a comprehensive perspective on commercialising deep-tech products. My scientific background deepened my analytical rigor, my start-up experiences honed my customer discovery and strategic decision-making, and my time at the public med-tech has uplifted my skills in aligning teams and managing agile software projects.

Looking ahead, I’m eager to leverage this unique blend of scientific knowledge and product management expertise to grow as a deep-tech Product Manager. I am prepared to lead larger product portfolios and drive strategic initiatives that deliver significant business value. My journey has taught me that successful product management in deep-tech requires a balance of technical understanding, customer empathy, and strategic execution—all of which I bring to the table.

Thank you for reading. I hope my experiences illustrate how deep-tech research and robust product management principles can combine to create meaningful solutions for patients and consumers alike.

P.S. If you’re interested in another scientist’s perspective on navigating academia and industry, I highly recommend checking out my friend and former colleague Kevin Koo’s excellent write-up:

https://www.linkedin.com/pulse/heads-tails-academicindustry-scientific-careers-both-sides-koo-nixxc

This pushback intrigues me because, while scientists are passionate about making new discoveries to help people, they understand that truly impacting lives often requires spinning out companies and developing products. It’s at this juncture that many scientists face a crisis of conscience and ethics. They feel uneasy running a commercial, for-profit enterprise. Yet, to make a difference, their ventures must be profitable, and they need to engage in commercial activities—from product development to sales—so their products can be built, reach the right people, and ultimately make a difference.

Why does this feel so uncomfortable for scientists? The reality is that profitable businesses are essential for delivering great products into the hands of those who need them.

To be clear, this isn’t about profits at the expense of ethics. It’s about recognising that we can be both profitable and ethical.

Balancing Profit and Ethics

Market forces, such as competition, naturally limit how much profit a company can make. There’s only so much customers are willing to pay. However, these forces can break down in two scenarios: when a product is life-saving, or when a company achieves a monopoly.

Life-saving drugs often exhibit price inelasticity—meaning customers are willing to pay whatever they can afford to access the product. Insulin pricing is a prime example. Despite being a century-old discovery, insulin costs remain prohibitively high in some countries because those who need it have no alternatives.

Similarly, monopolies create price inelasticity because customers have no other options. In these cases, where the market fails, governments often step in with regulatory measures. For instance, price caps and subsidies help ensure life-saving drugs remain accessible, while antitrust actions aim to break up monopolistic practices.

Subscribe now

A Simple Framework for Ethical Pricing

One approach to balance profitability and ethics is to map the relationship between the life-saving value of a product and its pricing elasticity.

Imagine a graph: on the x-axis, the life-saving value of the product, and on the y-axis, the profit margin that can reasonably be charged. This relationship shouldn’t be linear. As the life-saving importance of a product increases, profit margins should flatten—especially in cases where the product is life-saving and has no substitutes.

For example, a wellness supplement or fitness tracker with low life-saving value and elastic demand may have a higher profit margin because customers have alternatives and the product is non-essential. On the other hand, a life-saving drug like insulin, particularly in a monopolistic situation, should be priced more modestly to reflect its critical role in society and ensure accessibility.

By recognising where their products fall on this spectrum, companies can align pricing with ethical and business goals. In most cases, market forces will constrain pricing naturally. But in scenarios where they don’t—such as inelastic demand for life-saving treatments—leadership should exercise restraint and adopt fair pricing practices. This approach builds trust with consumers while fostering long-term sustainability for the business.

Elastic vs Non-Elastic Demand

For products with competition—those with elastic demand—market conditions allow companies to freely charge what they need to grow and remain profitable. This applies to non-essential items where customers can weigh the cost against available alternatives.

But when a product enters a non-elastic demand scenario—such as life-saving treatments—leadership has a responsibility to price fairly and within societal norms. If they cannot or will not, then government intervention is necessary to artificially constrain pricing, ensuring the product remains accessible to those who need it most.

Ethics and Profits Can Be Complementary

Finding product-market fit and pursuing profits is not at odds with ethical behaviour. By recognising where our medical products fall on the spectrum of life-saving value and demand elasticity, we can price them appropriately. In most cases, market forces will naturally constrain the profits that can be drawn. However, in situations where these constraints do not exist, it falls to us as leaders to exercise restraint. By offering well-priced products, we can build trust with consumers and foster long-term sustainability for both the business and its mission.

Profitability and ethics don’t have to be at odds—they can, and should, coexist.

Putting the User at the Heart of Your Product

When developing biotech products, it's easy to equate the product with the underlying technology or IP. While a robust IP portfolio is undeniably important, it doesn't automatically translate into market success. User-centricity is the cornerstone of creating products that not only solve real-world problems but also gain traction in the marketplace.

Why User-Centricity Matters in Biotech

Biotech products—whether they are diagnostic tools, therapeutic agents, or instruments—are designed to address specific needs within the healthcare ecosystem. These products must seamlessly integrate into existing workflows, meet regulatory standards, and provide tangible benefits to their users—be it clinicians, researchers, or patients.

Consider this: A revolutionary diagnostic device with unparalleled accuracy is impressive, but if it doesn't fit into the daily routines of healthcare professionals or if it's too cumbersome for patients to use, its adoption will be limited. Understanding the end-user's needs, pain points, and workflows is essential for designing products that are not only innovative but also practical and user-friendly.

Your Product is More Than Your IP

Intellectual Property represents the innovative foundation of your product, but it is not the product itself. A product is defined by its application, user experience, and the value it delivers to its users. Here’s how to think beyond IP:

1. IP as the Foundation

Your IP is the bedrock upon which your product is built. It encapsulates the unique technologies, methodologies, and innovations that differentiate your product in the market. However, relying solely on IP without considering user needs can limit the product's impact and adoption.

Imagine your IP as the core of a concentric circle:

• Core Layer (IP): The central foundation comprising your unique technologies and innovations.

• Foundation Product Layer: The backend platforms necessary to productise your IP into a service or product that delivers value to a defined user.

• Surface Layer: The user-facing components, such as apps or API platforms, through which customers interact with your product.

2. Building Around the IP with User Needs

While your IP is critical, the surrounding layers—the user interface, integration with existing systems, and overall user experience—are what make your product valuable to its users. Building these elements around your IP ensures that the technology is accessible, usable, and truly addresses the users’ needs.

Example: If your IP is a novel biomarker discovery platform, the surrounding product might include user-friendly software that allows clinicians to easily interpret and apply the biomarker data in their diagnostic processes. This integration ensures that the powerful technology is accessible and practical for everyday use in clinical settings.

Case Study: User-Centric Design in Action

Practical Example: Personalised Diagnostic Tool

Consider a biotech startup developing a personalised diagnostic tool for cancer detection. Initially, the company focused heavily on the technological aspects, ensuring the tool's accuracy and expanding its biomarker database. However, despite the advanced technology, the product struggled to gain traction in clinical settings.

Shifting to a User-Centric Approach:

• User Interviews: The product manager conducted interviews with oncologists to understand their specific needs and the challenges they faced with existing diagnostic tools.

• Prototyping: Based on the feedback, the product squad developed a prototype that streamlined the diagnostic process, reduced the time to results, and integrated seamlessly with existing referral systems.

• Iterative Feedback: Continuous testing and feedback loops with end-users ensured that the final product was not only accurate but also user-friendly and aligned with clinical workflows.

Outcome: By prioritising user-centric design, the startup significantly improved the adoption rate of their diagnostic tool, leading to successful commercialisation and improved patient outcomes.

Conclusion: Bridging Science and Market Success

The journey from innovative research to market-ready product is fraught with challenges. By placing the user at the centre of product development and viewing your product as more than just your IP, you can create solutions that truly resonate with your market.

Stakeholder management is a key part of a Product Manager’s role. While external stakeholders such as regulatory bodies and end-users are important, internal stakeholders also play a pivotal role in the success of your product. These stakeholders seek transparency about your squad’s roadmap, a clear vision of where the product is heading, and have invaluable personal experiences to share. Effective stakeholder management is a critical component of change management. Stakeholder insights provide essential telemetry to consider when designing initiatives on your roadmap.

1. Mapping Internal Stakeholders

Understanding who your internal stakeholders are is the first step toward effective management. In a science-based company, internal stakeholders typically include:

• Other Product Squads: Developers, designers, and product managers in other squads where dependencies exist with your roadmap.

• Regulatory Affairs: Professionals ensuring compliance with relevant regulations.

• Quality Assurance: Teams overseeing quality management and product testing.

• Senior Management: Executives providing strategic direction and resource allocation.

• Sales and Marketing: Teams responsible for promoting and selling the product.

• Customer Support: Personnel handling user enquiries and issues post-launch.

• Laboratory Staff: For products related to laboratory services, such as those under ISO 15189.

2. Applying the Power/Interest Grid

To prioritise and engage internal stakeholders effectively, we can use the Power/Interest Grid (also known as Mendelow’s Matrix). This method categorises stakeholders based on their level of power (influence) and their level of interest in the initiative.

Why Use the Power/Interest Grid?

Not all stakeholders have the same level of influence or interest in your initiative. The Power/Interest Grid provides a structured framework to:

• Prioritise Engagement: Allocate time and resources based on stakeholder importance.

• Tailor Communication: Develop customised strategies that address the specific needs and concerns of each stakeholder type.

• Improve Efficiency: Focus efforts where they will have the most significant impact, ensuring that high-priority stakeholders are adequately engaged without diluting resources on less critical ones.

Categories:

1. High Power, High Interest: Manage Closely

2. High Power, Low Interest: Keep Satisfied

3. Low Power, High Interest: Keep Informed

4. Low Power, Low Interest: Monitor

3. Personalising Stakeholder Engagement for High Power, High Interest Stakeholders

After categorising stakeholders using the Power/Interest Grid, the next step is to personalise your engagement strategies specifically for those in the High Power, High Interest category. This ensures that these key stakeholders receive the appropriate level of attention and communication tailored to their unique contributions and expectations.

Introducing Stakeholder Personas

One effective framework for personalising engagement is the Stakeholder Personas approach. This involves creating detailed profiles of typical stakeholders to better understand their motivations, concerns, and preferred communication styles. Below is an example adopting the Miller Heiman strategic selling method towards customer development.

Adapted Miller Heiman Strategic Personas:

• Economic: Individuals who have the final say on resource allocation and decisions (e.g., CFO, CEO, CPO).

• User: Those who will use the product or are affected by it (e.g., other product teams, go-to-market, customer support, lab staff).

• Technical: Experts who assess the product's feasibility and compliance (e.g., regulatory affairs, QA, CTO, principal engineers, lab director).

• Coaches: Stakeholders who support and advocate for the delivery of the product or initiative within the organisation. These are typical managers who want better outcomes for their teams.

Why Combine Power/Interest Grid with Stakeholder Personas?

By integrating the Power/Interest Grid with Stakeholder Personas, product managers can:

• Deepen Understanding: Gain insights into what each stakeholder type values in the updates they receive. This allows us to develop more effective and meaningful interactions tailored to each stakeholder’s role and influence.

• Address Jobs to Be Done: Understand and address the specific tasks and objectives each stakeholder aims to accomplish through the delivery of that milestone.

Example:

For Economic, understanding their primary focus on return on investment (ROI) and strategic alignment can help tailor presentations and reports to highlight financial metrics and long-term benefits.

For Technical, emphasising compliance details, technical specifications, and risk mitigation strategies ensures their concerns are adequately addressed.

Subscribe now

4. Establishing Engagement Frequency and Weighting Opinions

Effective stakeholder management should be an ongoing process, particularly as your initiative progresses through different milestones on the roadmap. Stakeholders may change from milestone to milestone, necessitating regular reassessment and adjustment of engagement strategies.

Stakeholder Management per Milestone

Each milestone in your roadmap represents a critical phase where specific stakeholders may play different roles or require different levels of engagement. By managing stakeholders at each milestone, you ensure that the right people are involved at the right time, improving alignment and product success.

Frequency of Engagement:

• High Power, High Interest (Manage Closely): Engage frequently through regular meetings and direct communication to ensure their needs and expectations are met. These stakeholders will also be asked to contribute to the PRD.

• High Power, Low Interest (Keep Satisfied): Invite them to monthly roadmap updates to keep them satisfied without overwhelming them with unnecessary details.

• Low Power, High Interest (Keep Informed): Provide regular updates through weekly newsletters or briefings to keep them informed and engaged.

• Low Power, Low Interest (Monitor): Minimal engagement required, but keep them on your radar for any changes in their status.

By tailoring the frequency and depth of engagement based on the Power/Interest Grid and stakeholder personas, you can efficiently manage your internal stakeholders, ensuring that high-priority individuals receive the attention they deserve.

5. Involving Stakeholders in the PRD

The Product Requirements Document (PRD) is a central tool for aligning stakeholder expectations and gathering input. Effective collaboration on the PRD ensures that all internal stakeholders are on the same page regarding product requirements and development progress.

Strategies for PRD Collaboration:

Invite High Power, High Interest stakeholders to contribute to the PRD early during the discovery phase. This proactive engagement helps identify requirements and potential issues early on. Create stub sections within the PRD for stakeholders to fill in missing details or provide specific input. This approach encourages active participation and ensures that all necessary information is captured. Additionally, encourage stakeholders to make comments directly in the document for clarity and transparency. This fosters an open dialogue and facilitates collaborative refinement of requirements.

Benefits:

Collaborative PRDs ensure all stakeholders are aligned on product requirements, reducing misunderstandings and misaligned expectations. Early feedback can identify potential issues and enhance the overall quality of the product by incorporating diverse perspectives. Moreover, involving stakeholders increases their commitment to the product's success, fostering a sense of ownership and accountability.

Regulatory and Quality Considerations:

Depending on the regulatory tier or product classification, include sections in the PRD for regulatory or quality sign-offs. For example, if a product falls under a specific regulatory standard like ISO 15189 or ISO 13485, dedicate a section where regulatory or quality stakeholders can review and approve relevant requirements. This ensures that all necessary compliance aspects are addressed early in the development process.

6. Optimising Communication Channels

Effective communication is vital for maintaining stakeholder engagement and ensuring product alignment. While some stakeholders may request broad communication platforms, such as a large Slack channel for all stakeholders, this approach can be overwhelming and ineffective.

Challenges with a Mega Chat:

Excessive messages can lead to information overload, making it difficult to follow important updates. Additionally, diverse topics may dilute relevance for individual stakeholders, and stakeholders may disengage if communication isn't directly pertinent to them.

Alternative Approach: Milestone-Specific Channels

To address these challenges, consider implementing milestone-specific communication channels. This approach ensures that communication remains focused and relevant, enhancing stakeholder engagement and collaboration.

Create temporary channels dedicated to each milestone in the roadmap. Limit participation to stakeholders directly involved in that milestone and set clear objectives to keep discussions aligned and productive. After the milestone is delivered, close the channel to maintain a streamlined communication environment and prevent ongoing distractions. Additionally, document key decisions and lessons learned for future reference to retain valuable insights.

Advantages of Milestone-Specific Channels:

Milestone-specific channels keep discussions relevant and efficient, reducing noise and enhancing clarity. They encourage active participation from stakeholders most affected by the milestone and prevent ongoing distractions by closing channels when no longer needed, maintaining a streamlined communication flow.

By adopting milestone-specific channels, you can ensure that stakeholder communication remains targeted and effective, fostering better collaboration and product outcomes.

Conclusion

Effective internal stakeholder management is essential for the success of product development. By mapping stakeholders using the Power/Interest Grid, personalising engagement for high-priority stakeholders through Stakeholder Personas, and optimising communication channels, you can ensure all internal parties are aligned and contributing positively to the product.

Embracing structured communication strategies, such as involving High Power, High Interest stakeholders in the PRD and creating milestone-specific channels, improves collaboration and product quality while avoiding the pitfalls of unfocused communication platforms.

Share EmbarkBio Substack

In Software as a Medical Device (SaMD), the stakes are even higher. The nuances of change management become critical, given the regulations and the potential impact on patient safety. This article explores the complexities of change management in SaMD product development and offers a structured approach to navigate these challenges effectively.

1. Understanding the Nuances of Change Management

The key to effective change management is recognising which changes require attention and to what extent. Specifically, in regulatory industries like MedTech, understanding when regulatory frameworks apply—or do not apply—is crucial.

For instance, in a SaMD company, you may have several products, both internal and external. Some of these products will be directly part of the SaMD, while others are not directly part of the SaMD certification but still fall under other regulatory standards like ISO 15189 for medical laboratories. This distinction affects how changes are managed.

These different levels of regulatory compliance can lead to frustration among product teams. Common questions include:

• What requires a comprehensive change management process, and what does not?

• Where is the line between different levels of compliance?

• Can we iterate and ship some features quicker because they're not directly our SaMD product, without going through our full SaMD-accredited Software Development Life Cycle (SDLC) process?

2. Creating an Assessment Matrix

To determine how to manage each product based on its regulatory impact, we can create an assessment matrix. This matrix helps define principles and criteria to categorise products into tiers, enabling tailored change management processes for each level.

Defining Principles

• Regulatory Impact: Assess the extent to which a product is subject to regulatory scrutiny under frameworks like SaMD regulations or ISO 15189.

• Product Functionality: Determine how the product contributes to the overall SaMD ecosystem or other regulated services.

• Risk Level: Evaluate the potential risks associated with changes to the product.

Establishing Criteria

By defining clear criteria, we can classify products into tiers that dictate the required level of change management. This ensures compliance without unnecessarily hindering innovation and development speed.

3. Defining Tiers of Regulatory Impact

A simple matrix is required to categorise the products into regulatory tiers. Keeping it to three tiers makes it simple and clear to product squads what tier their product fits into and what actions they need to take.

Here is a simple example using three tiers for a personalised cancer testing company:

Tier 1: Direct SaMD Regulated Product

Definition: This product is directly audited by a regulatory body for SaMD.

Example: A cancer bioinformatics pipeline that analyses Next-Generation Sequencing (NGS) data.

Required Actions:

• Strict Change Control Processes: All changes must go through formal change control procedures, including rigorous documentation, justification, and impact analysis.

• Comprehensive Testing and Validation: Perform extensive verification and validation activities to ensure the product meets all regulatory and safety requirements.

• Regulatory Approval: Significant changes may require prior approval from regulatory bodies (e.g., FDA, TGA).

• Detailed Documentation: Maintain meticulous records of all changes, testing results, risk assessments, and approval signatures.

• Key Stakeholder Sign-Off: Obtain approvals from key stakeholders, such as the Chief Product Officer (CPO), Chief Technology Officer (CTO), Regulatory Affairs, and Quality Assurance.

Tier 2: Indirect Regulated Product

Definition: Products that are not directly regulated as SaMD but form a key part of the customer journey that encapsulates the regulated product.

Example: An app that customers log into to order and see the status of their tests.

Required Actions:

• Moderate Change Control: Implement documented change management processes that include impact assessment and necessary testing.

• Regulatory Alignment: Ensure changes comply with any other relevant standards like ISO 15189/CLIA.

• Selective Documentation: Keep records of changes, test results, and approvals, with depth varying based on impact.

• Stakeholder Buy in: If there are other regulatory changes, these will require sign-off from relevant stakeholders, such as the Head of Laboratory or Pathologist. Ensure buy in from other stakeholders to help understand impact on the SaMD.

• Impact on SaMD: Assess whether changes could indirectly affect the SaMD or overall compliance.

Tier 3: Non-Regulated Product

Definition: Products or services not directly related to the SaMD or other regulated products but managed to deliver the overall product lifecycle.

Example: A Enterprise Resource Planning (ERP) system for company operations.

Required Actions:

• Standard Change Management: Follow general SDLC change management processes focused on efficiency and minimising business disruption.

• Basic Documentation: Maintain internal records of changes for accountability and future reference.

• Internal Stakeholder Engagement: Get alignment and buy-in from stakeholders, or “agree to disagree” and continue with the product vision.

• Risk Assessment: Evaluate operational risks and necessary regulatory risks to ensure it remains Tier 3.

4. The Product Requirements Document (PRD) as the Baseline

The Product Requirements Document (PRD) is the cornerstone for defining product requirements and managing changes. It should serve as the baseline that determines a product's regulatory tier and outlines the necessary actions for compliance.

Key Elements to Add to the PRD

1. Regulatory Requirements Section:

   • Tier Classification: Clearly state the regulatory tier (Tier 1, Tier 2, or Tier 3) that the product falls into, based on its features and impact.

   • Reference the Matrix: Include the assessment matrix or a link to it within the PRD.

   • Criteria Documentation: Document the criteria used for this classification to provide transparency and rationale.

   • Applicable Regulations: Detail all relevant regulations and standards applicable to the product, such as SaMD guidelines or ISO 15189.

2. Version Control and Approval Sign-Off:

   • Change Log: Add a dated change log to document all revisions to the PRD.

   • Stakeholder Review Field: Include a section where stakeholders can sign off on changes. This can be a digital approval.

   • Accountability: This ensures all changes are reviewed and approved by the necessary parties, maintaining compliance and accountability.

By adding these key elements to the PRD, you create a comprehensive document that not only defines product requirements but also serves as a central tool for managing changes and ensuring regulatory compliance.

Key Takeaways

• Centralise Information in the PRD: Use the PRD to define the product, determine its regulatory tier, and guide change management processes.

• Explicitly State Regulatory Impact: Clearly include regulatory considerations and classifications within the PRD to provide transparency and direction.

• Implement Formal Approvals: Establish and document approval protocols for changes affecting compliance, involving all necessary stakeholders.

• Prioritise Clear Communication: Ensure all team members understand the regulatory requirements and the implications of changes by making the PRD accessible and understandable.

• Maintain Consistency and Compliance: Regularly update the PRD and align it with regulatory documentation to support compliance and facilitate audits.

Conclusion

By clearly outlining regulatory considerations and change management procedures within the PRD, product teams can effectively navigate the complexities of SaMD development. This structured approach balances innovation with compliance, ensuring the successful delivery of safe and effective products to the market.

Embracing these practices minimises frustration, improves communication, and upholds the highest standards of quality. The PRD becomes not just a document but a strategic tool that guides the entire development process, integrating regulatory requirements seamlessly into product management.

A unified product roadmap can address these cross-squad dependencies by providing transparency about when deliverables are scheduled, allowing squads to align their plans accordingly. It ensures that all teams are moving in the same direction and are aware of each other's timelines and dependencies.

Setting Up a Unified Roadmap

Creating a unified roadmap is a straightforward process:

1. Consolidate Squad Roadmaps

   Each squad places their streams and tracks into a single document or platform. Streams and tracks represent the major initiatives or components within each squad's scope.

2. Standardise Milestone Descriptions

   Each milestone is written as a headline feature that succinctly summarises the deliverable. These should be crafted like press release headlines so that product marketing can easily repurpose them for external communications, such as blog articles or marketing releases.

3. Visualise Milestones on a Timeline

   By sequencing the milestones along a timeline (the x-axis), squads can align the order of deliverables and identify where they may be blocked due to dependencies on other squads. This visual alignment helps teams understand how their work fits into the broader product development schedule.

4. Maintain Consistent Timeframes

   Each milestone represents a vertical slice of work intended to be delivered in a six-week period. This consistent sizing allows squads to estimate delivery timeframes more accurately and align milestones effectively. Six weeks is optimal—long enough to accomplish meaningful work but short enough to maintain momentum.

Subscribe now

Benefits of a Unified Roadmap

The squads now have up-to-date and transparent information on what other squads are currently working on. This arms them with the information to engage on a squad-to-squad level to workshop how to unblock deliverables.

Another benefit of aligning the roadmaps in one document is providing a top-line summary of the major deliverables. These could be significant initiatives that internal stakeholders are eager to know about or market-moving deliverables that will impact revenue. This unified roadmap allows executives to understand, at a quick glance, key deliverables, serving as an effective stakeholder management tool. It not only aids in strategic decision-making but also ensures that all levels of the organisation are aligned with the company's objectives.

The unified roadmap also facilitates marketing and go-to-market planning. The top-level highlights can form the basis for product marketing activity as part of the launch strategy for major initiatives. Since milestones are written like press release headlines, they are readily usable by marketing teams for external communications, ensuring consistency in messaging and branding.

Additionally, the roadmap provides accessible detailed information without overwhelming stakeholders. Each milestone can hyperlink to its Product Requirements Document (PRD), allowing interested parties to delve into the specifics as needed. This approach balances the need for high-level overviews with the availability of detailed insights, catering to a diverse audience with varying informational needs.

Conclusion

By adopting a unified product roadmap, organisations can transform autonomy into aligned innovation. Squads retain their independence and creativity but now have the transparency and coordination needed to work cohesively towards shared goals. This strategic approach improves collaboration, drives efficiency across product squads, and ultimately leads to better product quality and timely delivery.

It's tempting to apply the same methodology to product development: define an end goal, outline the project scope, and establish milestones to demonstrate progress. However, this can lead to inefficiencies or misalignment in a dynamic product environment. While academic research often begins with well-defined objectives and structured plans—as seen in grant proposals or PhD outlines—the actual research process is iterative and exploratory, frequently adjusting to new findings and insights. In contrast, product development not only requires adaptability to new scientific insights, but must also respond swiftly to ever-changing user needs, business strategy changes, and market conditions. While research adapts based on experimental results or new publications, the feedback loop is primarily focused on scientific discovery, whereas product development involves multidimensional feedback, including user experience, market trends, and business objectives.

In my previous article, I touched upon how to setup a roadmap for science-based companies. Now we will go a level deeper on what exactly goes into developing each product milestone and we’ll use an example for a Software as a Medical Device (SaMD) company.

Transitioning from Research to Product Development

For scientists moving into product roles, understanding the distinctions between academic research and product development is crucial. In academia, projects often start with well-defined plans but evolve through iterative exploration. Product development, especially in regulated environments like SaMD, is inherently dynamic. It requires balancing compliance with regulations, user-centric design, and agility in response to market and technological changes.

Product Requirements Documents (PRDs) for a shared understanding

PRDs for Shared Understanding

Before building anything, the team needs a shared understanding of what to build. A Product Requirements Document (PRD) is a classic way to achieve alignment among team members. The PRD clarifies the "why" and "what" of a product for the product manager and communicates requirements to stakeholders and engineers.

The PRD helps align the team on key aspects:

• Which strategic objectives does the product address?

• Who is the product for?

• Why build this now?

• What should users achieve with this product?

Each PRD defines the milestones on your roadmap. Tracks represent larger initiatives, and each milestone is an incremental slice that adds value toward that initiative. A PRD is essential for each milestone, especially in a regulated deep-tech environment like SaMD.

Think of each milestone as a "bet" you're making as a product manager that this milestone will move the needle on an important OKR. Part of your due diligence is ensuring that what you're building is worth the effort and resources invested. Another crucial part is getting all stakeholders on board to support this bet. The PRD empowers you to do this by clearly articulating the value proposition, aligning the team, and providing a solid foundation for why this milestone deserves commitment.

PRDs in Regulated vs. Non-Regulated Environments

In non-regulated environments, PRDs may be seen as old-school or overly rigid, with teams favoring skipping the PRD and work at closer to the metal, by only focusing user stories within engineering task-tracking tools like Jira. However, for regulated products such as SaMD, PRDs are crucial for adhering to ISO 13485 standards and validation & verification (V&V) processes.

Integrating Agile Methodologies with Regulatory Compliance

Agile Development in SaMD

Agile development and ISO 13485 compliance can coexist in SaMD by structuring work into manageable increments—like six-week cycles—each with its own finalized PRD.

Here's how to make it work:

• At the start of each cycle, finalize the PRD requirements for that period.

• Keep requirements fixed during the cycle to enable thorough Verification and Validation (V&V).

• Use the time between cycles to adjust requirements based on new insights, user feedback, or market changes.

Subscribe now

Implementing Verification and Validation (V&V) Processes

PRDs and V&V Compliance

In the SaMD world, PRDs are part of the V&V process. During development, we verify that what we built meets the specifications defined in the PRD (verification) and ensure that it meets user needs (validation). During development, both verification and validation are critical steps in maintaining product quality and meeting compliance standards.

ISO 13485, the quality standard for medical devices, is rarely prescriptive. It requires traceability of requirements, verification, and validation, but doesn’t specify how to achieve this. Scientists new to regulatory standards might feel overwhelmed, attempting to over-engineer processes to meet requirements. Instead, keep it simple—document what is practical, then do it. A simple chart is better than a sprawling protocol no one follows.

Traceability for V&V

The standard software development process can be easily adapted to meet V&V requirements. Let’s break it down:

• Assign Requirement IDs: In your PRD, list requirements in a table with unique Requirement IDs for traceability. This ID remains immutable, even when development tickets change, preserving a clear link between each requirement and its implementation.

• Link to Development Tasks: Reference the Requirement ID in your task-tracking system (e.g., Jira) to connect user stories to development tasks.

• Verification: During testing, engineers use the Requirement ID to verify that the implemented features meet the specified requirements.

• Validation: In user acceptance testing (UAT), the Requirement ID traces back to the user requirement, ensuring the feature meets user needs.

Here’s an example of how a Requirements Table in a PRD might look:

With this structure, the Requirement ID is used during both unit testing and UAT for V&V, ensuring compliance without unnecessary complexity.

There are multiple ways to ensure traceability. The example above is a simple implementation. Use what best fits your company's established software development lifecycle processes, and adapt as necessary to meet the standards. Remember, a light-touch approach that is actually followed is a good principle to uphold.

Bridging the Gap: Practical Tips for Scientists

For scientists accustomed to writing grant applications and research proposals, writing a PRD involves similar skills:

• Define the Hypothesis (Business Hypothesis): Clearly state the problem you're solving and the value proposition.

• Outline Supporting Data: Provide data or research that supports the need for the feature or product.

• Describe Technical Solutions: Outline how you plan to address the problem, including any technical considerations.

By leveraging familiar skills, scientists can effectively contribute to product development while ensuring compliance and maintaining agility.

Focus on User-Centric Outcomes

Emphasizing user-centric design is crucial. Each requirement should enhance user experiences, such as:

• Improving Oncologist Workflow: Features that streamline data access, reduce administrative tasks, or provide decision support tools.

• Enhancing Patient Care: Tools that enable better patient engagement, provide educational resources, or facilitate remote monitoring.

By focusing on real-world impact, products are more likely to meet user needs and succeed in the market.

Final Thoughts

Moving from research-based project planning to product-focused roadmaps requires understanding key distinctions:

• Product development involves multidimensional feedback beyond scientific progress.

• Success depends on balancing across multiple dimensions such as technology, user needs, market trends, and business outcomes.

• Adhering to regulatory requirements like ISO 13485 is essential and can be integrated into agile practices.

The PRD is a cornerstone of delivering compliant, user-centric products. Even as we embrace agility, documentation like PRDs remains vital in deep-tech to maintain quality and ensure we are truly solving user problems.

In my experience, university spinouts often use traditional project management processes to deliver products to the market. The problem with this approach is that it is lengthy, and value isn't delivered until the end of the project. We should aim to deliver value to our customers and internal stakeholders, such as investors and operational teams, with milestone-driven roadmaps.

In a previous post, we discussed the need for product squads and ownership of OKRs.

We touched on creating roadmaps based on squad OKRs in that article, but let's dive deeper with more specifics.

Creating Squad Narratives

Before we get to the actual roadmaps, when a squad is developing their OKRs, they first set up their squad narrative.

This narrative is a common understanding document where squad members (PMs, designers, engineers, scientists) establish their Mission Statement, target customer considerations and assumptions, and squad principles. This document allows the squad to coalesce around these foundational principles and practices so they can establish their squad-level OKRs, develop a roadmap, and move the needle towards the larger company-level OKRs.

Let us establish that the company is a cancer diagnostic company with an NGS (Next-Generation Sequencing) platform to match cancer biomarkers to drugs for personalised medicine. The company has already determined its high-level strategy:

• Where we play: Providing products and services to oncologists.

• How we will win: Providing the most comprehensive drug recommendation platform through personalised reports to the patients of oncologists.

In this document, we will walk through how the Medical Applications Squad establishes their squad narrative that leads to their roadmap.

The Medical Applications Squad Mission Statement

The squad would be formed with company leadership, and they have determined their Mission Statement is:

Creating intuitive digital solutions that bridge the gap between genomic data and effective cancer therapies.

Medical Applications Squad Principles

With their Mission Statement defined and agreed with leadership. The squad determines the following high level principles:

1. User-Centric Design: Prioritise the needs and experiences of oncologists and their patients in every aspect of our applications.

2. Agility and Iteration: Embrace agile methodologies to deliver incremental value and adapt quickly to feedback.

3. Collaboration and Transparency: Maintain open communication within the squad and with other teams to ensure alignment and shared understanding.

Key Considerations and Assumptions

Now the squad can consider any positioning and assumptions about the products they will create:

1. Regulatory Compliance: Our applications must comply with healthcare regulations such as HIPAA, CLIA and GDPR.

2. Data Security and Privacy: We must ensure the highest standards of data security to protect sensitive patient information.

3. Integration with Existing Systems: Our solutions should seamlessly integrate with the oncologists' existing workflows and electronic health record systems.

OKRs

With the foundations now set, the squad is now ready to develop their squad-level OKRs. These will need to be aligned with the broader company level OKRs:

Objective 1: Improve the Oncologist User Experience

• Key Result 1: Increase user satisfaction scores from 70% to 85% by the end of Q1.

• Key Result 2: Reduce the average time to generate a patient report by 50% within six weeks.

Objective 2: Accelerate Adoption of the Personalised Report Platform

• Key Result 1: Onboard 50 new oncologists to the platform by the end of Q2.

• Key Result 2: Achieve a 25% increase in weekly active users over the next quarter.

Objective 3: Demonstrate Clinical Utility

• Key Result 1: Develop and integrate use-case specific diagnostic tests targeting at least three major cancer types by the end of Q2.

• Key Result 2: Provide personalised treatment guidance features that offer tailored treatment strategies, with a 30% adoption rate among active users by the end of Q4.

Subscribe now

The Roadmap

With the OKRs now established, we can now develop our roadmap1.

Tracks on the X-Axis

On the x-axis, we define our tracks, which are long-term initiatives along which we deliver successive milestones. For the Medical Applications Squad—a customer-facing team—these tracks can represent the major components of the personalized drug platform essential for market success. Alternatively, tracks could represent internal operational teams that require specific initiatives to realise value.

For example:

• Track 1: The Oncologist Referral App

• Track 2: Personalised Report

• Track 3: Clinical Utility Features

The squad's OKRs would each contribute to milestones across these tracks, and delivery across these tracks ensures the product delivers value and drives the company OKRs.

Themes on the Y-Axis

Next, the squad needs to set themes across the timeline of the roadmap. These themes are groupings of milestones designed so that completion of a theme provides significant progress towards the company's OKRs.

For instance:

• Theme 1: Unlock Short-Term Revenue (Q1)

  • Focus on features that enable immediate monetisation opportunities, such as premium report options or subscription models.

• Theme 2: Drive Clinical Utility (Q2)

  • Develop features that enhance the clinical relevance of our platform, such as advanced analytics and integration with clinical trial databases.

Why organize the roadmap by themes?

Organizing the roadmap by themes helps the team and stakeholders:

• Maintain Strategic Focus: Keeps the team's efforts aligned with the most critical objectives.

• Facilitate Communication: Makes it easier to convey the roadmap's direction to executives and stakeholders who are interested in high-level outcomes.

• Provide Flexibility: Allows adjustments in features and initiatives without derailing progress towards the main goals.

We are now ready to populate the Medical Application Squad’s roadmap with milestones that aim to move the needle on our OKRs. Here is how it could look by creating milestones based on some of the OKRs above.

By structuring our roadmap with clear tracks, themes, and milestones, we can deliver value incrementally, measure our progress against OKRs, and adjust our plans based on feedback and changing priorities

Conclusion

By adopting a theme-based, milestone-driven roadmap aligned with our squad narratives and OKRs, we ensure that value is delivered continuously to our customers and stakeholders. This approach not only accelerates time-to-market but also fosters collaboration, adaptability, and a clear focus on achieving our strategic objectives.

University spinouts and other innovation-driven organizations can greatly benefit from this agile methodology. By organizing work around strategic themes, squads can maintain alignment with high-level goals while remaining flexible in their execution. This method turns ambitious visions into tangible outcomes one milestone at a time.

However, a persistent challenge remains: why are scientists reluctant to talk to customers?

Common Reasons for Reluctance

To understand this reluctance, let's explore some common reasons why scientists hesitate to engage with customers.

• Scientists often worry that talking to potential customers—especially in regulated fields like healthcare—could unintentionally lead to legal or ethical violations.

• Without formal training in interacting with customers or conducting market research, many scientists feel they're not equipped to carry out effective customer discovery.

• With a strong focus on research and development, scientists might see customer discovery as a lower priority or even a distraction from their main work.

• Engaging with customers can feel out of step with the academic culture, which traditionally values research over commercial pursuits, making scientists hesitant to reach out.

The Misconception Between Customer Development, Sales and Business Development

Scientists often mistake customer development for sales or business development, but they are not the same.

• Customer Development is about learning. It's a part of product development focused on understanding the target customer's needs and jobs to be done. It involves engaging directly with potential customers to gather insights that inform the product, without pushing or presenting the product as a solution.

• Business Development involves strategic activities aimed at creating long-term value for the organisation. It focuses on identifying new markets, establishing partnerships, and exploring growth opportunities. The goal is to form strategic relationships and explore avenues for expansion, not to gather customer insights for product development.

• Sales is about generating revenue by converting prospects into customers. It involves promoting and selling a finished product or service, negotiation, closing deals, and meeting sales targets. Sales typically occur after a product has been developed and is ready for market.

Scientists may feel paralysed by the belief that they can't talk to medical professionals about their product due to regulatory reasons. While this may be true for sales activities, customer development is different. We're not trying to sell or form business partnerships—we're trying to learn.

The Role of the Product Manager in Customer Discovery

Customer discovery is the domain of Product Managers (PMs), and having a PM lead these efforts can effectively address many of the concerns scientists face. PMs are trained in customer engagement and market research methodologies, enabling them to conduct customer discovery effectively. By translating customer needs into product requirements, PMs bridge the gap between science and market, ensuring that the developed product aligns with market demands.

However, in the pre-spinout stage, scientists themselves should conduct initial customer discovery to inform the company and product strategy they will pitch to investors. This early engagement is crucial and should be included in any commercialisation grants. Including customer discovery data strengthens the proposal and demonstrates market validation. As a Product Manager and trained scientist, I would be highly critical if I were evaluating any commercialisation grant that did not involve any customer discovery.

By involving a Product Manager once the company is established, deep-tech companies can then ensure that ongoing customer discovery is conducted effectively. The PM's expertise allows for continuous alignment with market needs, which is vital for the product's success.

Subscribe now

Overcoming Challenges and Shifting Mindsets

Scientists need to shift their mindset from viewing customer interactions as potential sales pitches or business development initiatives to seeing them as invaluable learning opportunities.

This involves:

• Adopting practices that prioritize learning about customer needs over promoting your solution or forming business deals.

• Recognizing that the goal is to validate hypotheses about customer problems and needs, not to sell or negotiate partnerships.

• Focusing on gathering qualitative insights that guide product development, rather than being constrained by the need for statistically significant data suitable for academic publication.

• Understanding that customer development is permissible and essential, provided you are not making promotional claims about your product or engaging in sales activities.

The Importance of Early Customer Discovery

Before a company is spun out, any deep-tech venture should conduct customer development with potential customers to learn more about their needs. Scientists may get hung up on interviewing a statistically significant number of people, feeling that interviews need to meet the standards of peer-reviewed papers. However, we're looking for trends and direction—to be data-informed, not data-driven. You may start noticing trends as early as five interviews. As you approach 20 interviews, the insights become robust enough to inform your product strategy.

Customer development is about testing your assumptions by engaging directly with customers—not about collecting statistically significant data, but about gaining insights that help you make informed decisions.

A Practical Example

An assumption a scientist may make for a bioinformatics cancer platform is that doctors want as broad a range of markers as possible. But customer development with oncologists may reveal they are interested in a small subset of actionable markers and, furthermore, only interested in markers that are covered by private insurance or public access systems such as Medicare. What is legally permissible may not necessarily be what doctors are comfortable with referring. These insights inform the product roadmap, ensuring the product meets the actual needs of its users.

Integrating Customer Discovery into the Product-Led Approach

Connecting back to our previous discussion on forming product squads and setting OKRs, integrating customer discovery is a critical first step in this process. By understanding the real needs and pain points of your target customers, product squads can set more accurate and impactful OKRs that align with market demands.

A Product Manager plays a pivotal role within these squads, leading the customer discovery efforts and ensuring that the insights gathered directly influence the team's objectives and key results.

For example, in the formation of the Clinical Utility Squad, customer discovery led by the Product Manager would directly influence their mission and objectives:

• Objective: Establish Clinical Utility of the v1.0 Testing Platform

  • Key Result 1: At least 20 oncologists interviewed until 80% agreement on biomarker suitability is determined

  • Key Result 2: 100% of agreed-upon biomarkers integrated into the drug recommendation engine on v1.0 of the test report within 3 months of determining suitability

By incorporating customer insights, the squad ensures that they are focusing on biomarkers that are truly valuable to their target customers, increasing the likelihood of adoption and success.

Conclusion

Customer discovery is the missing ingredient in many deep-tech spinouts. It ensures that the products being developed meet genuine market needs and have a higher chance of commercial success. By understanding that customer development is a learning process distinct from sales or business development, scientists can confidently engage with potential customers.

Engaging a Product Manager to lead customer discovery efforts can address many of the challenges scientists face. By integrating customer discovery both at the spinout stage and as a core responsibility within product squads, led by a Product Manager, deep-tech companies can develop products that truly meet customer needs, enhancing the viability of the product and accelerating its journey to market.

Marty Cagan, a renowned product management expert, explains why theses attributes are valuable part of a of skill set of a Product Manager

We staff our product teams with the skills necessary to come up with effective solutions that are valuable (our customers choose to buy or use), viable (the solution works within the many constraints of the business), usable (the user can figure out how to use) and feasible (our engineers have the skills and technology to implement).

While the product designer is accountable for ensuring the solution is usable, and the engineers are accountable for ensuring the solution is feasible, the product manager is accountable for ensuring the solution is both valuable and viable. 

This is all to say that university spin-out companies are typically science-led rather than product-led. This is a problem because we know that many amazing IPs that are spun out into companies never make it to the market, which is a great loss for all of us. Such IP could have improved health, extended lives, and increased happiness, but due to the notorious commercialization valley of death, they never make it into the hands of customers.

To counter this problem, we’ll explore how shifting to a product-led approach, guided by clear Objectives and Key Results (OKRs), and empowered by product squads, can bridge the gap between the lab and the market.

The Importance of OKRs in Deep-Tech Companies

Objectives and Key Results (OKRs) are a goal-setting framework that can transform how deep-tech companies operate. Originally popularized by tech giants like Intel and Google, OKRs help organizations align their vision, focus efforts, and track progress toward measurable goals.

Why OKRs Matter

• The Objective part helps set clear and transparent goals across the company at both the macro (higher company level) and micro (squad level).

• The Key Results part allows the company and squads to set measurable outcomes to determine progress toward those objectives and criteria for when they have been met.

• These company OKRs set the foundation for product squads to develop squad-specific OKRs in line with the company OKRs, allowing them to develop and prioritise initiatives on the company roadmap that move the needle on these OKRs and deliver valuable and viable products.

A Practical Example: Cancer Next-Gen Sequencing Spinout

Let’s take an example of a Cancer Next-Gen Sequencing University spinout.

This spinout has developed a powerful bioinformatics platform that can identify biomarkers to more precisely determine, at a molecular level, the type of cancer a patient has. Their platform can be used to provide personalised medicine recommendations on drugs that would be the most effective to fight that type of cancer.

The Science-Led Approach

Typically, what would happen in a spinout is that the company would focus on redoubling their efforts in making the platform more reproducible outside of the lab and packing as many biomarkers as possible into their platform for a launch scheduled months into the future. Regulatory planning would be put into the delivery, and some sense of a go-to-market plan would be in mind on how to grow sales once the R&D has finished and regulatory approval has been given. This is a science-led approach and would typically lead to months of cash burn, only to be met with the sounds of crickets when launching this platform.

The Product-Led Approach

Here is what a product-led company would do instead.

First, the company would set OKRs such as the following:

Objective: Commercialize Cancer Testing in Australia

• Key Result 1: Public launch before FY Q2 2025

• Key Result 2: Over 100 referrals made for testing by FY Q4 2025

• Key Result 3: Turnaround testing from sample receipt to result within 15 days by FY Q1 2025

Formation of Product Squads

The spinout now recognizes they need to break down these OKRs into product squads to achieve these objectives. Product squads are small, cross-functional teams dedicated to specific product areas or initiatives. Each squad has a clear mission aligned with company OKRs.

These squads need to be autonomous teams that operate with a degree of independence to make swift decisions. Because of this autonomy and self-reliance, they need to be cross-functional to ensure they have all the skills required to carry out their objectives. Depending on the scope of the squad, they could include science, engineering, product management, design, and regulatory expertise.

Developing Squad Missions

These squads would have their own missions which directly contribute to achieving company OKRs.

For example, there certainly would be a squad with a mission focused on improving the clinical utility of the test in clinical practice. This squad would look into factors such as:

• Who are the target customers? Are they the referring doctors or the patients?

• What biomarkers are important to them so they can get actionable treatment?

• What other information does the test report need to contain for it to be valuable to them?

The testing platform has the capacity to identify 1,000 targets, but should that be the product? The squad may determine that only a subset of those targets are actionable and valuable to the target customers.

In addition, to deliver on the company OKRs, more product squads are required. Another squad could be focused on how those target customers get referred for a test—what solutions are required to build that referral process? How will those customers receive the test results? Yet another squad could be focused on how to deliver that test, such as what are the lab processes and solutions needed to reliably trace samples against patients to the required regulatory standards (i.e., ISO 15189).

Setting Squad OKRs

With each squad’s mission defined, they would develop their own OKRs at the squad level to move the needle toward achieving the overall company-level OKRs.

These can be set for 6-month intervals.

For the Clinical Utility Squad, one OKR could look like:

• Objective: Establish Clinical Utility of the v1.0 Testing Platform

  • Key Result 1: At least 20 oncologists interviewed until 80% concordance of biomarker suitability is determined

  • Key Result 2: 100% of concordant biomarkers matched with the drug recommendation engine on v1.0 of the test report within 3 months of biomarker suitability determination

For the Squad Responsible for Delivery of Tests, this may look like:

• Objective: Process 10 tests through the new Laboratory Information Management System (LIMS)

  • Key Result 1: Sample Receipt Module v1.2 processing 100% of all received samples by Q3

  • Key Result 2: Lab Workflow Module 1.0 to reduce DNA extraction to library prep time by 30%

Developing Squad Roadmaps

Now each squad is ready to start building out initiatives on their roadmaps which aim to meet their squad OKRs and, in turn, drive towards meeting the overall company OKRs. Because each OKR may take up to 6 months to meet, it is important to break up the delivery toward these OKRs into approximately 6-week milestones, where each milestone delivers incremental value in meeting that OKR.

For the Clinical Utility Squad, their milestones towards achieving the clinical utility of the v1.0 Testing Platform could be broken down as follows:

• Milestone 1: Recommendation Engine 0.5 for preliminary matching against 10 customer insights with a public biomarker database

• Milestone 2: Recommendation Engine 1.0 for matching against 10 customer insights with an in-house biomarker database

• Milestone 3: Recommendation Engine 1.2 for matching against 20 customer insights with an in-house biomarker database

Conclusion

Shifting from a science-led to a product-led approach is transformative for deep-tech companies aiming to bridge the gap between innovation and market success. By setting clear, customer-centric OKRs and empowering cross-functional product squads with aligned missions, companies can focus on delivering products that meet real market needs through customer-focused roadmaps while leveraging their scientific strengths.

EmbarkBio is dedicated to bridging the gap between science and market through strategic product management. Subscribe to stay updated on best practices, insights, and actionable strategies for deep-tech success.

In the world of deep-tech, particularly in biotech and medtech, groundbreaking research often faces a steep challenge when it comes to commercialisation. This challenge, known as the "commercialisation valley of death," is where many promising innovations stall.

This is where you may expect me to post a graph of the valley of death, but let's skip the cliché. Anyone who’s spent time in a lab coat is well aware of it. Instead, let’s focus on how to actually fix this problem. 

My career, as a research scientist and as a tech product manager, has shown me that the missing link often lies in a lack of experienced operators who understand not just the science but the processes needed to bring products to market.

This is especially true in markets like Australia, where the biotech and medtech ecosystem isn’t as mature as in the US. The scarcity of successful deep-tech companies here means there’s a corresponding lack of experienced operators who’ve taken an idea from the lab all the way to the market.

This was reflected in an AusMedTech plenary session that I attended in 20221

Here is a write up from that Conference by Minter Ellison:

It has for some time been a constant challenge for MedTech companies in Australia to source and retain the right people and in the right numbers. . .

In relative world terms, it is said that Australia has a small pool of qualified medical device people. This reinforces the need to be constantly engaging with prospective and existing staff and ensuring that they are motivated and incentivised to remain in the workforce.

How principles used by tech Product Managers could help

Tech product managers bring proven and high-impact processes that can be game-changers for deep-tech companies. Agile development, user-centered design, and cross-functional team collaboration are just a few examples of the methodologies that can transform how deep-tech innovations move from concept to market. In software, these approaches have led to rapid product cycles, continuous improvement, and a strong alignment between product development and market needs.

Deep-tech companies, on the other hand, often struggle with long development cycles, regulatory hurdles, and a focus that can be too inward-looking. Having worked in regulated environments, including Next-Gen Sequencing Pathology companies (ISO 15189) and Software as a Medical Device (SaMD) (ISO 13485), I’ve seen firsthand that even traditional university spinout deep-tech companies can benefit from practices used in the tech industry to better deliver essential products and services to their customers.

It's a misconception that regulatory ISO standards require a waterfall development approach, where long development lead times burn capital and create a high-risk gamble for a successful product launch. In fact, frameworks like TIR-45 provide guidance on integrating agile practices within regulated environments for SaMDs.

Subscribe now

By incorporating compliance activities into each sprint—such as documentation, verification, and validation—deep-tech companies can ensure that regulatory requirements are met incrementally. This approach reduces the risk of non-compliance surprises late in the development cycle and accelerates time-to-market. Regulatory bodies are primarily concerned with the quality and safety of the final product, not the specific development methodology used to achieve it.

Even with physical products such as lab-based tests or Research Use Only (RUO) test kits, value can still be expertly planned and delivered in strategic milestones that move the needle on a company’s OKRs.

By adopting software PM practices, deep-tech firms can not only accelerate their development timelines but also ensure that their innovations are aligned with market demands and regulatory requirements from the outset. This integration is crucial for avoiding the pitfalls that lead to the commercialisation valley of death.

Building a Community of Experienced Deep-tech Operators

EmbarkBio is a hub for professionals who are ready to bridge the gap between science and market. This is a space where we’ll explore how deep-tech companies can adopt and adapt the best practices from product management to drive their innovations forward.

What to Expect

Here’s what you can expect from EmbarkBio:

• Fortnightly Posts & Monthly Youtube Videos: To begin, I’ll aim to post twice a month with detailed explorations of how product management methodologies and their applications to deep-tech industries, with a focus on product management, agile development, and market alignment. I’ll also be posting monthly deep dive videos on my YouTube channel that I will link through to this site with supplementary information.

• Content for Executives, Managers and Specialists in Deep-tech companies: This content is primarily written based on my experience in biotech and medtech and aimed towards those who have mid to senior level positions within these types companies. The insights here likely also apply to other deep-tech and regulated industries and may be of relevance to you.

Join the Journey

This is just the beginning. I invite you to subscribe to EmbarkBio and be part of a community that’s dedicated to transforming deep-tech challenges into opportunities for growth and innovation. Together, we’ll explore how to apply the strategic processes from software tech to drive success in the biotech and medtech industries.