Platform Product Management: Turning Internal Infrastructure into a Product Teams Adopt

The platform nobody asked for

Platform product management starts with an uncomfortable admission: your platform can be technically excellent and still sit unused. Gartner forecasts that 80% of large software engineering organizations will establish platform engineering teams by 2026. Most of those teams will ship something. Fewer will ship something developers find worth using.

The gap usually comes from treating internal infrastructure as a delivery project with a launch date and a handover. Platform engineering and platform product management are different disciplines, and the gap sits between them. Platform engineering delivers the technical capabilities: pipelines, infrastructure automation, self-service tooling and the reliability behind them. Platform product management decides which capabilities to build first, how teams will be brought onto them, and how the organization will know they deliver value. The sections below show how to add the second discipline to the first, and what it changes about discovery and the numbers you report upward.

Why infrastructure projects stall

A delivery-focused infrastructure project is scoped once and built against assumptions made at the start. That model works for a data center migration. It fails for a developer platform, because the thing you're building is a daily working surface for people whose workflows keep changing underneath you.

Matthew Skelton, co-author of Team Topologies, described what this looks like in practice: "I've definitely seen teams when I was a consultant that built out amazing kind of mini Amazons, mini clouds without even talking to the developers. I'm like, no wonder they're not using it. You never talk to your customer." Octopus Deploy calls the same pattern a Field of Dreams platform, where you discover the product-market fit problem only after the build is done.

Weak ownership makes it worse. When nobody is accountable for whether developers get value, the platform drifts into a request queue, and the loudest stakeholder sets priorities. Mandates can paper over the symptom. Some requirements are legitimately mandatory, such as security controls or approved deployment processes in a regulated environment. But when usage is compulsory across the board, adoption numbers look fine while the feedback signal that would improve the platform disappears.

The data backs the caution. DORA’s 2024 report, based on a survey of nearly 3,000 technology professionals, found that internal developer platform users reported 8% higher individual productivity and 10% higher team performance. They also reported an 8% decrease in throughput and a 14% decrease in change stability. These are survey correlations, and DORA offered possible explanations, such as extra hand-offs between systems and teams, rather than proof of cause. Platforms don’t automatically pay off. Coverage of the report notes that teams tended to recover when they listened to developer feedback, which is the work platform product management does. DORA’s 2025 report, the latest edition, found that 90% of organizations in its data had adopted at least one platform, and that a high-quality internal platform correlates with an organization’s ability to unlock value from AI.

What platform product management changes

Three things change at once. Developers become customers whose needs shape the roadmap, the platform team is judged on outcomes rather than tickets closed, and leadership funds an enduring capability instead of a project with an end date. The Cloud Native Computing Foundation (CNCF) maturity model names the third shift explicitly: investment moves from “dedicated team” to “as product” as organizations mature. Customer doesn’t always mean someone with a choice. Some platform controls will be mandatory, and the product work is to make them as easy to follow as possible.

That reframing needs someone accountable for it. In Puppet’s 2024 State of DevOps Report, a vendor-run survey of about 500 people who work with platform teams, 52% called a product manager crucial to a platform team’s success and another 21% called it nice to have. The same report found organizations still under-investing in product management skills on platform teams. Read these as practitioner sentiment, not proof that a product manager causes better outcomes.

Responsibilities split roughly like this across a growing engineering organization. Smaller teams can combine roles, but each responsibility still needs a named owner:

• The Chief Technology Officer (CTO) or VP of Engineering funds the capability and defends the platform's roadmap against quarter-to-quarter reprioritization.

• The platform product lead (a dedicated product manager, or a tech lead or engineering manager who holds the role) owns discovery and the internal platform roadmap. This person says no to requests that serve one team at the expense of twenty.

• Platform engineers build and operate the capabilities, and they carry the support load that comes with them.

• Enablement or developer advocacy handles onboarding and the training that turns a capability into a habit.

• Security and compliance partners define the mandatory controls and encode them into the platform’s defaults instead of reviewing each team separately.

A dedicated product manager isn’t mandatory for every organization. In a small engineering team, one person can hold several of these roles, or the product responsibilities can be shared, provided accountability is explicit: someone owns prioritization, someone owns adoption and enablement, and someone owns the measures. What fails is the version where everyone assumes someone else owns the roadmap. Notice what’s missing from the list: a steering committee that approves features. Learn more about platform engineering and its role in reducing operational drag.

Research developer needs

You can't prioritize friction you haven't seen. Atlassian's 2025 developer experience research, based on 3,500 developers and managers across six countries, found that 63% of developers say leaders don't understand their pain points, up sharply from 44% the previous year. The top time sinks were finding information about services and APIs, and context switching between tools.

Continuous discovery is how platform product management stays ahead of that. It is a standing rhythm of conversations and observation that keeps running after launch. The ACM Queue paper by Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler gives you a useful lens here as it distills developer experience into three measurable dimensions. Friction that shows up across all three is platform work. Friction confined to one repo isn't.

