Six months after launching an internal developer portal, weekly active usage has plateaued at around forty percent of engineering. How would you go about figuring out why, and what would you actually do about it?
4 min readUpdated 2026-08-15
0
Answer
Short answer
Stalled adoption is rarely a UI problem; segment usage by team and task rather than the aggregate number, then match the fix to whichever of three causes shows up - a missing daily task, a faster existing habit, or data nobody trusts.
Was this answer helpful?
Likely follow-ups
→What would make you recommend shutting the portal down rather than continuing to invest in it?
→How would your diagnosis differ if the forty percent had been declining for the last two months rather than flat?
→Suppose the portal is heavily used by platform and SRE teams but almost unused by product engineering teams. What does that split tell you?
→How do you distinguish a portal people don't need from a portal people don't know exists?
Forty percent weekly active usage is a single figure covering what is almost certainly a very uneven distribution, and treating it as one problem to solve is the first mistake. Before proposing anything, split it: by team, by tenure since the portal launched for that team, and by which feature was used. A platform serving on-call engineers a service catalog they check during every incident and serving product engineers a scaffolding tool they touch twice a year will show very different usage shapes even if both are working exactly as intended. A single aggregate number flattens "used constantly by the people who need it" and "opened once during onboarding and never again" into the same figure, and those have entirely different fixes.
The next split that matters is trajectory, not just current level. A team that never used the portal is a different problem from a team that used it heavily in month one and dropped to nothing by month four — the first is an awareness or relevance gap, the second is a trust or habit failure that happened after they gave it a real try. Pulling usage logs segmented this way, before forming any hypothesis, is the difference between diagnosis and guessing.
Team category Pattern seen Likely cause
-------------------------- -------------------------------- ---------------------------
Adopted, still using Steady weekly usage Working as intended
Adopted, then dropped High in month 1, near zero by 4 Data went stale, or a
faster alternative exists
Never adopted Near zero from week one Doesn't cover their task,
or they never heard of it
The three causes that actually produce this pattern
Once the split is done, the candidates worth investigating narrow to a small set, and each has a distinct signature.
The portal doesn't do anything a given team needs daily. A service catalog is compelling to whoever is on call and needs to find an owner at 2am; it's nearly irrelevant to a team that ships features and rarely touches another team's service. If the "never adopted" segment clusters around teams whose daily tasks the portal simply doesn't serve, the fix isn't marketing — it's building or surfacing a feature relevant to that segment, or accepting that this portal isn't for them.
The portal duplicates something people already do faster. If engineers can find who owns a service by asking in a Slack channel with a fast answer, a portal that requires navigating to a page and running a search is strictly slower for that specific task, and habit will always win against a marginally worse alternative unless the old path is actively removed or degraded. This shows up as a team that tried the portal, found the old way faster, and reverted — the "adopted, then dropped" pattern above, specifically for tasks with a fast informal alternative.
The portal's data is wrong often enough that people stopped trusting it. This is the most damaging cause because it is self-reinforcing: the first time someone pages a listed owner and gets nothing, they don't file a bug against the catalog entry, they just stop using the catalog and go back to asking around. A handful of stale entries can poison trust across an entire team well before the aggregate staleness rate looks alarming in a dashboard.
Loading diagram…
Matching the fix to the cause, not to the symptom
The failure mode in how organisations respond to stalled adoption is applying a generic engagement fix — a leaderboard, a mandate to use the portal, a Slack campaign — to a problem that is actually one of the three specific causes above. A mandate forces usage of a tool people have already learned is unreliable or irrelevant to their work, which produces resentment and workarounds rather than genuine adoption, and it burns the platform team's credibility for the next thing they ship.
The correct response is scoped to whichever cause the segmentation surfaced. If the gap is coverage, the fix is shipping the specific feature the uncovered segment needs, validated with that segment before building it broadly.
If the gap is an informal alternative winning on speed, the fix is either making the portal path faster than the informal one for that specific task, or in some cases actively degrading the informal path — turning off the Slack bot that answered "who owns this" — which is uncomfortable to propose but is sometimes the only thing that actually shifts a habit.
If the gap is trust, no feature work matters until the underlying data quality is fixed and demonstrably fixed, because the trust deficit does not repair itself just because the data got better quietly.
Forty percent is not a problem to solve directly; it's an average masking several different, smaller, and much more tractable problems.