To the outside observer there might not look like there is a big difference between research and clinical laboratories. They both have hard floors, wipable countertops, and the smell of ethanol and bleach can sometimes be in the air. However if we look at what these labs value, the story changes. Translational (research) labs trade in one currency - possibility. Clinical labs trade in another - reliability. In this context, regulation isn't just a hurdle; it's the exchange rate that determines whether your innovation can be recognized in the clinical world. It definitely is not an easy balance. During my 12 year journey into diagnostics, I've watched interesting technologies, backed by brilliant minds make a fatal miscalculation: they develop products rich in the currency of research, then struggle to convert that value when it's time to enter clinical practice. The result is a costly re-work (if they are lucky), frustrated stakeholders, and a graveyard of failed innovations that never reach the patients who need them. The problem isn't that these teams lack talent or dedication. It's that they're approaching regulation as something that happens _to_ their product rather than something that shapes it from the beginning. They're treating regulatory approval as a final step rather than an integral part of the value creation process. Having been involved in this 0-1 journey myself, I've learned that the most successful diagnostic companies don't just pass regulatory hurdles, they use regulatory thinking as a design constraint that actually improves their products. But this requires avoiding three critical mistakes that I see repeatedly across the industry. ![[20250910080995.png]] ## Mistake #1: "Build First, Validate Later" The most expensive mistake diagnostics companies make is assuming they can perfect their science in isolation, then retrofit regulatory compliance afterward. This approach treats risk management as a compliance checkbox rather than what it actually is: a design philosophy that should guide every engineering decision. I attended an Emergo at some point in the last couple of years where the presenter shared an insight that has stuck with me, as it is very much how I think about risk analysis. They explained that risk analysis isn't about searching for new problems or requiring unnecessary design changes. It's more like process that generates random potential problems and then organizes them for consideration. **More problems equal more opportunities.** Looking at things through this lens: instead of seeing risk analysis as an obstacle to innovation, successful teams use it as a systematic way to uncover design improvements they might never have considered. If you've spent time thinking about the ISO 13485 quality management framework, you know isn't just about documentation—it's about creating processes that surface problems early when they're still easy and inexpensive to solve. ### What I've learned: Risk management becomes exponentially more expensive when it's retrofitted. Every design decision you make without considering regulatory implications creates technical debt that compounds over time. The teams that succeed integrate risk thinking into their design process early, using it to guide material choices, user interface decisions, and workflow design. **Questions to guide your process:** - What risk management framework are we using to guide design decisions? - How are we documenting design rationale in ways that will support regulatory submissions? - What user-related risks are we designing out rather than trying to mitigate with instructions? ## Mistake #2: "Research Lab Complexity = Clinical Lab Viability" Research labs and clinical labs operate in fundamentally different worlds, yet I consistently see teams assume that what works in a translational research setting will translate seamlessly to clinical practice. This mistake reveals itself in assay complexity that seems manageable in a research context but becomes a nightmare in clinical implementation. While it might be tempting to think that you can transition from research to the clinic seamlessly, this is often not the case. Translational labs can tolerate complex, multi-step assays if they deliver meaningful research insights. Clinical labs, however, must consider throughput, staffing requirements, error rates, and cost per test. A brilliant assay that requires specialized training, custom reagent handling, or extensive manual steps might be perfect for research but catastrophic for routine clinical use. Especially in diagnostics contexts, the degree of user interaction required fundamentally shapes both regulatory complexity and commercial viability. **Every additional user touchpoint increases the potential for error, requires additional training, and complicates risk management.** Clinical labs are looking for solutions that integrate smoothly into existing workflows, not research projects that require dedicated specialists. ### What I've learned: Understanding your end users isn't just good product development—it is essential to a good regulatory strategy. The more complex your user interactions, the more extensive your usability testing and risk mitigation must be. **Questions to guide your process:** - Who are our actual end users, and how do their workflows differ from research labs? - How can we reduce complexity through design rather than managing it through training? ## Mistake #3: "Regulatory Approval = Market Success" Perhaps the most dangerous assumption is that clearing regulatory hurdles guarantees market adoption. This mistake reflects a fundamental misunderstanding of how clinical diagnostics actually create value. Approval is valuable and (sometimes) necessary but not sufficient - your test must improve patient care while also meeting the needs of labs and making economic sense for a range of stakeholders. I've seen companies invest years in regulatory approval for tests that technically work but don't address real clinical needs. Just because you can detect a biomarker doesn't mean detecting it changes patient management. Just because your technology is innovative doesn't mean it fits into existing laboratory operations or reimbursement models. **Clinical success requires satisfying multiple value equations simultaneously:** patients need better outcomes, laboratorians need reliable workflows, and payers need cost-effective solutions. If your test disrupts revenue models, requires expensive new equipment for low-throughput applications, and/or doesn't clearly improve standard of care, regulatory approval won't save you. ### What I've learned: The more you seek to disrupt, the more uphill you might need to climb before you would ever see a return. Regulatory approval is often toward the beginning of clinical market validation, not the end. The most successful diagnostics companies design their products with the entire clinical ecosystem in mind, considering not just technical performance but workflow integration, economic impact, and stakeholder adoption patterns. **Questions to guide your process:** - How does our test clearly improve patient outcomes compared to current standard of care? - What's the total cost of implementation for clinical labs, including training and workflow changes? - How do different stakeholders (clinicians, laboratorians, payers) define value, and does our test deliver on their specific needs? ## Building Better These mistakes share a common root: treating regulation as something external to product development rather than integral to it. The most successful diagnostics companies use regulatory thinking as a design consideration that actually improves their products. They recognize that the exchange between research possibility and clinical reliability is about creating solutions that actually work in the messy, complex world of healthcare. **The reality is more nuanced than many teams initially realize:** brilliant science is necessary but not sufficient. Market success requires understanding the exchange rate between research innovation and clinical implementation from the very beginning, using regulatory thinking not as a final hurdle but as an ongoing design partner. As I continue learning and refining this approach, I'm convinced that the future is brighter for teams that view regulation not as an obstacle to overcome but as the mechanism that helps their interesting science transact in the currency of clinical care. The question isn't whether to engage with regulatory thinking early, it's how to integrate it so seamlessly into your design process that compliance becomes a natural outcome of good product development. --- *Have thoughts on regulatory strategy or want to continue this conversation? Please feel free to [connect on LinkedIn](https://www.linkedin.com/in/c-wagner/), or [shoot me an email](mailto:[email protected]) if you want to discuss further.*