The Kitchen That Cooks What It Wants
A restaurant opens in a working-class neighbourhood.
The chef trained in Paris. They studied under a three-star mentor. They can execute techniques most kitchens have never attempted.
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 does not ask what the neighbourhood wants. They cook what they believe is excellent. They plate it beautifully. They wait.
The neighbourhood arrives. They look at the menu. They cannot find what they want. They leave.
The chef calls it a marketing problem.
It is not a marketing problem.
It is a governance problem: no mechanism existed to validate demand before the dish was cooked.
Now consider how most platform organisations decide what to build.
A platform team forms. They study the engineering organisation. They identify common patterns: deployment friction, environment inconsistency, observability gaps.
They build a CI/CD pipeline. A service catalogue. An internal developer portal.
They 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 an adoption problem.
It is a governance problem: the platform was built without demand validation, without product governance, and without a mechanism to retire what nobody uses.
Why Platform Investments Fail to Move Adoption
Three structural failures produce the same outcome: a platform that is technically excellent and practically unused.
1. Built Without Buyer
A feature is proposed in the platform backlog.
The platform team discusses it in sprint planning. The architect approves the design. The feature is built, tested, and released.
Nobody asked: which engineering team specifically requested this? Who committed to using it within thirty days of release? What happens if no team adopts it?
The build decision is separated from the consumption decision.
The platform team controls what gets built. The engineering teams decide what gets used. These two decisions operate in different governance structures — and the gap between them is where platform investment goes to die.
The result: Features enter production with zero committed consumers. The platform team measures output (releases, features shipped) while engineering teams silently choose not to participate.
2. Measured by Output, Not Outcome
The platform team reports to leadership:
- Five new capabilities delivered this quarter
- Platform uptime at 99.9%
- One hundred tickets resolved
- Three new integrations completed
Every metric is about what the platform team produced.
None of them measure whether engineering teams are actually using what was produced.
Meanwhile, in the engineering organisation, something else is happening. Team A built its own deployment pipeline because the platform pipeline does not support their tech stack. Team B built its own secret management tool because the platform version is too slow. Team C built its own monitoring dashboard because the platform one does not surface the signals they need.
None of these appear in the platform report.
They do not appear anywhere — until someone maps the full landscape and discovers that the organisation is maintaining five deployment pipelines, three secret stores, and four monitoring solutions, all of which were built because the platform did not fit.
The result: Leadership sees the platform budget and the shadow platform budgets as separate line items. They are the same problem expressed twice.
3. Governed as Infrastructure, Not as Product
Platform decisions pass through infrastructure governance:
- Cost review
- Security review
- Compliance review
- Architecture review
These gates ensure the platform is safe, compliant, and well-architected.
They do not ensure anyone will use it.
There is no product governance gate:
- User research: which teams need this, and what specific problem are they solving?
- Adoption target: what percentage of eligible teams must adopt within what timeframe?
- Retirement criteria: if adoption falls below target, is the feature redesigned or removed?
The platform is governed like a bridge: built to specification, inspected for safety, assumed to be useful.
But a platform is not a bridge.
A bridge has captive users. A platform has customers. And customers choose.
The result: The platform is compliant and unused. Every release makes it safer and more expensive — and no more adopted.
Platform Product Governance Model (PPGM)
Platform Product Governance Model (PPGM) is a three-layer governance model that treats platform delivery as a product lifecycle — not an infrastructure programme.
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.
%% caption: PPGM: the questions each governance layer asks before a platform feature is built and adopted
flowchart TB
A["Platform Product Governance Model (PPGM)"]
A --> B["Layer 1: Demand Governance"]
A --> C["Layer 2: Build Governance"]
A --> D["Layer 3: Adoption Governance"]
B --> B1["Who asked for this?"]
B --> B2["What problem does it solve?"]
B --> B3["Which teams committed to adopt?"]
C --> C1["Is this platform or application?"]
C --> C2["Does it duplicate existing capability?"]
C --> C3["What is the migration path?"]
D --> D1["What is the adoption target?"]
D --> D2["Are users adopting or working around?"]
D --> D3["What is the retirement criteria?"]
Layer 1: Demand Governance
The gate before build.
Before any platform feature enters development, three questions must be answered:
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 currently face.What specific problem are they solving that cannot be solved without a platform change?
The problem must exist today. It must be concrete. It must be measurable in 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 that agrees to migrate within a defined window. Without commitment, there is no demand — only curiosity.
If a feature cannot clear these three questions, it does not enter the build queue.
It is not postponed. It does not get added to a "future consideration" list. It is not built.
Named failure mode — Orphan Features. These are backlog items that have no identified consumer, no committed adopter, and no validated problem. They exist because someone on the platform team believed they would be useful. That belief is not demand. It is speculation.
The causal chain: a platform team member observes a pattern across engineering teams. They generalise it into a platform capability. They add it to the backlog. Nobody challenges the assumption because the team is oriented toward building, not validating. The feature is built. It ships. Nobody adopts it. The team moves to the next feature, and the cycle repeats.
This is not a planning failure. It is a demand failure. The platform had no mechanism to distinguish between "this would be useful" and "a team has committed to using this."
Without that mechanism, the backlog fills with orphan features. The platform team builds in a vacuum. And every sprint delivers capabilities that have exactly zero waiting consumers.
When absent: Features are proposed based on what the platform team believes is needed. Roadmaps are built on assumption. The backlog fills with orphan features. The platform team ships and hopes.
When present: Every feature has a named consumer team. Adoption is committed before build starts. The platform backlog reflects validated demand, not internal opinion.
Layer 2: Build Governance
The gate during build.
Once demand is validated, three additional questions govern the build itself:
Is this truly a platform capability — or is it an application concern being pushed into the platform?
Platform capabilities serve multiple teams. Application concerns serve one team. When application logic enters the platform, the platform accretes complexity that only one team needs — and every other team pays for in cognitive load.Does this capability already exist — in another platform service, another team's stack, or a shadow platform?
Duplication in the platform is visible. Duplication outside the platform is invisible until it is too late. Build governance must scan for existing solutions before approving new ones.What is the migration path and rollback plan?
Consuming teams need to know how to adopt, how long it will take, and what happens if the feature does not work for their context. A platform feature without a migration plan is a platform feature that will not be adopted.
Named failure mode — Platform Accretion. This is the gradual absorption of application concerns into the platform layer, driven by convenience rather than governance. It follows a precise causal chain:
A team needs a capability the platform does not provide. Raising it as a platform request is slow. Pushing it into the platform directly is faster. The platform team accepts the contribution because it fills a gap and the path of least resistance. One team's application concern becomes every team's platform complexity.
This is not a design failure. It is a boundary failure. The platform had no mechanism to say: "this capability belongs in application space, not platform space — build it in your team, and we will extract it when a second team needs it."
Without that mechanism, every platform becomes a graveyard of one-team capabilities. The platform does not grow. It accretes.
When absent: Platform Accretion runs unchecked. The platform becomes a monolith of generic functionality that serves nobody well. Teams hide application logic in platform services because no boundary exists. The cognitive load of using the platform increases with every release.
When present: The platform has a defined scope boundary. Capabilities outside that boundary are rejected at build governance. Every new feature includes a migration plan and a deprecation policy. The platform surface area is actively managed. Accretion is replaced by intention.
Layer 3: Adoption Governance
The gate after release.
Delivery is not the end of governance. It is the beginning.
Three questions govern the post-release phase:
What is the measurable adoption target?
A specific percentage of eligible teams that must adopt within a specific timeframe. Example: 60% of teams using Kubernetes must migrate to the platform pipeline within ninety days.Are users adopting — or are they working around?
Adoption metrics measure usage. Working around is invisible. If teams are not using the platform capability, the question is not "how do we push harder" — it is "what is wrong with the feature that makes teams prefer their alternative?"What is the retirement criteria?
If adoption falls below target after the grace period, the feature is either redesigned or removed. Features are not allowed to persist indefinitely at low adoption. They consume maintenance cost, cognitive load, and governance attention.
Named failure mode — The Feature Graveyard. This is the accumulation of shipped capabilities that were never adopted and never retired. The causal chain:
A feature ships. Teams evaluate it. It does not fit their context. They build their own alternative. The platform team does not measure adoption — they measure output. The feature sits in the platform, consuming documentation effort, migration compatibility constraints, and cognitive load. New engineers join. They discover the feature exists. They evaluate it. They also find it does not fit. They build yet another alternative. The feature persists because nobody owns the retirement decision.
This is not a build failure. It is a retirement failure. The platform had no mechanism to say: "this capability was shipped, it was not adopted, and it is now costing more to keep than to remove."
Without that mechanism, every platform becomes a museum of unvalidated experiments. The surface area grows in one direction — outward — while the useful surface area stays flat or shrinks. Newcomers cannot distinguish the living features from the dead ones.
When absent: Features accumulate like technical debt. Nobody removes unused platform capabilities. The platform becomes harder to use with every release because the active surface area grows while the useful surface area stays flat. The Feature Graveyard expands.
When present: Features that fail adoption targets are either redesigned or removed. The platform surface area is actively governed. New capabilities replace old ones. The platform gets easier to use over time, not harder. The graveyard is cleared.
The PPGM Decision Matrix
| Gate | Question | When Absent | When Present |
|---|---|---|---|
| Demand Governance | Who asked for this? | Features built on assumption. Backlog has orphan items. | Every feature has a named consumer team with committed adoption. |
| Build Governance | Is this platform or application? | Platform accretes generic capabilities. Boundaries are undefined. | Platform scope is defined. Feature requests outside scope are redirected. |
| Adoption Governance | Are users adopting or working around? | Features accumulate forever. Nobody tracks usage. | Unused features are retired. Adoption metrics drive investment. |
How Shadow Platforms Emerge
When PPGM is absent, engineering teams do not complain.
They adapt.
A team needs a deployment pipeline that supports their specific stack. The platform pipeline supports a different stack. The team does not raise a formal request — they know the platform backlog is full. They build their own pipeline. It takes two weeks. It works perfectly for their context. They never mention it.
A second team faces the same gap. They evaluate the first team's pipeline. It does not fit their context either. They build their own. Now there are three pipelines.
Six months later, the organisation has five deployment pipelines, three secret stores, four monitoring dashboards, and two service catalogues. None of them talk to each other. Each is maintained by a team that considers it a necessary workaround.
Leadership discovers this during an audit. 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.
Shadow platforms are not a symptom of undisciplined engineering teams.
They are a symptom of absent platform governance.
Implementation Guide (45–90 Days)
Phase 1: Demand Audit (Weeks 1–3)
Objective: Identify every feature in the platform pipeline that lacks validated demand.
Activities:
- Audit every feature in the current platform backlog — in progress, planned, and under consideration
- For each feature, attempt to answer the three Demand Governance questions: named consumer team, specific problem, committed adoption
- Features that cannot answer all three questions are marked as unvalidated
- Present the audit to platform leadership: this is the percentage of our backlog that nobody asked for
Do not fix anything yet. The goal is visibility.
Deliverable: Validated vs unvalidated backlog report
Success Metric: Every active feature item either has a named consumer team with committed adoption — or is flagged as unvalidated
Phase 2: Build Boundary (Weeks 4–6)
Objective: Define what belongs in the platform and what does not.
Activities:
- Define the platform scope boundary: what capabilities are in-scope and what capabilities are out-of-scope
- Classify every existing platform capability against the boundary
- For out-of-scope capabilities, create a sunset plan with migration support for consuming teams
- For in-scope capabilities, attach the Build Governance questions to the delivery workflow
Deliverable: Platform scope document with capability classification and sunset plan
Success Metric: Every feature request now passes through Build Governance before development begins
Phase 3: Adoption Cadence (Weeks 7–12)
Objective: Embed adoption measurement into the platform delivery lifecycle.
Activities:
- Establish adoption targets for every active platform capability
- Build a simple adoption dashboard: which capabilities are being used, by which teams, and at what rate
- For capabilities below adoption target, initiate a root-cause investigation: is it a fit problem, a migration friction problem, or a visibility problem?
- Establish a quarterly platform health review with consuming team representatives
Deliverable: Adoption dashboard with per-capability targets and a quarterly review cadence
Success Metric: Platform leadership reviews adoption metrics alongside delivery metrics in the same meeting
Evidence from Practice
A Series B company I worked with had five engineering teams sharing a single platform team. Each team had built its own deployment pipeline because the platform pipeline didn't support their stack. The platform team measured uptime and feature delivery — they had no idea that sixty percent of engineering teams were operating outside the platform.
We mapped the shadow platform landscape, classified every hidden pipeline and tool, and traced each to an unmet platform need. Then we defined a platform scope boundary and established adoption targets per capability. Within one quarter, the platform consolidated four deployment pipelines into one. Adoption went from under forty percent to over eighty percent. The platform team shipped fewer features — and every feature was used.
Action Plan
This Week
Ask three questions about your platform:
For every feature on your current roadmap, can you name the engineering teams 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? If the answer is never, your platform is accumulating dead weight.
Do you know 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.
Next 30 Days
- Run a Demand Audit on your current platform backlog
- Suspend every feature that does not have a named consumer team with committed adoption
- Define the Platform Scope Boundary
- Identify shadow platforms and trace their root cause to a platform gap
3–6 Months
- Implement all three PPGM gates into the platform delivery lifecycle
- Build an adoption dashboard with measurable targets per capability
- Establish a quarterly Platform Health Review with consuming team representatives
- Begin retiring platform capabilities that fail adoption targets
- Report platform success by adoption rate, not feature count
Final Thought
The kitchen that cooks what it wants goes out of business.
Not because the food is bad.
Because nobody ordered it.
Your platform team is the kitchen. Your engineering teams are the diners.
And right now, most platform organisations are serving dishes nobody ordered — then wondering why the tables are empty.
The fix is not a better menu.
It is a governance model that ensures nothing gets cooked until someone has ordered it.
Turn Your Platform From a Build Initiative Into a Product
If your platform team keeps building features that engineering teams work around…
if your platform backlog has features with no identified consumers…
or if shadow platforms are emerging because your platform does not fit —
then the problem is not the platform.
It is the governance model.
In a focused 30-minute Platform Product Governance Diagnostic, we will:
- Audit your current platform backlog for orphan features
- Identify shadow platforms in your organisation and trace their root cause
- Classify your platform delivery against the PPGM three-layer model
- Define a 45-day plan to move from build-and-hope to governed adoption
→ Book a Platform Product Governance Diagnostic
or
The best platform teams do not build what they think is needed.
They build what their users have chosen.
