I've watched the same pattern play out at half a dozen organizations. The infrastructure team spends eighteen months building an internal platform. They design it thoughtfully. They implement it carefully. They write documentation. They present it to the engineering organization. And then nobody uses it. Or worse -- people are forced to use it, and they resent every interaction with it.
The platform isn't bad. The technology is sound. The architecture is reasonable. The problem is that it was built like an infrastructure project -- with requirements gathered from leadership, designed in isolation, and delivered as a mandate. Nobody asked the developers what they actually needed. Nobody tested whether the workflows made sense. Nobody measured whether the platform made developers faster or slower. It was built, shipped, and declared a success by the people who built it.
This is what happens when you treat a platform as infrastructure. You get something technically correct and practically useless.
The Product Mindset
The teams that build successful internal platforms approach them with a product mindset. This isn't a metaphor. It's a literal operating model. The platform has users -- the developers who build on top of it. It has a value proposition -- reducing cognitive load and accelerating delivery. It has competitors -- the alternative workflows developers will invent if the platform doesn't serve them. And it has a feedback loop -- usage data, satisfaction surveys, support tickets, and direct conversation with its users.
When you treat a platform as a product, you ask different questions. Not "what should we build?" but "what problems do our developers have?" Not "how do we enforce adoption?" but "how do we make this so good that people choose to use it?" Not "what's our architecture?" but "what's the developer experience?"
The shift is fundamental. Infrastructure projects are evaluated by their technical properties -- uptime, throughput, scalability. Products are evaluated by their outcomes -- did they make the user's life better? A platform can be technically excellent and still be a failed product if nobody wants to use it.
Developers Are Your Customers
The first uncomfortable implication of the product mindset is that your developers are your customers. Not your stakeholders. Not your colleagues. Your customers. This matters because customers have choices. Even in an organization where platform adoption is mandated, developers find workarounds. They build shadow infrastructure. They use their own CI pipelines. They deploy to side accounts. They do whatever they need to do to get their work done without the friction imposed by a platform that doesn't serve them.
I've seen organizations with an official "standard platform" that maybe 40% of teams actually use as intended. The rest have found ways around it -- custom scripts, manual processes, or entirely separate toolchains that the platform team doesn't know about. The platform team reports full adoption because it's mandated. The reality is that the mandate created compliance theater while developers quietly built their own solutions.
Treating developers as customers means doing the things product teams do: user research, usability testing, satisfaction measurement, and -- critically -- accepting that if customers aren't using your product, the problem is the product, not the customers. This is hard for infrastructure-minded teams to accept. The instinct is to write more documentation, schedule more training sessions, or escalate to management for a stronger mandate. None of these work. They're the equivalent of a consumer product company blaming customers for not reading the manual.
Self-Service Over Ticket Queues
The single most reliable indicator of whether a platform team has a product mindset is how developers provision resources. If the answer is "file a ticket and wait," you have an infrastructure project. If the answer is "push a config file and it happens automatically," you have a product.
Ticket-based workflows are the natural output of infrastructure thinking. The platform team controls the resources. Developers request access. Someone reviews the request, provisions the thing, and closes the ticket. This model works when you have five teams and a handful of services. It collapses at scale because the platform team becomes a bottleneck, developers wait hours or days for basic resources, and everyone's time is consumed by coordination overhead that adds no value.
Self-service is the natural output of product thinking. The platform provides capabilities that developers consume on demand. Need a database? Declare it in your service manifest. Need a new environment? Run a command. Need DNS configured for your service? It happens automatically when you deploy. The platform team isn't in the loop for routine operations because the platform itself handles them.
Building self-service is harder than building ticket queues. It requires more upfront investment in automation, guardrails, and sane defaults. But the operating cost is dramatically lower, and the developer experience is incomparably better. A developer who can go from idea to running service in thirty minutes -- without filing a single ticket -- is a developer who ships faster, experiments more freely, and doesn't resent the platform.
Golden Paths, Not Golden Cages
The concept of a "golden path" -- a recommended, well-supported way of doing things on the platform -- is central to good platform design. The golden path for deploying a web service might include: a standardized service template, a preconfigured CI pipeline, automatic provisioning of logging and monitoring, built-in observability dashboards, and one-click deployment to production. Following the golden path should be the easiest option. It should require less effort than doing things a different way.
But here's the critical distinction: a golden path is a recommendation, not a requirement. It's paved and well-lit, but developers can walk off it when they need to. Maybe their service has unusual requirements. Maybe the standard template doesn't support their language. Maybe they need a database topology that the golden path doesn't offer. In these cases, the platform should let them deviate -- with appropriate guardrails -- rather than forcing them into a path that doesn't fit.
Golden cages happen when platform teams mistake standardization for value. They lock down every option, restrict every configuration, and mandate every tool. The intention is consistency and operational simplicity. The result is that developers spend more time fighting the platform than building their products. They file exception requests. They wait for the platform team to add support for their use case. Or they build workarounds that bypass the platform entirely and give you the worst of both worlds -- no consistency and no platform adoption.
The right model is opinionated defaults with escape hatches. The platform has strong opinions about how things should be done, and those opinions are encoded as defaults. But developers can override defaults when they have good reasons. The platform tracks deviations -- not to punish them, but to learn from them. If many teams are deviating in the same way, that's a signal that the golden path needs to be widened.
Measuring What Matters
Platform teams that think like infrastructure projects measure infrastructure metrics: uptime, latency, throughput. These matter, but they're table stakes. They tell you whether the platform is running, not whether it's useful.
Platform teams that think like product teams measure developer experience metrics:
- Time to first deployment. How long does it take a new developer -- or a new team -- to go from zero to a running service in production? This is your onboarding experience, and it's a proxy for how approachable the platform is.
- Deployment frequency. Are teams deploying more often after adopting the platform? If not, the platform isn't reducing friction -- it might be adding it.
- Lead time for changes. How long from code commit to production? The platform should shorten this. If it doesn't, something's wrong with the pipeline.
- Self-service ratio. What percentage of resource provisioning happens through self-service versus tickets? This tells you how much of the platform is actually automated versus manually gatekept.
- Developer satisfaction. Ask your users. Run quarterly surveys. Track NPS. Talk to developers. If satisfaction is declining, your platform is accumulating UX debt regardless of what the infrastructure metrics say.
The metric that matters most is one that's hardest to measure: cognitive load. Is the platform reducing the number of things developers need to think about? When a developer deploys a service, do they need to worry about DNS, certificates, logging, monitoring, scaling policies, and network configuration? Or does the platform handle that? Every concern the platform absorbs is cognitive load removed from the developer. That's the core value proposition.
The Platform Team's Role
In an infrastructure model, the platform team's job is to operate the platform. They provision resources, handle tickets, fix outages, and maintain the underlying systems. They're operators. In a product model, the platform team's job is to make developers successful. They build tools, improve workflows, reduce friction, and enable capabilities. They're enablers.
This is a meaningful difference in how the team spends its time. An infrastructure-oriented platform team might spend 60% of its time on operations and support, and 40% on building new capabilities. A product-oriented platform team inverts that ratio -- 60-70% building, 30-40% operating -- because the platform itself handles most routine operations through automation.
The product model also changes hiring. An infrastructure-oriented platform team hires systems engineers and operations specialists. A product-oriented platform team also hires people with product management skills, UX sensibility, and developer empathy. The best platform engineers I've worked with aren't just technically strong -- they genuinely care about the experience of the people using their systems. They get frustrated when a workflow takes too many steps. They notice when error messages are confusing. They think about discoverability, progressive disclosure, and sensible defaults. These are product instincts, and they're as important as technical skills in a platform context.
The "Build It and They'll Come" Trap
The most expensive mistake a platform team can make is building in isolation and expecting adoption. I call this the "build it and they'll come" trap, and it's startlingly common. A team goes heads-down for six to twelve months. They emerge with a polished platform. They demo it. And then they're surprised when adoption is slow.
The problem is that they skipped the discovery phase. They built what they thought developers needed instead of what developers actually need. These are often different things. The platform team might build a sophisticated deployment pipeline with blue-green deployments, canary analysis, and automated rollback. Meanwhile, developers are struggling with something much more basic -- they can't get a development environment that resembles production, so they're debugging issues that only manifest after deployment. The fancy pipeline doesn't help if developers can't test locally.
Product teams avoid this trap by building incrementally and validating continuously. Ship a small thing. See if people use it. Get feedback. Iterate. Ship the next thing. This is harder for platform teams because infrastructure has long feedback cycles and high setup costs. But the principle still applies: start with the smallest useful capability, validate it with real users, and build from there.
A practical approach: pick one team -- ideally a friendly one -- as your design partner. Build for their needs first. Work with them closely. Watch them use the platform. See where they struggle. Fix those things. Then expand to the next team. Then the next. By the time you're rolling out to the broader organization, you've iterated on real feedback from real users and the platform actually works for the way people do their jobs.
The Feedback Loop
Products live or die by their feedback loops. Internal platforms are no different. The platform team needs mechanisms for hearing from their users that are lightweight, continuous, and actionable.
This means more than a Slack channel and an annual survey. It means embedded time with development teams -- platform engineers pairing with developers, sitting in their standups, watching their workflows. It means instrumenting the platform to understand usage patterns -- which features are used, which are abandoned, where developers get stuck. It means regular office hours where developers can ask questions and surface pain points. And it means treating every support ticket not just as a problem to solve, but as a data point about where the platform is falling short.
The teams that build the best internal platforms are the ones that are closest to their users. Not closest in the org chart -- closest in daily practice. They know what developers are struggling with because they've seen it firsthand. They prioritize ruthlessly because they understand which problems are most painful. And they ship things that people actually want because they've validated the need before writing the code.
If you have to mandate adoption, your platform has already failed as a product. The best internal platforms win by being genuinely better than the alternative -- so much better that developers choose them voluntarily.
Treat your platform like a product. Know your users. Measure their experience. Build self-service capabilities. Pave golden paths with escape hatches. Iterate on feedback. And judge your success not by whether the platform runs, but by whether developers are better off because of it. The infrastructure will follow. The adoption will follow. But only if you start by solving real problems for real people.