Adoption is critical. Yet elusive.

Around 80% of new products fail within two to five years of launch – not in the first year, but later, when the product is out in the world and momentum should be building. It's not that the technology doesn't work, or that the consumer market or clinical need isn't there.

In our experience working across digital health and medtech, the reason is rarely what teams expect. It's not the product itself that lets them down. Adoption fails because it was never properly designed for in the first place.

This is the uncomfortable truth that most founders and product leads encounter eventually – usually later than they'd like, and at a much greater cost than planned. A monitoring platform that clinicians quietly stop using after a strong pilot. A consumer service that sees strong early uptake and then fades. A solution that the organisation approved, integrated, and never truly embraced.

The instinct is to treat adoption as a downstream problem - something to solve once the product is built, through better training or a more compelling launch. But the teams that consistently achieve adoption aren't solving it after the fact, they're designing for it from the start; building clear pathways that guide users from first encounter to sustained, embedded use.

Adoption isn't an outcome that just happens when you build a good product. It's a design problem – and one that needs to be tackled throughout the entire implementation journey.

‍

What do we actually mean by “adoption”?

Adoption gets talked about a lot, but it's rarely defined with much precision. Downloads, logins, pilot completions – these get reported as adoption metrics, and in doing so, a much more important question gets glossed over: are people actually using this solution in a way that delivers the outcomes it was designed for?

Meaningfuladoption means a solution has been sustainably integrated into the lives or workflows of the people it was built for. For a tool used by professionals, that means consistent, confident use within existing workflows – not a workaround that gets tolerated alongside the real process. For a consumer-facing product, it means sustained use and engagement beyond the novelty of something new, built on genuine habit and trust in the solution.

This distinction matters because it changes what you measure, and more importantly, what you design for. A product can clear every usability benchmark, pass every regulatory hurdle, and still fail to be adopted – because usability and adoption, while related, are not the same thing. Usability tells you whether people can use a product. Adoption tells you whether they actually do, consistently, and to the degree that it makes a difference and marked improvement in their lives.

It's also worth noting that adoption doesn't only apply to the end user of a product or service. Organisations themselves constantly face adoption challenges, including:

• Integrating new technology into existing operations
• Embedding AI tools into professional workflows
• Adapting to evolving roles and responsibilities
• Rolling out internal process changes
• Embracing process change as a result of a new product launch

In each case, the same principle applies: change doesn't stick because it was mandated or deployed. It sticks because it was designed for. And that's as true for an internal transformation programme as it is for a consumer-facing product launch.

‍

The real problem – adoption is treated as an outcome, not a design challenge.

Most teams building new products and services are, understandably, focused on building the right thing. They invest in research, iterate on the design, validate with users, and work hard to solve a genuine problem well. And then they ship – and expect adoption to follow.

It rarely does, at least not in the way they'd hoped.

The issue is that adoption tends to be treated as something that happens after you make a good product – a reward for getting the design and the product-market fit right. In reality, the friction that kills adoption is rarely about the quality of the product itself. It lives in the gap between the solution and the real-world context it needs to operate in: the existing habits and workflows it has to compete with, the organisational dynamics that shape whether it gets championed or quietly shelved, the trust that needs to be built before people will change the way they work or live.

These aren't problems you should solve at or after launch. They're problems you have to design for – continuously, and from the very beginning of the development process.

This is the reframe that changes everything: adoption isn't a deployment issue or a natural solution outcome; it's a design problem. The teams that treat it as such – building adoption into their strategy rather than bolting it on at the end – are the ones that consistently see their solutions take hold and deliver the impact they were built for.

————————————————

In part 2 of this series we’ll look at the concept of the adoption pathway, and the stages of product development and implementation where designing for adoption is most important.