Treat the people who use your internal platform like customers, not ticket-raisers. The four journeys every platform has to nail — and how to measure whether it does.
5 concepts 4 decision paths Diagrams
Share
The four journeys (plus the one that keeps you honest)
Click each journey to see the analogy and the metric that exposes whether it works.
The first impression
Journey: Get Access
"Day one at a new office: is your badge ready, or are you waiting at reception?"
'I need access to the platform, an account, or a service.' This is the first time a developer meets the platform. If onboarding is a multi-day chain of tickets and approvals, every later journey starts from a position of distrust. Self-service access with sane defaults, granted in minutes, sets the tone for everything after.
Time-to-first-deploy is the onboarding metric that matters — measured from 'new engineer starts' to 'their code is running'. Six weeks to provision an environment isn't a tooling gap, it's a frustrated engineer who's churned before they've shipped a thing.
The first impression
Journey: Get Access
"Day one at a new office: is your badge ready, or are you waiting at reception?"
'I need access to the platform, an account, or a service.' This is the first time a developer meets the platform. If onboarding is a multi-day chain of tickets and approvals, every later journey starts from a position of distrust. Self-service access with sane defaults, granted in minutes, sets the tone for everything after.
Time-to-first-deploy is the onboarding metric that matters — measured from 'new engineer starts' to 'their code is running'. Six weeks to provision an environment isn't a tooling gap, it's a frustrated engineer who's churned before they've shipped a thing.
Order off the menu
Journey: New Service
"Ordering off a menu vs commissioning a bespoke meal every time"
'I want a new product, service, or environment.' The platform's catalogue is its menu. The journey is great when the common cases are a self-service order — pick from the catalogue, get a paved-road setup with logging, networking, and guardrails already wired in. It's painful when every new service is a bespoke conversation.
A service catalogue is only as good as its coverage. If 80% of requests fit a catalogue item, the platform team spends its time on the interesting 20%. If everything is bespoke, the catalogue is decoration and the team is a queue.
Shift left
Journey: Get Help
"A good help desk answers; a great one means you didn't need to ask"
'Something's broken, or I don't know how.' Support is where trust is won or lost under pressure. The mature version shifts left: searchable docs and runbooks resolve the common case before a human is involved, an in-context assistant handles the next tier, and humans take the genuinely novel problems. Knowledge management is the multiplier.
Shift-left support isn't about deflecting people — it's about not making a human re-answer the same question fifty times. Every resolved ticket that doesn't become a doc is a ticket you'll get again next week.
Safe vs slow
Journey: Change
"Renovating a room you live in — without knocking the house down"
'I need to change something that already exists.' Firewall rules, scaling, a new dependency, a config change. This journey lives or dies on the gap between safe and slow. Encode the safe changes as self-service with guardrails; reserve human review for the genuinely risky ones. Treat every change like the riskiest one and you teach people to batch up changes and route around the process.
When change is uniformly slow, people make bigger, rarer, riskier changes to amortise the pain — the opposite of what you want. Make the safe 90% frictionless and you get smaller, safer, more frequent changes for free.
Run it like a product
Measuring Experience
"You can't run a product on vibes — internal platforms included"
If developers are customers, you measure their experience like a product team would. Internal NPS, time-to-first-deploy, catalogue coverage, ticket deflection, friction instrumented across each journey. The point isn't a vanity dashboard — it's that a falling score is an early warning, and a rising one is the proof the platform is earning its keep.
The metric that exposes everything is internal NPS plus one open question: 'what's the most frustrating thing about the platform?' Engineers will tell you exactly where the friction is. The platforms that improve are the ones that ask, then act on the answer.
Decision framework
Frequently asked questions
What does treating developers as customers actually mean?
It means the people using your internal platform are users with a choice, not ticket-raisers with an obligation. They can always route around you — build their own, use a credit card, or quietly not adopt. So you research their needs, shape a roadmap around demand, measure their experience, and treat a falling satisfaction score as the early warning it is. The alternative is a platform that is technically complete and commercially ignored.
What are the four developer journeys a platform has to nail?
Get access — the first impression, measured by time-to-first-deploy. New service — ordering off a catalogue rather than commissioning a bespoke meal every time. Get help — where trust is won or lost under pressure. And change — modifying something that already exists without knocking the house down. A fifth keeps you honest: measuring the experience, because you cannot run a product on vibes, internal platforms included.
Why does time-to-first-deploy matter so much?
Because it is the platform's first impression, measured from a new engineer starting to their code running. If onboarding is a multi-day chain of tickets and approvals, every later journey starts from a position of distrust. Six weeks to provision an environment is not a tooling gap — it is a frustrated engineer who has churned before shipping anything. Fix onboarding before adding features.
How do you stop the platform team becoming a support queue?
Two levers. Grow the catalogue until roughly 80% of requests fit an existing item, which frees the team for the interesting 20% — if every new service is a bespoke conversation, the catalogue is decoration. And shift support left, so searchable docs and runbooks resolve the common case before a human is involved. Every resolved ticket that does not become a doc is a ticket you will get again next week.
What should a platform team measure?
Internal NPS, time-to-first-deploy, catalogue coverage, ticket deflection, and friction instrumented across each journey. Then add one open question: what is the most frustrating thing about the platform? Engineers will tell you exactly where the friction is, in detail, for free. The platforms that improve are the ones that ask and then act on the answer — a dashboard nobody responds to is a vanity exercise.
