As life science research organizations grow and workflows become increasingly complex, the challenge of managing experimental data, coordinating teams, and maintaining traceability across projects continues to intensify. Digital tools have emerged to support laboratory operations, but many still fragment workflows across disconnected systems, creating inefficiencies for scientists and limited visibility for leadership. In this Q&A, Ryan Cawood, Ph.D., Chief Executive Officer and Co-Founder of Lab Thread, discusses how a unified “digital thread” platform aims to connect laboratory workflows, data, and project management into a single integrated system designed to support both bench scientists and organizational leadership, with Pharma’s Almanac Editor in Chief David Alvaro, Ph.D.
David Alvaro (DA): Was the genesis of the Lab Thread platform informed by your own experiences, both at the bench and running your previous company?
Ryan Cawood (RC): My career has primarily been in virology — genetically engineering viruses for different applications, mostly gene therapy. The very first project I did as an undergrad was in virology, and I’ve essentially stayed in that field ever since.
I did my Ph.D. at Oxford and went on to start a company called Oxford Genetics, which later traded as OXGENE. I ran that company as CEO for about 10 years. At one point, we had more than a hundred scientists, and one of the big challenges was managing the data those teams were producing every day — understanding where it was stored, making sure it could be accessed, and ensuring continuity if someone left the company.
It’s also surprisingly difficult to find software that scientists actually enjoy using. Scientists are trying to run experiments quickly and efficiently, and if the software slows them down or creates friction, they’ll revert to writing things down on paper. So, from the scientist’s perspective, the challenge was: how do you build something intuitive that doesn’t interrupt the flow of the work?
I also saw challenges in laboratory work management from the CEO perspective. As a company grows and additional layers develop between the bench and leadership, it becomes very difficult to fully follow and understand everything that is going on: who’s working on what, where the data are stored, whether projects are progressing properly.
Having spent time both at the bench and running a large scientific organization gave me a view from both sides of the problem, which gave me the insight to develop something better: Lab Thread.
DA: Among the digital research management tools that have emerged over the last couple of decades, what do you think developers have gotten right, and where do they still fall short?
RC: There are good products out there, but it’s hard to find scientists who will say they genuinely love using a piece of lab software, unless you narrow the conversation to a very specific function.
In most labs, different parts of the workflow are handled by separate systems. You might have an electronic lab notebook, a project management tool, file storage, and additional software for specific scientific tasks. Scientists might like some of those tools individually, but everything is decoupled, so you end up working across four or five different platforms that each do something well on their own. However, the overall workflow breaks down because nothing is connected.
This is where the idea of the “digital thread” behind Lab Thread comes from. The goal is to thread those pieces together, so they’re all connected in a single system. Ideally, over time, each module becomes something scientists genuinely enjoy using — intuitive and natural without adding unnecessary overhead. The real advantage is that all of those components are integrated in a way that most existing systems simply aren’t. That connectivity is the core principle behind Lab Thread.
DA: When you’re designing a platform like this, how do you approach building something that works for all potential users: bench scientists, principal investigators, and leadership teams?
RC: It’s genuinely difficult. The needs of a lab scientist are very different from what someone in the C-suite of a company or the PI of an academic lab wants to see. Scientists at the bench tend to focus on their own experiments. They want to record their data as quickly and efficiently as possible and then move on; they're already thinking and planning three experiments ahead; they're not necessarily considering what the other 10 people in the lab are working on.
Leadership, on the other hand, has to look at things differently. They’re asking: How do we manage these teams? How do we assign work? How do we make sure projects are progressing properly and people are doing things the right way?
Designing a single platform that serves these different groups is challenging because what helps one group often creates more work for the other. We need to constantly consider how different parts of the product will be used by different people. For the scientist-facing interfaces, the focus is on reducing friction — minimizing clicks and making it as easy as possible to capture data during the flow of an experiment. For the leadership or project-management views, the challenge is almost the opposite: there’s a huge amount of data available, but most of it isn’t relevant to someone at that level. The goal is to surface just the key information they need — whether a project is on track, who’s working on it, and where things stand — without forcing them to dig through tables of experimental data.
There’s also a cultural element to this. A lot of scientists begin their careers working independently at a bench — during their master’s, Ph.D., or postdoc studies — often in small groups where everyone talks to each other every day. In that environment, paper notebooks and informal conversations work well enough. But when those same scientists move into larger organizations, where a team of three becomes 10, 50, or 100 people, that way of working breaks down. You can’t rely on day-to-day conversations to keep projects aligned, and you can’t track everything on paper anymore.
If someone has spent 10 years working in a small academic lab and then joins a company with a hundred scientists, there’s inevitably going to be a disconnect between the way they’re used to working and the systems that are needed to manage a larger organization. That transition creates resistance — people often say, “Well, it’s always worked this way.” And the reality is that it did work that way, but only because the scale was different. Once the organization grows, the tools and processes must evolve with it.
DA: Why did you take the approach of building the platform from scratch rather than leveraging existing tools and focusing on connecting them?
RC: The challenge with stitching existing components together is that you can usually make them talk to each other to a certain extent, but it becomes very difficult to keep everything synchronized as the system evolves. If you later extend component A or component B — or both —keeping them in sync becomes incredibly complicated, especially if they’re built on separate databases. You end up with fragile integrations that can break whenever something changes.
Building a system from scratch creates an opportunity to unify the underlying data architecture. That means when something changes in one part of the platform, that information can propagate across the rest of the system — from component A to B to C and so on — because everything rests on the same foundation.
We started developing the underlying architecture for Lab Thread in 2021. At that stage, we weren’t even building the biological features yet; we were just laying down the core system architecture. Our first attempt at the architecture ultimately didn’t work because the complexity of reproducing the laboratory environment in a digital system was greater than we had anticipated. The following year, we essentially rebuilt the architecture, creating what we call Architecture 2.
It then took another year just to establish the database structure for the entire system before we began building the parts people would recognize today, like the data management and laboratory workflow tools.
A lot of that effort was about making sure the platform could scale. For example, if 10,000 scientists signed up tomorrow, the system should be able to handle it. A common mistake in software development is building something quickly, achieving success, and then realizing you must completely rebuild it to support growth. We wanted to avoid that by designing the system for scale from the beginning.
DA: I realize that there is no such thing as a typical lab workflow, but could you walk through an example of one that highlights the value of the “thread” concept?
RC: I tend to think about it in terms of two different threads.
The first is what you might call the human thread. A PI or someone in the C-suite decides they want to run a particular project. As the initial idea becomes better defined, the project is distributed across different people in the organization. Multiple scientists begin working on different aspects, and the challenge becomes keeping all of that coordinated — making sure everyone understands what they’re supposed to be doing, how their work fits into the broader effort, and how the pieces come together.
That kind of project-level coordination is difficult to track in any industry. But in biotech, there’s an additional layer underneath that, which I would call the genetic thread. For example, you might start by synthesizing a piece of DNA. Then you combine that DNA with another sequence. That construct might then be inserted into a virus, which enters a cell line. That cell line might be grown and used for years, eventually moving into larger-scale processes like a bioreactor, where you might run multiple production runs.
At that stage, how do you trace everything back? If you’re standing at the bioreactor stage, how do you know exactly which DNA sequences ultimately fed into that process?
It’s almost like a set of Russian dolls — you can keep opening the layers one by one and tracing the lineage further back. In bioscience, that kind of traceability is incredibly difficult to manage with any software on the market.
Our vision is for Lab Thread to unlock the ability to follow that entire journey. You can start at the DNA level — designing and engineering sequences — then track how those materials are used as they move into viruses, cells, and downstream processes. And at any point, you can look back and see exactly how each component has been used and how it connects to everything else.
That genetic lineage is separate from the project management or information thread we talked about earlier, but both are happening simultaneously in biotech. Before Lab Thread, no single piece of software has been capable of capturing both of those threads together in a unified way.
DA: During development, did you encounter any surprises —challenges you didn’t anticipate or benefits that emerged along the way?
RC: Honestly, I was surprised by just how complex bioscience workflows really are. In hindsight, I was probably a bit naïve at the beginning. You sit down and try to list every type of material a lab scientist might work with, and you think you’ve covered everything. Then you show the system to someone and they ask something like, “How do I add an animal? How do I add a mouse?” Suddenly you realize that a mouse doesn’t have a concentration and doesn’t sit in a tube, and the assumptions you built into the system don’t quite apply anymore.
As we’ve developed the platform, we’ve constantly had to work through those kinds of scenarios — if we change one part of the system, how does that affect everything else? Sometimes the logic holds together nicely, and sometimes you discover you need to rethink something more fundamental. The advantage of being in the beta stage is that we can still make those changes without disrupting many users.
Some of the benefits that have emerged have been really encouraging. For example, the sharing functionality turned out to be much more powerful than I originally appreciated. The ability to share biological materials within the system — with options like view-only access, edit access, or full control — gives research teams a lot of flexibility. It allows people to collaborate without worrying that something critical might be edited or changed unintentionally.
The commenting and collaboration tools have also proven extremely useful. You can have discussions at multiple levels within the system — at the project level, the task level, the electronic notebook entry, or even within a specific genetic design. That creates a structured way for teams to communicate about their work as it evolves. Those collaborative elements ended up being more valuable than I initially expected.
DA: Reproducibility has been a challenge throughout the history of biological research. To what extent does Lab Thread help to make it easier to replicate experiments properly?
RC: Reproducibility remains a huge issue in biotech, and part of the reason is simply cost. If you can’t reproduce an important result, you’re essentially repeating expensive work over and over again, sometimes across multiple labs.
The key to reproducibility is standardization. If you can standardize how teams record and run their processes, then when something works (or doesn’t), you can start to look for the subtle differences that explain why.
That’s where the process module we’re developing comes in. It both allows teams to create standardized forms and workflows that everyone in the organization uses and allows individual scientists to record the small variations that inevitably occur.
For example, imagine a step in a protocol where a sample goes into a water bath. Maybe historically that’s always been done at 38 °C. One day, someone runs the experiment at 36 °C. If everything is recorded consistently, you can later run a query and ask why that experiment failed, and the system will point to the temperature difference.
In the future, AI could analyze those data and make more definitive conclusions: every time this step is performed at 36 °C the experiment fails, and every time it’s done at 38 °C it succeeds.
Without that level of structured data, troubleshooting becomes much harder. Instead of identifying real variables, people often rely on intuition or even superstition — “maybe it failed because it was Tuesday.”
It is critical to give scientists a friction-free way to record those small differences in their workflows. If you think about something simple like making a cup of tea, sometimes it tastes great and sometimes it doesn’t — but most of us don’t record the temperature of the water or the freshness of the milk. In the lab, those kinds of details can make the difference between success and failure, so you need a system that captures them consistently without slowing people down.
DA: Does embedding standards into the system help teams consider regulatory or documentation requirements earlier in the workflow?
RC: There are really two layers to that: quality and compliance.
The quality aspect is fundamental. In any laboratory data system, you want to know who did what and when, and you want that information recorded consistently. That’s true regardless of formal regulatory requirements — it’s simply good scientific practice. When experiments are expensive, you want to be confident that the work is being done correctly and that the data are reliable.
Above that basic level of quality sits the more formal compliance framework — things like CFR compliance, ISO accreditations, and other regulatory standards. Those become especially important if you’re working with human samples or if your research is eventually going to support a clinical trial and you need to submit data to regulators like the FDA or the MHRA.
The more consistently teams record their work, the easier everything becomes downstream. You can export the data, analyze them, share them with collaborators, or submit them for review. There’s also the review cycle itself — you finish a piece of work, a colleague reviews it, and someone signs off. All that documentation needs to live in one place.
Technically, you could still do this manually on paper and scan everything afterward. But imagine a project like developing a stable cell line, which might take a year. If that work eventually moves into a GMP environment, every single cell passage (which might occur every two or three days) has to be documented and signed off on. That is an enormous administrative burden, and at the end you still have to scan all those records and organize them correctly. If even one record is missing, you face serious problems when you try to move the program toward the clinic.
Embedding those steps directly into the system helps prevent those problems. It doesn’t just make the process easier; it provides a reminder. When someone reaches a certain stage of the workflow, the system can prompt them to complete the necessary documentation or approvals. It keeps the record complete and, in a sense, keeps everyone honest about the steps that need to happen.
DA: You recently announced that Lab Thread has entered beta testing. Can you discuss the scale of that effort and what you’re hoping to learn from those early users?
RC: The beta group includes scientists from my own network and those of others involved in Lab Thread. These are people who have a real need and are willing to try the system to see whether it delivers on what we’re aiming for. At this stage, we are evaluating the user interface (UI) and the user experience (UX).
The beta process has been incredibly valuable. Some of the early interfaces we showed people weren’t as intuitive as we thought — people clicked on the wrong things, or certain design elements didn’t work the way we expected. That kind of feedback has helped us refine the product significantly.
We’ve also been doing very informal usability testing. Sometimes I’ll just sit down with someone, open the interface without any explanation, and ask them what they want to click on or what they think a button does. Watching how people interact with the system like that gives you a very clear sense of how intuitive the design truly is.
Beta is really the next stage of that process. Instead of just looking at the interface, we’re asking people to use the system — manage a project, upload files, run their workflows in the lab or in the office — and then tell us how it feels. It’s essentially a stress test and an optimization phase. We currently have a few hundred people using it, which is enough to get meaningful feedback on what works and what doesn’t.
DA: How mature do you see the product at launch in terms of the full vision for Lab Thread?
RC: When we launch at the end of April, Lab Thread will include the core functionality we set out to build when we started the project.
However, we are already working on additional capabilities that we will seek to add over time. For example, we plan to introduce modules for things like animal studies and discovery workflows, as well as more advanced plate functionality so scientists can design experiments and create reusable templates.
One of the biggest areas of future development will be adding an AI layer over the platform. The underlying system must be in place before you can start work on that layer, because the AI needs to understand how the system works and how the data is structured to interact with it in a meaningful way.
Our vision is for a scientist to be able to talk directly to the platform and say something like: “Create a project. Assign David to it. Assign two other people to this task. Attach this plasmid DNA sequence to that step.” Then the AI would understand the structure of the system and automatically build the project workflow. We’d like to begin delivering capabilities like that by the end of this year.
We believe that the platform will continue to evolve, but not necessarily because the fundamentals of lab work are changing. The basic mechanics of running a laboratory are still the same — centrifuges are spinning, tubes are going into freezers, and experiments follow familiar processes. What is changing rapidly is user expectations. A few years ago, scientists assumed they would write their own protocols from scratch every time. Now, many people will start by using AI to generate a draft protocol that they will then adapt for their specific experiment. While the underlying lab processes remain stable, the way scientists expect software to help them work — particularly in terms of efficiency and analysis — is evolving very quickly.
DA: We touched on the very different kinds of organizations that Lab Thread could serve. Do you foresee some being more hesitant to adopt the platform than others?
RC: One of the realities in this space — and it’s not specific to Lab Thread — is that the larger a company becomes, the harder it is to migrate to a new system. When organizations already have years of data stored in a particular format, moving those data into a new platform can feel more difficult than simply continuing with the tools they already use.
Because we’re new to the market, our initial focus will naturally be smaller organizations where that transition is easier. Small to mid-sized biotech companies are really the ideal early users for what we’re building. There’s no real reason larger companies couldn’t adopt Lab Thread — it just requires more effort on both sides, both from our team helping with migration and from the company restructuring its existing data so it can be imported properly.
Our goal isn’t to immediately roll out across large pharmaceutical companies with tens of thousands of scientists. Instead, we’re focused first on the smaller and mid-sized biotech groups where adoption can happen more naturally.
Academia is also an important part of that strategy. Academic labs are typically small groups, so we offer a free version of the platform for up to five scientists. That allows smaller research teams to start using the system without a financial barrier.
The platform itself is tiered, so different organizations can access different levels of functionality depending on their needs. Some groups will only need the basic tools, while others may require more advanced features like digital signatures, approval workflows, or formal documentation generation. Those capabilities can significantly increase storage and system requirements — for example, generating PDF records for approvals daily — so the tiers reflect both the number of users and the level of functionality each team needs.
Additionally, everybody who signs up for Lab Thread will get a 30-day free trial of the whole functionality, which we believe will allow them to fully appreciate the value the platform can provide.
DA: Could you speak a little about the team behind Lab Thread and how the company is positioned for financing and growth?
RC: The development team is extremely strong. Every member of the team shares broad technical capabilities, but each also has a particular specialization. For example, we have someone focused primarily on database architecture, someone specializing in molecular biology interfaces, and someone dedicated to user experience design. They can all work across different areas, but each brings deep expertise in their specific domain.
That combination has been important because it allows us to build a system that’s technically robust and capable of scaling as the platform grows. I’ve also deliberately built the team around people I know and trust — many of whom worked with me at OXGENE — whose skills I’ve seen firsthand and who I’m confident can help scale the company as the product expands.
The immediate focus is getting the product to market at the end of April. It’s generally difficult to raise capital before you’ve actually launched something, so we’ve raised what we need to get to that stage and beyond, but at some point later this year we’ll likely be raising another round to support that next phase of development, both implementing more advanced AI capabilities and expanding the team.
In the meantime, we are focused on connecting with potential users outside of our beta group to promote our free trial option. There’s really nothing to lose in that first month of testing, and we are confident that the value will be very clear.
