TL;DR: A platform roadmap is healthy when product teams recognize their own pain in it. Treat the platform as a product with users, map work into capabilities that carry a promise and an adoption path, sequence by impact on delivery flow, and measure adoption rather than shipped features — a platform capability nobody uses is inventory, not value.
Start with product friction
Every platform roadmap I have reviewed falls into one of two genres. The first reads like a product document: "reduce time from merge to production", "make the third-party sandbox stop blocking QA", "kill the manual certificate renewals that caused two outages". The second reads like an infrastructure wish list: "migrate to service mesh", "adopt the new cluster API", "evaluate the next-generation build system".
The first genre earns budget and goodwill, because product teams can see their own pain in it. The second competes with product delivery for resources while promising benefits only the platform team can perceive — and it loses that competition, slowly and then suddenly, at the next planning cycle.
The platform exists to make everyone else faster. A roadmap that cannot be traced back to somebody's friction is a hobby with a budget line.
This does not mean infrastructure work is illegitimate — the mesh migration might be exactly right. It means the roadmap entry must be written in terms of the friction it removes, because that phrasing is also the test of whether it removes any.
The platform is a product
The single most useful framing shift for platform teams: your product engineers are your users, and they have alternatives. They can build shadow tooling, copy-paste that one Jenkinsfile forever, or quietly route around your golden path. Platform adoption is voluntary in practice even where it is mandatory on paper — and treating it as voluntary produces better platforms.
Taking the product framing seriously has concrete consequences:
- Discovery over assumption. Sit with product teams and watch a deploy, an incident, an onboarding. The friction you observe is real; the friction you remember from your own last product job is stale.
- A request intake that is not a queue of doom. Product teams need a visible path from "this hurts" to a roadmap decision, with an honest yes, no, or later — silence is what breeds shadow infrastructure.
- Deprecation with migration paths. Removing a capability without an assisted path off it is how platform teams spend years of goodwill in a week.
Map platform capabilities
Roadmap items shaped as projects ("Terraform migration Q3") hide their purpose. I group platform work by capability instead — deploy, observe, secure, integrate, test, recover — because a capability has a user and a promise, which makes both progress and gaps visible.
Capability: deploy
User: product engineer
Promise: production change in under 30 minutes, rollback in under 5
Current: 55 min median, rollback manual and unrehearsed
Adoption: service template, docs, one migrated example, office hours
Capability: observe
User: on-call engineer
Promise: any service's impact dashboard reachable in 2 clicks
Current: 60% of services on the standard dashboard layout
Adoption: dashboard-as-code module wired into the templateTwo properties make this map more useful than a project list. The promise is a service level product teams can hold you to, which builds exactly the kind of trust budgets are renewed on. The current state line keeps the roadmap honest — the gap between promise and current is the roadmap, and it is visible to everyone.
Sequence by flow impact
With capabilities mapped, sequencing stops being political and starts being arithmetic. The question for every candidate item: how much repeated waiting, risky manual work, or support burden does this remove, multiplied by how many teams hit it, and how often?
| Candidate | Who hits it | Frequency | Flow impact |
|---|---|---|---|
| Self-service database branching | Every product team | Daily | Removes the top support-ticket category |
| Deploy pipeline 15 min faster | Every product team | Several times daily | Compounds on every change shipped |
| Exotic build cache tuning | One team | Weekly | Real but narrow — later |
A roadmap item that saves every team one hour per week beats a niche optimization even when the niche one is technically more interesting — and it is usually the niche one that is more interesting, which is why the arithmetic matters. Two categories deserve a standing priority override: risky manual steps on the critical path (they are incidents on a timer) and anything that generates recurring support tickets (each ticket is the platform failing at self-service, twice — once for the user, once for the engineer answering it).
Adoption is the deliverable
The platform trap I see most often: a capability ships, the roadmap item closes, and six months later three teams use it while nine still do the old thing. By any product standard that feature failed — but platform roadmaps rarely say so, because "shipped" was the definition of done.
I define platform done differently: a capability is done when the second team uses it without talking to the platform team. That definition forces the unglamorous work that actually drives adoption:
- A template or module that makes the right way the shortest way.
- Documentation written against a real use case, tested on someone who did not build the thing.
- One production service migrated by the platform team itself — the reference implementation and the empathy check in one move.
- An explicit migration window with help, not a deprecation email with a deadline.
Measuring flow honestly
The platform's outcome metrics are delivery metrics: lead time for changes, deployment frequency, change failure rate, time to restore. If the platform is working, those move for product teams — measuring the platform team's own velocity mostly measures how busy it is, which is not the same thing as useful.
Alongside the DORA-style outcomes I track two platform-specific signals. Adoption curves per capability — flat curves are the earliest honest feedback that something about the capability is wrong, long before anyone files a complaint. And support-ticket taxonomy — the distribution of what people ask for help with is a ranked list of where self-service is failing, updated continuously and free of survey bias.
How platform roadmaps fail
- The ivory tower rebuild. Eighteen months of building the perfect platform v2 while product teams live with v1's problems. By the time v2 lands, its assumptions are stale and its users are hostile. Ship capability by capability into the existing flow instead.
- Mandate without merit. Forcing adoption through policy before the capability is actually better than what teams do today. Compliance happens; trust does not; the next capability launches into a headwind.
- The resume-driven roadmap. Technology choices driven by what the platform team wants to learn. Sometimes aligned with user needs, but only by coincidence — the capability map exposes this quickly, which is another argument for the map.
- Everything for everyone. A platform that accepts every request converges on a second, worse version of each team's bespoke setup. A healthy roadmap says "no" or "later" visibly and with reasons.
Summary
- Write every roadmap entry in terms of the product friction it removes — that phrasing is also the test.
- Treat product engineers as users with alternatives; adoption is voluntary in practice.
- Map work into capabilities with a user, a promise, and a current-state line — the gap is the roadmap.
- Sequence by flow arithmetic: breadth times frequency times friction removed, with manual risk and ticket generators jumping the queue.
- Done means the second team adopted it unassisted — templates, tested docs, and a migrated reference service are the real work.
- Measure product teams' delivery metrics and adoption curves, not platform-team busyness.