Common Platform Roadmap¶
Document — instantiates Shared-Input Variety Platform Design
Sequences investments in common capabilities so multiple output teams can depend on a visible shared foundation.
A Common Platform Roadmap is a published, time-phased plan stating which shared capabilities will be built, hardened, or retired — in what order, and by roughly when — so the many output teams that draw on the shared layer can plan around a foundation they can see instead of lobbying for it in private. Its defining move is commitment over time: it is not a description of what the platform is today, but the sequence of shared investments the whole portfolio is invited to bet on. That forward promise is the thing that lets a downstream team decide, today, to stop building its own version of something the platform will offer next quarter.
Example¶
A regional transit agency runs bus, commuter-rail, and ferry services. Historically each service built its own fare collection, trip planning, and rider-notification software, and each keeps hedging because none can tell what the others — or the new central platform team — will actually deliver. The ferry team's fare system is failing, and without any visible commitment they quietly begin rebuilding their own rather than wait.
The platform team publishes a roadmap: shared account-based ticketing is committed for Q2, a shared real-time arrivals feed is planned for Q4, and the legacy rail notification stack is slated for retirement the following spring. The ferry team now schedules its own decommissioning against the Q2 date instead of starting a doomed rebuild; the rail team stops pouring money into a stack with a published expiry. Outcome: local plans co-schedule against visible shared milestones, and the platform team can defend its funding against a document rather than anecdote.
How it works¶
- Order by who is unblocked, not who is loudest. Each roadmap item is justified by the set of outputs it serves; the capability that unlocks the most (or the most critical) outputs is sequenced first.
- Phase by dependency and readiness. A capability lands only after the things it rests on, and only when it is mature enough to depend on.
- Make retirement a first-class item. Deprecation and cut-off dates appear on the roadmap alongside new build, so teams stop investing in stacks that are going away.
- Re-baseline on a cadence. A roadmap is versioned and openly re-issued; a stale one that quietly slips is worse than none, because teams that trusted a dead date revert to stovepipes.
Tuning parameters¶
- Horizon length — how far out the plan commits. A longer horizon lets teams plan deeper but stakes the platform's credibility on guesses about distant needs.
- Commitment firmness — tiering items as committed / planned / exploring. Firm near-term items give teams something to bet on; firm distant items become broken promises.
- Sequencing rule — by demand (unlock the most outputs first), by risk (kill the most dangerous duplication first), or by readiness. The choice changes which teams win.
- Granularity — capability-level versus feature-level entries. Finer detail helps consumers plan but ages faster.
- Re-baseline cadence — quarterly versus annual re-issue; more frequent keeps trust but costs planning overhead.
When it helps, and when it misleads¶
Its strength is converting private lobbying into public planning: when the sequence of shared investment is visible, output teams can co-schedule their own work against it, and the platform gains a legible object it can be funded and held to. It is also how a portfolio decides to stop paying for the same thing many times — the ferry team's rebuild only dies once the roadmap makes the alternative real.
Its failure mode is roadmap theater: a plan published to win a budget cycle, full of aspirational dates nobody resources, that slips silently until teams stop believing it — after which they revert to self-reliance, and the reversion is self-reinforcing. The classic misuse is inflating distant commitments to look ambitious while the near-term stays vague. The guarding discipline is to publish only what stewardship will actually fund, to use commitment tiers honestly, and to re-baseline in the open. Sequencing is most defensible when it tracks each capability's evolutionary maturity rather than sentiment — the logic behind Wardley mapping.[n1]
How it implements the components¶
common_capability_layer— names the shared capabilities that will exist and when, giving the layer a forward shape rather than only a present-tense description.portfolio_complementarity_map— each roadmap item is anchored to the set of outputs it serves, and that overlap map is what decides ordering.shared_layer_stewardship— the roadmap is the stewardship body's public instrument of reinvestment and deprecation authority; publishing and honoring it is stewardship acting in the open.
It does not price the layer (scope_benefit_metric, allocation_and_chargeback_rule — that is Cross-Output Cost Attribution Model) nor screen an individual output's fit (reuse_onboarding_path — Reuse Intake and Fit Assessment); a roadmap commits a sequence, it does not run the sums or the gatekeeping.
Related¶
- Instantiates: Shared-Input Variety Platform Design — the roadmap is the appraisal's forward calendar for the shared layer.
- Consumes: Platform Governance Board supplies the priorities and funding authority the roadmap encodes; Cross-Output Cost Attribution Model supplies the benefit evidence that orders it.
- Sibling mechanisms: Cross-Output Cost Attribution Model · Joint Procurement or Tooling Pool · Modular Capability Library · Platform Governance Board · Product-Line Architecture · Reuse Intake and Fit Assessment · Shared Data or Feature Store · Shared Service Catalog · Stovepipe Retirement Migration Plan
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Sequences investments in common capabilities so multiple output teams can depend on a visible shared foundation, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Common Platform Roadmap as 'Sequences investments in common capabilities so multiple output teams can depend on a visible shared foundation', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Product and portfolio management established time-phased roadmaps as published commitments that prioritize shared capabilities and milestones so dependent teams can sequence their own work and investments.
Related originating lineages:
- Computer Science & Software Engineering — Platform engineering supplies the shared technical capabilities, interfaces, lifecycle dependencies, and consuming development teams that the roadmap coordinates.
- Innovation & Entrepreneurship — Technology roadmapping contributes staged capability maturation, investment choices, and explicit build, buy, share, and retirement paths.
Review resolution: Microsoft's platform-roadmapping guidance explicitly develops actionable milestones, deliverables, phased implementation, prioritization, and stakeholder communication for platform evolution. Its capability model treats platform investment, adoption, governance, provisioning, interfaces, and feedback as shared organizational targets. This supports organizational management as primary, while software platform engineering and technology roadmapping remain materially formative.
Attribution caveat: The object being roadmapped is a software platform, but organizational product and portfolio management is primary because sequencing, commitment communication, and cross-team dependency planning are the defining operation.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- Microsoft Learn: Strategic Platform Road Mapping
- Microsoft Learn: Platform Engineering Capability Model
Notes¶
The roadmap is a communication artifact, not a decision engine. It publishes decisions the governance board has already made; keeping the two separate is what lets the board deliberate privately while the portfolio plans against a stable public promise.
[n1] Wardley mapping — Simon Wardley's technique for plotting capabilities by how evolved they are (genesis → custom-built → product → commodity) so a team can decide what to build, buy, or share, and in what order. It grounds roadmap sequencing in a capability's maturity rather than in who lobbies hardest. ↩