# Developers as Customers Source: John Bradshaw — https://bradshaw.cloud URL: https://bradshaw.cloud/strategy/developers-as-customers/ Type: insight Date: 2026-06-06 Updated: 2026-08-15 Tags: Developer Experience, Platform Engineering, Strategy > 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. ### Journey: Get Access _The first impression_ **Analogy:** 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. **Business take:** 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. ### Journey: New Service _Order off the menu_ **Analogy:** 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. **Business take:** 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. ### Journey: Get Help _Shift left_ **Analogy:** 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. **Business take:** 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. ### Journey: Change _Safe vs slow_ **Analogy:** 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. **Business take:** 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. ### Measuring Experience _Run it like a product_ **Analogy:** 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. **Business take:** 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 ### How long is time-to-first-deploy for a new engineer? **Measure it. If it is weeks, fix onboarding before adding features.** The access journey is the first impression. A multi-day ticket chain to get an environment churns engineers before they ship. Self-service access with sane defaults, granted in minutes, sets the tone for every later interaction. ### What share of requests fit a catalogue item? **Low → everything is bespoke and the team is a queue. Grow the catalogue.** A service catalogue that covers 80% of demand frees the platform team for the interesting 20%. If every new service is a bespoke conversation, the catalogue is decoration and provisioning does not scale. ### Does a resolved support question become a doc? **No → you will answer it again next week. Shift knowledge left.** Mature support resolves the common case before a human is involved — searchable runbooks, then an in-context assistant, then humans for the novel problems. Every ticket that does not become reusable knowledge is a recurring tax. ### Is every change as slow as the riskiest one? **Yes → people batch up risky changes. Make the safe 90% self-service.** Uniformly slow change pushes teams toward bigger, rarer, riskier releases. Encode safe changes as guardrailed self-service and reserve human review for genuinely risky ones — you get smaller, safer, more frequent changes. ## 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. ## Diagrams Standalone SVG diagrams, licensed CC BY 4.0 with attribution to John Bradshaw — link back to https://bradshaw.cloud/strategy/developers-as-customers/ when embedding. - [Journey: Get Access (SVG)](https://bradshaw.cloud/strategy/developers-as-customers/diagrams/onboarding.svg) - [Journey: New Service (SVG)](https://bradshaw.cloud/strategy/developers-as-customers/diagrams/provision.svg) - [Journey: Get Help (SVG)](https://bradshaw.cloud/strategy/developers-as-customers/diagrams/support.svg) - [Journey: Change (SVG)](https://bradshaw.cloud/strategy/developers-as-customers/diagrams/change.svg) - [Measuring Experience (SVG)](https://bradshaw.cloud/strategy/developers-as-customers/diagrams/measure.svg) ## Related - [Platform Operating Model](https://bradshaw.cloud/strategy/platform-operating-model/) — the org model behind the experience. - [FinOps Maturity](https://bradshaw.cloud/strategy/finops-maturity/) — the cost discipline that runs alongside the platform. - [Team Topology Decisions](https://bradshaw.cloud/strategy/team-topologies/) — the team shapes that produce the experience. - [Content Wars to Experience Wars](https://bradshaw.cloud/strategy/content-wars-to-experience-wars/) — the same experience-over-access argument, for media. - [All strategy insights](https://bradshaw.cloud/strategy/)