Quick Navigation
- Start here — the kitchen that cooks what it wants
- Three structural failures behind low adoption
- The gate before build — demand
- The gate during build — scope
- The gate after release — adoption
- Shadow platforms are a receipt, not a crime
- Running it — 45 to 90 days
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Most platform teams are measured on what they have built. Releases shipped, capabilities delivered, uptime held. Every one of those numbers can rise while the platform's actual usefulness falls.
A platform is not technology. It is a product, and your developers are the customers. If they do not choose to use it, you do not have a platform — you have a museum.
That single reframe moves platform engineering out of the infrastructure category and into the product category. And products are governed by demand, not by ambition.
Keep it in mind.
1. Start here — the kitchen that cooks what it wants
A restaurant opens in a working-class neighbourhood. The chef trained in Paris and can execute techniques most kitchens have never attempted, so they design a menu that would earn a Michelin star: sous-vide duck confit, truffle foam, deconstructed tarte tatin. The neighbourhood eats curry, biryani and fried rice. The chef never asks what the neighbourhood wants — they cook what they believe is excellent, plate it beautifully, and wait. The neighbourhood arrives, reads the menu, cannot find what they want, and leaves.
The chef calls it a marketing problem. It is not. It is a governance problem: no mechanism existed to validate demand before the dish was cooked.
Now look at how most platform organisations decide what to build. A platform team forms, studies the engineering organisation, and identifies the common patterns — deployment friction, environment inconsistency, observability gaps. They build a CI/CD pipeline, a service catalogue, an internal developer portal, and launch with high expectations. Six months later adoption is below forty percent. Engineering teams are using their own deployment scripts, their own monitoring dashboards, their own secret management tools. The platform is technically sound. It is simply not being used.
The platform team calls it an adoption problem. It is not. It is a governance problem: the platform was built without demand validation, without product governance, and without any mechanism to retire what nobody uses.
A platform does not fail because it was built badly. It fails because nobody governed who asked for it.
Try it yourself — The three questions
Answer these about your own platform before reading on.
| Question | Your answer |
|---|---|
| For every feature on your current roadmap, can you name the team that explicitly requested it — not "would benefit," but requested? | |
| When was the last time a platform feature was removed because it was not being adopted? | |
| How many shadow platforms exist in your organisation right now? Not "probably some" — a number. |
If the answers require investigation rather than a dashboard, your platform is being built without product governance.
2. Three structural failures behind low adoption
Low adoption is rarely one bad decision. It is three structural conditions producing the same outcome: a platform that is technically excellent and practically unused.
Built without a buyer. A feature is proposed in the backlog, discussed in sprint planning, approved, built, tested and released. Nobody asked which engineering team specifically requested it, who committed to using it within thirty days, or what happens if no team adopts it. The build decision has been separated from the consumption decision — the platform team controls what gets built, the engineering teams decide what gets used, and the gap between those two governance structures is where platform investment goes to die.
Measured by output, not outcome. The quarterly report says five new capabilities delivered, uptime at 99.9%, a hundred tickets resolved, three integrations completed. Every one of those metrics describes what the platform team produced; none describe whether anyone used it. Meanwhile one team has built its own deployment pipeline because the platform pipeline does not support their stack, another its own secret management because the platform version is too slow, a third its own dashboard because the platform one does not surface the signals they need. None of that appears in the platform report. Leadership sees the platform budget and the shadow platform budgets as separate line items. They are the same problem expressed twice.
Governed as infrastructure, not as product. Platform decisions pass through cost, security, compliance and architecture review. Those gates ensure the platform is safe, compliant and well architected. They do not ensure anyone will use it. There is no user research gate asking which teams need this and what problem they are solving, no adoption target naming what share of eligible teams must adopt within what window, and no retirement criteria stating what happens if they do not.
The platform is governed like a bridge — built to specification, inspected for safety, assumed to be useful.
But a bridge has captive users. A platform has customers. And customers choose.
3. The gate before build — demand
The fix is not a better menu. It is a governance model that ensures nothing gets cooked until someone has ordered it.
The Platform Product Governance Model (PPGM) treats platform delivery as a product lifecycle rather than an infrastructure programme, in three layers. Its purpose is precise: ensure that every platform feature has validated demand, a clear scope boundary, and an adoption outcome — before build starts, during delivery, and after release.
flowchart TB
A["🏗️ Platform Product\nGovernance Model"]
A --> B["Layer 1: Demand\nBefore build"]
A --> C["Layer 2: Build\nDuring delivery"]
A --> D["Layer 3: Adoption\nAfter release"]
B --> B1["Who asked for this?\nWhat problem does it solve?\nWho commits to adopt?"]
C --> C1["Platform or application?\nDoes it already exist?\nWhat is the migration path?"]
D --> D1["What is the target?\nAdopting or working around?\nWhat retires it?"]
The first gate sits before development starts, and asks three questions.
Which engineering team explicitly requested this capability? Not "could benefit from it." Not "we anticipate they will need it." A named team that has stated, in writing, that this capability would solve a specific problem they face today.
What specific problem are they solving that cannot be solved without a platform change? The problem must exist now, it must be concrete, and it must be measurable in the time or cost currently being consumed.
Which teams commit to adopting within thirty days of delivery? Commitment is not interest. It is a named team agreeing to migrate inside a defined window. Without commitment there is no demand — only curiosity.
A feature that cannot clear all three does not enter the build queue. It is not postponed. It does not go on a "future consideration" list. It is not built.
The failure mode this gate prevents is the orphan feature — a backlog item with no identified consumer, no committed adopter and no validated problem, existing because someone on the platform team believed it would be useful. The chain is always the same: an engineer observes a pattern across teams, generalises it into a capability, adds it to the backlog, and nobody challenges the assumption because the team is oriented toward building rather than validating. It ships. Nobody adopts. The cycle repeats.
That is not a planning failure. It is a demand failure — no mechanism existed to distinguish "this would be useful" from "a team has committed to using this."
Try it yourself — The demand audit
Take the six items nearest the top of your platform backlog.
| Feature | Named requesting team | Problem it solves today | Team committed to adopt in 30 days |
|---|---|---|---|
Any row with a blank in it is unvalidated. Count them, then say the number out loud as a percentage of the backlog: this is the share of our roadmap that nobody asked for.
4. The gate during build — scope, and the charter that holds it
Once demand is validated, three more questions govern the build itself.
Is this truly a platform capability, or an application concern being pushed into the platform? Platform capabilities serve multiple teams; application concerns serve one. When application logic enters the platform, it accretes complexity that one team needs and every other team pays for.
Does this capability already exist — in another platform service, another team's stack, or a shadow platform? Duplication inside the platform is visible; duplication outside it is invisible until it is too late.
What is the migration path and rollback plan? Consuming teams need to know how to adopt, how long it takes, and what happens if it does not work for their context. A platform feature without a migration plan is a platform feature that will not be adopted.
The failure mode this gate prevents is platform accretion — the gradual absorption of application concerns into the platform layer, driven by convenience rather than governance. A team needs something the platform does not provide. Raising it as a platform request is slow; pushing it in directly is faster. The platform team accepts the contribution because it fills a gap and it is the path of least resistance. One team's application concern becomes every team's platform complexity.
That is not a design failure. It is a boundary failure — the platform had no mechanism to say: this belongs in application space; build it in your team, and we will extract it when a second team needs it.
Which is what the platform charter is for. A charter that lists what the platform provides is only half written. The half that does the work names what the platform does not own, because that is the sentence the accretion request runs into. Write the scope boundary as two columns, classify every existing capability against it, and attach a sunset plan to everything on the wrong side.
The charter has a second job, covered in Cognitive Load & Team Interfaces: keeping the platform team itself from absorbing every unclaimed responsibility in the organisation. One document does both jobs. Write it once, use it in both conversations.
5. The gate after release — adoption is the measure
Delivery is not the end of governance. It is the beginning of it.
What is the measurable adoption target? A specific share of eligible teams adopting within a specific window — for example, sixty percent of teams running Kubernetes migrated to the platform pipeline within ninety days. A capability without a target cannot fail, which means it can never be corrected.
Are users adopting, or working around? Adoption metrics measure usage; working around is invisible. When teams are not using a capability, the question is not "how do we push harder." It is "what is wrong with this that makes teams prefer their alternative?"
What is the retirement criteria? If adoption stays below target after the grace period, the feature is redesigned or removed. Low-adoption features are not allowed to persist — they consume maintenance cost, documentation effort, compatibility constraints and governance attention whether or not anyone uses them.
The failure mode this gate prevents is the feature graveyard — shipped capabilities that were never adopted and never retired. A feature ships. Teams evaluate it, find it does not fit, and build their own alternative. The platform team measures output rather than adoption, so nothing registers. New engineers join, discover the feature, also find it does not fit, and build yet another alternative. The feature persists because nobody owns the retirement decision, and the platform's active surface area grows outward while its useful surface area stays flat. Newcomers cannot tell the living features from the dead ones.
This is also where golden paths are judged. A golden path — the standardised, secure, observable route through creating a service, shipping to production, adding an integration — earns the name only when it is genuinely the path of least resistance. The moment the paved road is slower than the dirt road, developers take the dirt road, and every standard the platform encoded leaves with them. Adoption is not a measure of developer compliance. It is a measure of whether the golden path won on merit.
Report platform success by adoption rate, not by feature count. A platform that ships fewer things and has all of them used is winning.
6. Shadow platforms are a receipt, not a crime
When these gates are absent, engineering teams do not complain. They adapt.
A team needs a deployment pipeline that supports their stack; the platform pipeline supports a different one. They do not raise a formal request, because they know the backlog is full. They build their own — two weeks, works perfectly for their context, never mentioned. A second team hits the same gap, finds the first team's pipeline does not fit either, and builds a third. Six months later the organisation has five deployment pipelines, three secret stores, four monitoring dashboards and two service catalogues, none of which talk to each other, each maintained by a team that considers it a necessary workaround.
Leadership discovers this in an audit, and the reaction is predictable: shadow IT, ungoverned spend, security risk. The reaction should be different: we built a platform that did not fit, and our teams responded rationally.
Every shadow platform is a receipt for an unmet need. Mapped properly, the shadow landscape is the most honest demand backlog a platform team will ever get — each hidden tool traces to a specific gap, and the gap is the feature request nobody filed.
flowchart TD
GAP["🕳️ Platform does not fit\na team's context"] --> SLOW["Formal request is slow\nBacklog is full"]
SLOW --> BUILD["Team builds its own\ntool in two weeks"]
BUILD --> HIDDEN["🔍 Never surfaced\nNever reported"]
HIDDEN --> AUDIT["Discovered in an audit\nas 'shadow IT'"]
AUDIT --> READ["Read as evidence:\neach tool names\nan unmet need"]
READ --> GATE["📋 Validated demand\nfor the next capability"]
7. Running it — 45 to 90 days
Weeks 1–3, the demand audit. Put every backlog item — in progress, planned and under consideration — through the three demand questions. Mark everything that cannot answer all three as unvalidated, and present the result as a single number: this is the share of our roadmap that nobody asked for. Do not fix anything yet; the goal is visibility.
Weeks 4–6, the build boundary. Define what is in scope and out of scope, classify every existing capability against that boundary, and give the ones that fall outside a sunset plan with migration support. Attach the build governance questions to the delivery workflow so nothing reaches development without passing them.
Weeks 7–12, the adoption cadence. Set a target for every active capability and build a dashboard showing which are used, by which teams, at what rate. For anything below target, investigate with one question: is this a fit problem, a migration friction problem, or a visibility problem? Then establish a quarterly platform health review with consuming team representatives in the room.
The success test for the whole programme is a meeting agenda: platform leadership reviews adoption metrics alongside delivery metrics, in the same session, at the same level of seriousness.
Consider what that surfaces. In one Series B company, five engineering teams shared a single platform team, and each had built its own deployment pipeline because the platform pipeline did not support their stack. The platform team measured uptime and features delivered, unaware that sixty percent of engineering teams were operating outside the platform. The shadow landscape was mapped, every hidden tool traced to an unmet need, a scope boundary defined, and adoption targets set per capability. Within one quarter four pipelines consolidated into one and adoption rose from under forty percent to over eighty — with fewer features shipped, and every one of them used.
Putting it all together
flowchart TD
REQ["💬 A capability\nis proposed"] --> G1{"Named team?\nReal problem?\nCommitted adopter?"}
G1 -->|"no"| STOP["❌ Not built\nNot postponed"]
G1 -->|"yes"| G2{"In the platform's\nscope boundary?\nMigration path?"}
G2 -->|"no"| APP["↩️ Application space\nExtract at the\nsecond consumer"]
G2 -->|"yes"| SHIP["🚀 Build and release"]
SHIP --> G3{"Adoption target\nmet after the\ngrace period?"}
G3 -->|"yes"| KEEP["✅ Keep and invest"]
G3 -->|"no"| FIX["🔁 Redesign or retire\nNot 'push harder'"]
The foundation:
A platform is a product with customers who can decline. Low adoption is not a marketing problem or a discipline problem — it is the visible result of three separated decisions: who decides to build, who decides to use, and nobody deciding to retire. Demand governance stops orphan features before they are built. Build governance holds a scope boundary against accretion, and the charter naming what the platform does not own is what does the holding. Adoption governance measures whether the golden path actually beat the dirt road, and retires what did not. Shadow platforms are the demand backlog nobody filed. And the reporting line changes from feature count to adoption rate.
Cheat Sheet — All the key terms
| Term | What it names | The signal to watch |
|---|---|---|
| Platform as product | Developers are customers who can choose not to buy | Adoption rate, not release count |
| Built without a buyer | Build decision separated from consumption decision | Features shipping with no committed consumer |
| Output over outcome | Reporting what was produced, not what was used | A green platform dashboard beside five shadow pipelines |
| Governed as infrastructure | Safety gates present, product gates absent | Compliant, well architected, unused |
| Demand governance | The gate before build: who asked, what problem, who commits | Backlog items that can name all three |
| Orphan feature | A backlog item with no consumer, adopter or validated problem | "This would be useful" said in planning |
| Build governance | The gate during build: scope, duplication, migration path | Requests redirected to application space |
| Platform accretion | Application concerns absorbed for convenience | One team's need becomes everyone's complexity |
| Scope boundary | The half of the charter naming what the platform does not own | The sentence an accretion request runs into |
| Adoption governance | The gate after release: target, usage, retirement | Capabilities removed for low adoption |
| Feature graveyard | Shipped, never adopted, never retired | Newcomers cannot tell live features from dead ones |
| Golden path | The standardised route through a common task | It must beat the dirt road or it is unused |
| Shadow platform | A team-built alternative to an unfitting platform | A receipt for a specific unmet need |
How to know if this landed
You will know this has landed when someone stops asking "why aren't teams using the platform?" and starts asking "what do teams actually need?" When a feature proposal is met with "which team committed to adopt it?" and the meeting stops if there is no answer. When adoption is reported alongside uptime and a fall in it is treated as an incident. And when a discovered shadow tool produces a demand investigation rather than a compliance memo.
What changes when the mental model clicks
Platform teams range from startups with no platform at all to enterprises with platforms nobody uses. The gap at the start is rarely engineering quality — it is that developers were never treated as customers, and that no mechanism existed to tell a validated request apart from an internal opinion.
What changes is the direction of the roadmap. It stops being assembled from what the platform team believes is needed and starts being assembled from what named teams have committed to use. Backlogs get shorter. Surface area shrinks for the first time. And "developer resistance" stops being the diagnosis when the real problem was that nobody made the right way the easy way.
Where this comes from
This module develops the argument in Your Platform Team Is Building a Product Nobody Asked For, and runs alongside the Platform Engineering & DevEx Strategy Workshop.
The conditions that decide whether a golden path is actually faster than the dirt road are the subject of Developer Experience as a Control System.
Book a Workshop
Ready to find out how much of your platform roadmap nobody asked for?
or
1-day intensive workshop includes a platform backlog demand audit, scope boundary definition, shadow platform mapping, golden path review, and an adoption dashboard with per-capability targets.