A platform roadmap should begin with the work consumers cannot complete reliably, not with the next shared technical component.
This week’s three reviews expose the same decision from different sides.
A migration becomes expensive when consumer teams must change code, tests, deployment logic, or operating procedures only because the platform changed its internal machinery.
Self-service also fails when nobody owns adoption, support, evolution, or the consumer promise. The portal can work while the platform becomes an unattended interface.
Both problems can produce feature requests. Neither is automatically solved by another feature.
Before approving the roadmap item, start with one observed friction. Record the delayed workflow, workaround, support handoff, unused capability, or coordinated change. Keep the observation separate from the proposed solution.
Then classify the gap.
1. Outcome
Can consumers state what they accomplish without naming the engine or interface?
2. Service expectations
Do they know what behavior, limits, recovery, health signals, and support they can rely on?
3. Ownership
Who owns adoption, support, evolution, and the tradeoffs inside the promise?
4. Evolution
Which implementation changes can happen without coordinated consumer work?
The CNCF Platforms White Paper treats self-service as one platform attribute and separately assigns user research, roadmap, feedback, and measurement responsibilities. DORA's 2024 research reports mixed platform outcomes and emphasizes developer independence rather than platform presence alone.
Those sources do not prescribe a roadmap. They support evaluating the platform through consumer work and operating consequences.
Compare the smallest credible remedies. The answer may be documentation, a support path, one accountable owner, contract versioning, a compatibility layer, a narrower promise, or a new component.
The component is justified when the capability is genuinely missing, several consumers need substantially the same outcome, the contract is clear enough to govern it, and someone can own it as a product.
Some decisions remain stuck because architecture, ownership, product value, and portfolio cost are discussed separately.
The Executive Decision Altitude Review is my new paid, fixed-scope diagnostic for one consequential data, platform, distributed-system, or AI capability decision. It is not presented as prior client delivery or a guaranteed result. Scope and fee are quoted after fit.
If one cross-team system decision has become expensive to change, review the engagement and bring that decision: