The stepping stones problem

There are rivers you cross on stepping stones rather than a bridge. It works if each stone is placed where your foot naturally falls. Shift one a few inches, and the crossing becomes a small act of concentration every time. Most people manage. But given the choice, they’ll find another route.

Scientific software adoption works the same way. The question isn’t whether a scientist can use your tool. It’s about whether using it feels like the natural next step or a small, deliberate effort every time.

Adoption failure in life science software rarely announces itself. By the time it’s visible, the decision is usually already made. There are several places where I see it take hold, but three come up consistently enough to warrant close examination.

Friction is cumulative, not catastrophic

The failure mode I see most often isn’t dramatic. There’s no moment where a scientist throws up their hands. What happens instead is a series of small decisions, each entirely rational.

Manual export, reformat and import between applications rather than learning how to import the data directly. Exporting to a familiar tool to run an analysis rather than staying in the main platform. Asking the one person who really knows the software to create the report rather than figuring it out themselves.

Each workaround is a stepping stone placed slightly wrong. None of them feels like a problem. Collectively, they mean the software never quite becomes part of the daily rhythm.

I worked on a partnership earlier in my career that illustrated this cleanly. Optibrium and Collaborative Drug Discovery integrated StarDrop directly with CDD Vault. Before that integration, scientists searched the Vault, exported a file, reformatted the data, and imported it into StarDrop for analysis. Four steps, each trivial on its own. But when you’re doing it regularly, the cumulative weight of that process becomes the thing you remember about the software, not what it produced.

Removing that friction didn’t just make life easier. It made both platforms feel indispensable because neither required scientists to break their flow to use them.

That’s the standard worth aiming for: not impressive, invisible.

The champion is not the account

Reducing friction is only part of the picture. Even when a platform fits the workflow well, there’s a second problem that can undermine the account just as quietly, and it’s harder to see from the outside.

Usage is concentrated in one or two people. They love the software, understand it deeply, and advocate for it internally. To the vendor, the renewal feels safe because those people are engaged.

But look at the rest of the team. They’re asking the champion to run analyses for them. Or they’re exporting the data and running their analysis somewhere else. They’ve quietly decided the software is for experts, not for them.

This is a fragile position to be in. If the champion moves on (and in life sciences, people often move or get reassigned), the software loses its internal voice. Usage drops, and the renewal that felt secure suddenly isn’t.

The question worth asking isn’t “Who loves our software?” Instead, ask “Who uses it because it makes their work measurably easier, not because they’ve invested enough time to make it work?”

That second group is where the renewal is actually secured.

The renewal decision is made in the first 90 days

Workflow friction and champion dependency are both slow-burning problems. But there’s a timing dimension that makes both of them harder to recover from than they appear.

Churn decisions in life science software are rarely made at renewal. In my experience, they’re made in the first 90 days of a licence and confirmed nine months later.

If a scientist hasn’t found the point at which the software makes their work easier and demonstrates impact within that first quarter, they stop looking for it. They might keep the login. But they’ve mentally categorised it as a tool they own rather than a tool they use. At worst, they forget it’s even available in their toolbox.

The signals are quiet. Response times lengthen. Training invitations are declined with a plausible reason. When you ask how it’s going, you hear that they haven’t quite gathered the right data yet, but that they’ll really get into it on the next project.

The groundwork for a renewal is laid in month one, not month eleven. What happens in those first 90 days, whether a scientist finds their footing, whether the tool fits the workflow rather than fighting it, determines whether the account is secure long before anyone uses the word renewal.

What this means commercially

Taken together, these three patterns point to the same conclusion.

Adoption isn’t simply a training problem or a support function. It’s where your commercial strategy either pays off or doesn’t.

A scientist who finds the software genuinely useful doesn’t agonise over renewal. It’s in the budget because removing it would create a problem. A scientist who’s been managing around it for eleven months is looking for a reason to cut it, and in a tight budget cycle, they’ll find one.

The stepping stones have to be placed where the feet actually fall. Sometimes that means changing the route, but only if the scientist can see where they're going and trust they'll get there. The problem isn't changing a workflow. It's doing so without that trust in place.

These three patterns don’t cover every way adoption can go wrong. But in my experience, they’re worth checking first because if any one of them is present, the others usually aren’t far behind.