What is the adoption pathway?

When we talk about “the adoption pathway”, what we we’re thinking about is the journey that a user takes from their first encounter with a product, service or solution, all the way through to a deep, sustained integration into how they work or live. It's not a launch plan, and it's not an onboarding flow – it's the full arc of change that needs to happen for a solution to truly take hold. It also doesn’t happen by accident, it’s a deliberate, designed route we need to guide our users on otherwise they can quite easily fall off the path.

The reason the pathway matters is that adoption rarely happens in a single moment. It's a journey, and like any journey it has distinct stages – awareness, understanding, first use, growing confidence, habit formation, and finally the kind of embedded use where the solution becomes the new normal - true adoption. Each of those stages presents its own challenges, and each needs to be actively designed for.

Users also rarely take a single route to navigate the adoption pathway. Most products and services touch multiple user groups, each with their different motivations, different starting points, and different barriers and resistances to change. A first-time user and a power user, a frontline employee and a senior decision-maker, a clinician and the patient they're treating – each might need to "adopt" the same solution, but what that looks like, and what it takes to get there, will be very different for each of them. A well-designed adoption pathway accounts for all of their experiences.

What this means in practice is that the adoption pathway needs to be mapped, tested, and iterated with the same rigour as the product itself. Without that, you're relying on users to find their own way and navigate any gaps in your pathway on their own – and most of them won’t, they’ll simply stop using your solution.

‍

Plan for adoption through all phases of product development.

One of the most common misconceptions about adoption is that it first becomes relevant at the point of launch. In reality, the decisions that determine whether a product gets adopted are made much earlier, whether the development team realise it or not – and the opportunity to design deliberately for adoption exists at every stage of the development process.

Pre-pilot
‍This is where the adoption pathway ideally starts being built (but rarely is). User research, stakeholder mapping, workflow analysis, and early co-design with the people who will actually use the solution are all adoption-shaping activities, even if they're rarely labelled as such. The most important question to answer at this stage is deceptively simple: who needs to change their behaviour for this to work, and what would make that change feel worthwhile to them? Teams that can't answer that clearly before entering a pilot are building on uncertain ground.

‍During and post-pilot
‍Pilots are typically treated as a proof of concept for the technology. They should also be treated as a proof of concept for the adoption pathway. Real-world usage will surface friction that no amount of research or testing fully anticipates – where engagement drops off, which user groups are struggling and why, what workflow tensions emerged that weren't expected. The post-pilot phase is a critical inflection point, and one that's frequently underused. Some teams iterate on their product based on what they learn in the pilot - fewer iterate on their adoption strategy with the same rigour.

Pre-summative and regulatory validation
‍For regulated products (eg: medical devices, digital health products), the summative phase is where the usability and safety of a product is formally validated. But as we've already established, usability and adoption are not the same thing. A product can very often perform well in a closely controlled, specifically designed validation study and still struggle in the real world, where context, pressure, and competing priorities all come into play. This is the phase where training programmes, onboarding journeys, and integration strategies need to be properly resolved – not treated as details to be finalised after any meaningful change becomes locked behind the weight of validation.

Preparing to Go to market
‍A strong go-to-market strategy is about more than awareness and acquisition – it's an integral part of the adoption pathway. How a solution is positioned, who it's introduced to first, how early champions are identified and supported, and how the narrative is framed for different user groups will all shape the trajectory of adoption from day one. Teams that treat go to market as a communications exercise, separate from the design and implementation process, often find that even a well-built product struggles to gain traction. The most effective go-to-market strategies are built in close collaboration with the people responsible for the product experience – because the message and the experience need to land as one.

The thread that runs through each of these phases is the adoption pathway. It isn't something that gets handed over at launch or bolted on at the end – it's a living part of the development process that needs to be considered, shaped, and refined at every stage. The teams that achieve lasting adoption aren't the ones that got lucky at go to market - they're the ones that were asking the right questions about adoption long before the product was ready to ship.

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

In part 3 of this series we’ll look at how to design for adoption at all points of the development process, the cost of getting it wrong, and how you can get to know your adoption pathway better.