Developers as Customers
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.
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.