Using PRDs to Develop Medical Software (SaMD)
Combining Agile Methods with Regulatory for User-Focused Products
As scientists, we are trained to execute complex research projects with well-defined milestones. This is the foundation of grant applications and PhD studies. Each deliverable—often a research paper or a set of experimental results—adds value incrementally and contributes to the whole project outcome.
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.
Strategic Roadmapping for Deep-Tech Products
Milestone-Driven Roadmaps: Delivering Value Incrementally in University Spinouts
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.
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.