A product grows quickly, then it does not. Acquisition is still working — signups are flat or even up — but activation has drifted down and the growth curve has bent. The usual response is to look harder at the top of the funnel: new channels, better landing pages, more content. Sometimes that helps. More often it pours more people into the same leak.
Adjacent user theory offers a different diagnosis. It says the plateau is usually not an acquisition problem at all. It is that your product has become excellent for the users you already have, and the next user out — one step less technical, one step different in job or context or starting conditions — keeps arriving, keeps trying, and keeps failing to reach the moment where the product makes sense.
The idea was articulated by Bangaly Kaba, drawing on growth work at Instagram, and its usefulness comes from being uncomfortably specific: it insists you name the group, understand why they fail, fix that, and then do it again, because by then the adjacent user has moved. This guide covers how to find yours in your own data, what to change for them, and the traps that make teams either miss them entirely or chase them too far.
Key Takeaways
- A plateau is usually a serving problem, not an acquisition problem. The next users are already arriving; they just are not succeeding.
- The adjacent user is defined by failure to activate, not by demographics — find them in activation data, not in a persona deck.
- They are one step out, not three. Serving someone far outside your core requires changes that damage it; serving the next ring rarely does.
- The fix is usually the first session. Different starting state, different first task, more guidance at the steps that assume knowledge they lack.
- Averages hide them. An overall activation rate of 42% can be 70% for the core and 15% for the group you are about to lose.
- It is a loop, not a project. Serve one ring and the adjacent user becomes someone else — which is what keeps growth compounding.
What Adjacent User Theory Says
The adjacent user, in one paragraph
Your adjacent user is the group of people who are aware of your product and attempt to use it, but cannot succeed with it in its current form — and who sit immediately outside the users it already serves well. They are not a market you have failed to reach; they are in your signup data, dropping out of onboarding this week. Adjacent user theory holds that most growth plateaus are caused by this group being persistently unserved, and that growth resumes when you identify them precisely, understand why they fail, and change the experience for them specifically.
The framing is deliberately relative. There is no permanent adjacent user, because the position moves: once you serve today's, they join the core and someone one step further out becomes the adjacent group. That is what makes it a loop rather than an initiative, and it is also why teams that run it once and stop see growth flatten again a couple of quarters later.
Users the product was built for. They activate reliably, retain well, and their feedback dominates your backlog because they are the ones still around to give it.
Arriving now, trying, and failing. Differs from the core in one or two attributes — context, expertise, starting data, or the job they came to do. Invisible in averages.
Would need changes that make the product worse for rings 0 and 1. A real market later; a distraction now. Serving them is a different product decision, not a growth loop.
Why one ring at a time. The changes required to serve ring 2 usually conflict with what makes the product good for ring 0 — the classic version is stripping an interface down for a novice and removing the density an expert relies on. Ring 1 is close enough that the fix is normally additive: a different first session rather than a different product.
It Is Not a Persona, and It Is Not a Segment
These three get conflated constantly, and the difference is practical rather than semantic.
| Persona | Segment | Adjacent user | |
|---|---|---|---|
| What it is | A research artefact describing a type of user | A group of your users defined by shared attributes | A position: whoever is failing at the edge of what you support |
| Built from | Interviews and research, usually with people who stayed | Product and account data | Activation failure data, then interviews |
| How often it changes | Yearly, if that | Whenever you redefine it | Every time you successfully serve the current one |
| What it is for | Shared understanding of who you build for | Targeting and measurement | Deciding what to fix next |
In practice they work together: personas give you the vocabulary, segmentation is the mechanism that lets you build and target the cohort, and adjacent user theory is the strategy that says which cohort to point it at. The one real warning is that personas are usually derived from users who succeeded, which means the adjacent user is precisely the group your personas do not describe.
Finding Your Adjacent User in Your Own Data
This is a two-day exercise, not a quarter-long research programme. The data half tells you who is failing; the conversation half tells you why, and you need both.
1. Split by activation, not by revenue
Take everyone who signed up in a recent window — long enough ago that they have had a fair chance to activate — and split them into activated and not. If you do not have a single defensible activation event, define one first; our guides to the aha moment and user activation cover how to choose one that predicts retention rather than one that flatters the funnel.
2. Find the attributes that differ
Compare the two groups across every attribute you actually hold. The dimensions below are the ones that most often separate a core user from an adjacent one — and note how many of them are about starting conditions rather than about the person.
Do they expect to configure something, or expect it to work? The single most common dividing line in early-stage products.
Your core arrives with a spreadsheet to import. The adjacent user arrives with nothing and meets an empty product.
Same tool, different reason for buying it. The first task that convinces one job is irrelevant to another.
In B2B especially: can this person actually make the change the product requires, or do they need someone else?
Users from a comparison article and users from a colleague's recommendation arrive with entirely different expectations.
Device, connection, language, whether they are doing this in one sitting or in five-minute gaps between other work.
3. Locate exactly where they stop
For the failing cluster, map the onboarding funnel step by step and find the specific step where they diverge from the core. Almost always there is one, and it is almost always a step that assumes something — a concept, a piece of data, a permission — that the core happened to have. Our onboarding funnel guide covers building that view.
4. Talk to a dozen of them
The data gives you the where; only conversation gives you the why, and the why determines whether the fix is a sentence of copy or three months of engineering. Ask what they were trying to accomplish, what they expected the step to do, and what they did instead when it did not work. An in-app survey at the drop-off point catches people while they still remember.
The adjacent user is visible the moment you stop looking at the funnel as a single population.
The averaging trap. An overall activation rate of 42% is compatible with 70% for the core and 15% for the cohort you are about to lose. Any metric reported as a single number for all users will hide the adjacent user by construction — which is why plateaus so often arrive as a surprise even in teams that watch their funnel closely.
What to Change for Them
The instinct is to reach for the product roadmap. Start with the first session instead: it is where adjacent users are lost, it is cheap to change, and the change can be delivered to that cohort only, which protects the core.
1. A different starting state
If your core arrives with data to import and the adjacent user arrives with nothing, the first screen is an empty product — and an empty product is not a demo of anything. Offer sample data, a template, or a guided path that produces something real within the first few minutes. Our empty states guide covers how to make that first screen do work.
2. A different first task
The task that convinces your core is chosen for the job they came to do. If the adjacent user came for a different job, walking them through the core's first task is a demonstration of something they did not ask for. Pick the shortest path to a visible result for their job, and route them to it explicitly — this is the practical heart of asking users what they came to do before showing them anything.
3. Guidance at the two or three assuming steps
You do not need a longer tour; you need help at the specific steps that assume knowledge this cohort lacks. A short contextual walkthrough on those steps only, shown to that cohort only, is usually the highest-return change in the whole exercise — and it costs the core nothing because they never see it. See our guide to product tours that convert for how to keep it short enough to be finished.
4. Their vocabulary, not yours
Products accumulate internal language that the core has learned and nobody else has. If the adjacent user's failure step involves a term you invented, the cheapest possible fix is a sentence of microcopy that explains it where it appears. Do this before considering anything structural.
5. A shorter path, not a simpler product
Resist rebuilding the product for the new cohort. What usually works is a shorter, more guided route to the same value — progressive disclosure, with the depth still available for anyone who goes looking. Our progressive onboarding guide covers how to stage that without hiding things people need.
A branching first question is the cheapest way to send the adjacent cohort down its own path without touching the core's.
The reason all five of these sit in onboarding rather than in the product is worth stating plainly: a change to onboarding can be targeted, measured and reversed within a week, and a change to the product cannot. Establish that the diagnosis is right by fixing the first session first. Then, if the cohort activates but does not retain, you have earned the right to a roadmap conversation — and much better evidence for it.
The Loop, and When to Stop
Run it as a repeating cycle rather than a project: identify → understand → serve → repeat. Each pass should take weeks, not quarters, and each pass ends with a measurement rather than a launch.
A ring is closed when two things are true at once. First, the cohort's activation rate has moved materially towards the core's. Second — and this is the half teams skip — the core's own activation and retention are unchanged. A change that lifts a new cohort while quietly costing the core is normally a net loss, and because the core is larger it will not show up in the overall number for months. Watch both curves separately for at least one full retention cycle; our retention curve guide covers reading them without fooling yourself.
Then start again, because the adjacent user has moved outward. This is the mechanism behind products that keep compounding long after their obvious market looked saturated: they were not finding new channels, they were repeatedly making themselves usable by the next ring of people who were already showing up.
Four Ways Teams Get This Wrong
- Building for the loudest users instead of the next ones. Feedback comes overwhelmingly from the core, because the adjacent user left before they had an opinion worth sending. A backlog built purely from inbound feedback is a machine for over-serving ring 0 — the mechanism behind most feature bloat.
- Jumping two rings out. Choosing a dramatically different audience because the market looks bigger. The changes required conflict with the core, the core notices, and the new audience still does not activate because the gap was never one step.
- Reporting activation as one number. Guarantees the adjacent user stays invisible until the plateau is already visible on the growth chart.
- Treating it as a one-off project. A "new user experience initiative" ships, growth resumes, the team moves on, and two quarters later the curve bends again for exactly the same reason one ring further out.
The B2B Version: The Adjacent User Is Down the Hall
In B2B the rings are often inside a single customer rather than across the market, and the pattern is unusually consistent. The champion who ran the evaluation is a power user by definition: motivated, technically comfortable, and present for every demo. The product is then rolled out to their colleagues, who are none of those things, and the account shows one very active seat surrounded by nine dormant ones.
That second-wave role is your adjacent user, and the diagnosis is the same: they came for a different job, arrived without the context the champion accumulated over six weeks of evaluation, and hit a first session designed for someone who already knew why they were there. The fix is also the same — a different first task for that role, guided, delivered to them and not to the champion. Our guides to enterprise onboarding and personalised onboarding cover the mechanics, and the single most useful account-level metric here is the ratio of active to provisioned seats rather than total account activity.
Serve the next ring without touching the core
Kompassify lets you show a different onboarding path to a specific cohort — tours, checklists and contextual tooltips targeted by behaviour or attributes, built without engineering time — and shows you where each cohort drops off, so you can find your adjacent user and fix their first session in the same week. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →The One-Sentence Version
Adjacent user theory says your growth plateau is standing in your signup data right now, failing at a step your core users never noticed — so before buying more traffic, split activation by cohort and find out who is one step outside the product you have actually built.
Frequently Asked Questions
What is adjacent user theory?
Adjacent user theory is the idea that a product's growth plateau is usually caused by the next group of users just outside the current core — people who are aware of the product and try it, but cannot succeed with it because it was designed for someone slightly different. The theory was articulated by Bangaly Kaba, drawing on growth work at Instagram, and its central move is to reframe a plateau as a serving problem rather than an acquisition problem. The adjacent user is defined by failure to activate, not by demographics.
How do you identify your adjacent user?
Look at activation rather than acquisition. Take everyone who signed up in a recent window, split into those who reached your activation event and those who did not, and then find the attributes that differ between the two groups — acquisition channel, company size, technical background, device, country, whether they arrived with existing data, and which job they were trying to do. The adjacent user is the largest coherent cluster on the failing side that is only one step removed from your core. Then talk to a dozen of them, because the data tells you who is failing but not why.
What is the difference between an adjacent user and a persona?
A persona is a research artefact describing a type of user, usually stable for a year or more and often built around the users you already serve well. The adjacent user is a moving position defined relative to your current core: it is whoever is failing right now at the edge of what your product supports, and it changes every time you successfully serve the previous one. Personas answer 'who are our users'; adjacent user theory answers 'who is the next group we could serve, and what is stopping them today'.
How is it different from user segmentation?
Segmentation divides the users you have so you can target them differently. Adjacent user theory is about the users you are losing, and it is directional — it points at the specific ring immediately outside your current success zone rather than at all possible groups. In practice you use segmentation as the tool and adjacent user theory as the strategy: segmentation lets you build the cohort and serve it differently, and the theory tells you which cohort deserves that effort next.
Why not just serve everyone at once?
Because the changes that make a product work for someone two or three rings out usually damage it for the core. Simplifying an interface for a novice removes the density an expert depends on; adding an assisted setup path for a non-technical buyer can slow down the technical one. Moving out one ring at a time keeps each change small enough to be reversible and specific enough to measure, and it means the change can be delivered to the new cohort only — which is what makes onboarding personalisation the natural implementation of the theory.
What do you actually change for an adjacent user?
Almost always the first session rather than the core product. The most common effective changes are: a different starting state, because they arrive with no data to work with; a different first task, because the one that convinces your core is irrelevant to them; more guidance at the two or three steps that assume knowledge they do not have; different vocabulary in the empty states and onboarding copy; and a shorter path to a visible result. Deep product changes are sometimes required, but onboarding is where you should look first and it is where the cheapest wins are.
How do you know if you have successfully served an adjacent user?
The activation rate of that specific cohort rises towards the core's rate, while the core's own activation and retention are unchanged. Both halves matter. A change that lifts the new cohort and quietly costs the core is usually a net loss, and it will not show in an overall number because the core is bigger. Watch both curves separately for at least one full retention cycle before declaring the ring closed, then repeat the exercise, because the adjacent user has moved outward by then.
Does adjacent user theory apply to B2B products?
Yes, and the rings are often clearer. The adjacent user in B2B is frequently a different role inside the same customer rather than a different company — you serve the power user who was in the sales cycle, and the plateau appears when their colleagues are meant to adopt it. The signal is an account where one seat is highly active and the other nine are dormant. The response is the same: work out what the second-wave role's first successful task should be, and design a first session around that rather than around the champion's workflow.