The hard part is separating a shared need from an isolated request. A single team asking for a new database engine is a preference. Four teams independently writing the same deployment wrapper is a signal, and that distinction is what keeps the platform thin enough to maintain.

Choose research participants

Pick people who disagree with each other. Include developers from teams that adopted the platform early and teams that never touched it, because the ones who opted out carry the information you most need. Mix experience levels too, since a staff engineer who's memorized every workaround will describe a smooth workflow that a new hire finds impenetrable.

Cover the architectural variety that actually exists in your estate. A team running a monolith on virtual machines has different constraints than one shipping twelve services into Kubernetes, and a platform designed only for the second group quietly excludes the first.

Interviews alone will mislead you, because people describe their intentions rather than their behavior. Pair them with workflow observation and usage analytics from the platform itself. When what developers say and what the telemetry shows disagree, that disagreement is the finding.

Ask better discovery questions

Stop asking what features people want. Ask about the work:

1. What task were you completing the last time you opened the platform?

2. Where in that task did you wait on someone, or switch tools to get an answer?

3. What breaks repeatedly, and what do you do when it breaks?

4. What workaround have you built that you'd be embarrassed to show us?

5. What would have to be true for you to choose self-service over filing a ticket?

That last question matters most. It moves the conversation from compliance to preference. For optional capabilities, preference is where adoption is won. For mandatory controls, it shows what would make them easier to follow.

Use a product canvas

Research produces a pile of observations. A canvas turns that pile into a decision you can defend before anyone commits engineering time. It's a single page that forces agreement on who you're serving and what you're choosing not to build, and it takes an afternoon rather than a quarter.

The point is the argument the artifact forces, because a canvas makes disagreement visible early, when changing direction costs a conversation instead of six months of delivery.

Platform as a product canvas

Keep it compact enough to read in one sitting. A workable platform as a product canvas covers:

• Customers: which teams and which ones you're explicitly not serving yet.

• Jobs and pain points: the workflows developers are trying to complete and where those workflows break.

• Business outcomes: the delivery or risk measures leadership expects to move.

• Value proposition: why a developer would choose this over the thing they do today.

• Capabilities and golden paths: the supported routes through common work.

• Constraints: compliance obligations, mandatory controls, and the architecture you can’t change.

• Adoption channels: how teams find out and get help.

• Costs and measures: what it takes to run and how you'll know it's working.

The capabilities row is where discipline pays. Team Topologies calls the target a "thinnest viable platform", and co-author Manuel Pais frames the decision rule as starting from your internal teams' workflows and then figuring out the minimum thing that helps. Everything beyond that minimum is cognitive load you've moved from the application teams onto your own.

Test canvas assumptions

A canvas is a set of bets. Validate it with a small cohort of two or three teams who agreed to work with you, and watch whether they complete a real task end to end without a platform engineer in the room. If they can't, the value proposition row is wrong.

Write down the assumptions you couldn't resolve and date them. Platforms accumulate stale beliefs faster than most product work, because the underlying architecture and the organization’s priorities both move. Revisit the canvas when a major workflow changes or when adoption flattens, and change it in front of the people who use it rather than quietly.

Set vision and boundaries

Vision is the shortest useful sentence about what the platform does for the business. Boundaries are what stop it from becoming everyone's dumping ground. You need both, and the second is harder to hold.

Golden paths are how the vision becomes concrete. Spotify defines a Golden Path as the "opinionated and supported" path to build something, paired with a step-by-step tutorial that walks an engineer through it. A good path covers the workflows most teams run most often and encodes your security and compliance guardrails into the defaults. A path that covers an edge case used four times a year is a path that nobody maintains.

Consider a team that needs a new service in a regulated environment. Without a platform, it waits on a ticket for a repository, another for a pipeline, a third for network and cloud resources, and then on a security review of whatever was assembled. With a golden path, the same request starts from a standardized CI/CD pipeline template, infrastructure defined as code in a reviewed module, and automated security controls (dependency and image scanning, secrets detection, policy checks) that run on every commit. Provisioning becomes a self-service request that behaves the same way every time, and manual administrative work moves from repeated one-off reviews to one review of the template. The change shows up in time from request to first deployment and in manual hand-offs per service, so baseline both before the platform goes live.

Standardization also supports auditability and control enforcement. When every service is built and deployed through the same pipeline, change records, approvals, scan results and access logs are produced consistently, so an auditor can sample evidence from one system instead of reconstructing it team by team. Mandatory controls, such as required scans or approved base images, can be enforced as pipeline defaults rather than checked after release. This maps onto control areas in frameworks such as ISO/IEC 27001, including change management, configuration management, secure development and logging. A platform supplies evidence and enforcement, but it does not make an organization compliant. That still depends on the wider management system: scope, risk assessment, policies, the people who operate them, and whether the platform’s controls are actually mapped to the framework’s requirements.

