Designing for Adoption

9/5/2025 • 5 min read

In many teams, product adoption is treated as an afterthought. It’s something to worry about later, or something other people - like enablement, comms, or “the business” - will figure out.

But when you're building internal products, platforms, or APIs, avoiding the adoption question almost always comes at a cost. If you’ve ever launched something great that nobody used, you know exactly what I’m talking about.

Even with well-built systems and genuinely useful capabilities, adoption often stalls. Teams fall back on legacy workarounds, miss out on improvements, or don’t even know the product exists. When that happens, impact stalls too - regardless of technical quality.

This isn’t a technology problem. It’s an adoption problem - and it can have a huge commercial impact.

Every internal tool or platform that isn't used as intended represents wasted investment, missed opportunities, and hidden costs - not just in effort, but in lost alignment, duplicated work, and slower delivery across the business.

Introducing: The Path to Adoption Framework

To support that shift, I began prototyping a structured facilitation method - something approachable, theory-informed, and easy to apply in real teams. I call it the Path to Adoption. It draws on established models like Crossing the Chasm, the Pirate Metrics Funnel, and innovation diffusion theory. My goal was to combine them into a hands-on, collaborative method tailored for internal products and platform adoption. At least, that's the context in which I’ve applied it so far.

The idea is simple: adoption is not a binary state. It’s a series of distinct stages a user (or team) goes through. From first awareness to long-term reliance and advocacy.

Here’s how I define it, drawing inspiration from the models referenced above:

1. Spark – Someone hears about it

2. Discovery – They explore what it is and what it does

3. Evaluation – They assess whether it’s useful in their context

4. Experimentation – They try it out in a low-risk way

5. Integration – They adopt it into real work

6. Reliance – It becomes critical to their workflow

7. Advocacy – They recommend it to others

In a recent workshop, I mapped each of these stages collaboratively using a digital whiteboard. Teams were asked to describe what currently happens, what should happen, what’s getting in the way, and what could enable better adoption.

The insights were immediate and actionable.

How the Exercise Works

The Path to Adoption session is structured in two collaborative parts. It helps teams reflect on the full adoption journey, not just from a user’s point of view, but as a cross-functional product team shaping that experience.

Part 1 – Understand the Now

In the first part, the team maps out:

What is currently happening in each adoption phase (from awareness to advocacy)

Where things are working well and where blockers, gaps, or frustrations exist

This helps create a shared understanding of the current state and surfaces hidden assumptions or disconnects across teams.

Part 2 – Shape the Future

Building on the insights from Part 1, the second part invites the team to:

Reimagine what a smooth, ideal adoption experience could look like

Brainstorm concrete actions, enablers, and opportunities to move closer to that vision

Identify cross-team initiatives or experiments that could unblock progress

It’s an open brainstorming format, where everyone contributes, regardless of role. However, product managers would typically facilitate and orchestrate the session, helping to turn the insights into aligned next steps or backlog candidates.

This structure turns “adoption” from a vague challenge into a shared design problem, something teams can actively shape, improve, and own together.

I believe this method can help to bring awareness to the fact that adoption is a shared responsibility across everyone involved in product development. Understanding how adoption unfolds, and where it can stall, equips teams to design and deliver with adoption in mind from the start, not as an afterthought. Each phase informs key decisions around communication, onboarding, documentation, integration, and long-term success.

Looking Ahead

I am continuing to iterate on this approach whenever possible and I am seeing early signals of stronger alignment, better prioritisation, and deeper confidence in the solutions we’re delivering.

Adoption isn’t something we can assume. It’s something we need to design for, track, and continuously improve.

If you’re working on internal products, platforms, or APIs, and you're struggling to get traction, you can think about giving this approach a try.

Feel free use the template above and to connect or message me about it.