Flexibility matters as much as the paths themselves, but it has limits. Netflix frames its approach as a paved road inside a freedom and responsibility culture, where teams with a legitimate reason to leave the road can, and accept the operational responsibility that follows. In a regulated enterprise, governance sets the boundary: mandatory security controls and standardized deployment processes apply to everyone, and developer choice operates inside what has been approved. Within that boundary, let the road win on merit, and treat the exits teams actually use as a signal of where the path is getting worse.

State the boundaries plainly in the same document as the vision. What the platform supports and what a team gets if they go their own way. Ambiguity here is what produces the support load that eventually swallows the roadmap.

Build the internal platform roadmap

An internal platform roadmap sequences problems. Each candidate gets assessed on how many teams it reaches and how strong the evidence is. Items with thin evidence go back to discovery rather than onto the list.

The balance that breaks most teams is between new capabilities and the unglamorous work that keeps existing ones usable. Reliability and maintenance have to hold real roadmap capacity, because a golden path that silently rots is worse than no golden path. Octopus Deploy's 2025 platform engineering research points at the same thing when it describes platforms moving through a normal J-curve pattern during years two through five, where delivery metrics dip before they recover. That dip is where underfunded platforms get abandoned.

Here's the test for whether you have a roadmap or a queue. If every item traces to a request from a named stakeholder, you have a queue with better formatting. An internal platform roadmap has items on it that nobody asked for, because discovery found a problem the people living with it had stopped noticing. Teams can also use infrastructure as code to make platform changes repeatable and governed.

Earn adoption through service

Onboarding and documentation are product work. They're not overhead around the real engineering. Kathryn Koehler, director of productivity engineering at Netflix, has been candid about where this goes wrong as she notes that platform teams write documentation "from the platform provider perspective, rather than the customer's perspective." She also named documentation as the top thing developers want and the hardest habit to sustain.

Onboarding is where the service layer shows up first, and vendor-reported figures give a sense of scale. In a 2020 post, Humanitec’s CEO reported that teams surveyed before and six months after adopting an internal developer platform, a mix of in-house builds and Humanitec customers, saw developer onboarding fall from 30 hours to 4 hours and average deployment frequency rise from 1.5 to 6 per week. This is a vendor’s selected-team data, not independent research, so use it to illustrate what’s possible and baseline your own numbers before setting targets. Whatever the size of the gain, a developer who can’t find the path doesn’t walk it.

Repeat usage is the honest signal wherever teams have a choice. A team that came back next sprint without being reminded tells you something a mandated enrollment number never will. For mandatory controls, measure something different: how much effort compliance costs teams, and how often they ask for exceptions. The CNCF maturity model captures the broader direction as the move from “extrinsic push” to “intrinsic pull” in how users discover and use platform capabilities.

Treat your support channel as a research instrument. When the same question appears eight times in a month, that's a design defect, and it belongs on the internal platform roadmap as a defect rather than in a backlog of nice-to-haves. Review those patterns on a fixed cadence.

Fund and measure outcomes

Fund the platform the way you’d fund a revenue product: a sustained allocation rather than a one-off project budget. Project funding produces project behavior, where the team optimizes for a launch and then disperses. Puppet’s 2024 report also notes that securing investment remains a challenge for platform teams, which is why a clear outcome story matters when you make the budget case.

Build that story from measures that span three layers. Adoption and experience: where use is optional, the share of teams choosing golden paths and their repeat usage, plus developer satisfaction across the board. Delivery performance: your DORA throughput and instability metrics, tracked per application rather than per person. Business outcomes: time to market for new features and incident cost.

Activity metrics alone will mislead you. Number of capabilities shipped and tickets closed go up while developer experience goes down. A review of platform engineering literature published in Frontiers in Computer Science flags exactly this risk because organizations over-index on what is easy to measure and neglect whether developers actually find the platform useful. Survey data and telemetry have to sit side by side, because either one alone can be read as good news. See how DORA metrics support delivery measurement across shared platforms.

Assess the current state

Run a short, honest check across seven questions. Is there a named owner of outcomes, whether a dedicated product manager or a clearly assigned shared role? Do you talk to developers on a schedule, or only before a build? Does the internal platform roadmap contain problems or only stakeholder requests? Where adoption is optional, do you know your repeat-usage rate, and where controls are mandatory, do you know what they cost teams in effort? Is support feeding the roadmap? Is funding sustained? And can you connect platform product management to a delivery or business number?

Each question you answer with a shrug is where the next quarter's work sits. The gap is in the ownership and the evidence.

ABS Technologies builds and operates cloud and DevOps capabilities for companies where software is the business, which is the same work that turns an internal platform into something teams choose. If your platform is technically sound but adoption is thin, contact our team for a current-state assessment and a prioritized platform product management roadmap.