Platform Roadmapping Guide

Platform Planning Roadmapping Organizational Design

A quick-reference guide for platform and business portfolio teams as they plan together. Use it during continuous planning — especially within the T-6 and T-2 week timeframes — to ensure platform work and business portfolio work appear on roadmaps in a connected, visible, and accountable way.

This guide is a supplement to the Platform Evolution Playbook and the Continuous Planning Playbook. It assumes you’ve read both. It doesn’t replace your planning process. It provides patterns for how platform capabilities should appear on roadmaps and how to keep them aligned across portfolios.

The Core Principle: Connecting Roadmaps

Platform roadmaps and business portfolio roadmaps are separate, and they should stay that way. But they need explicit connection points. Without them, misalignment compounds and teams find out they’re blocked after it’s too late. (See: Connect Your Roadmaps in the Platform Evolution Playbook.)

Every pattern below answers the same question: what goes on which roadmap, and how do the two sides stay connected?

Outcome Types on Platform Roadmaps

Before getting to patterns, it helps to name the three kinds of outcomes that show up on platform and business portfolio roadmaps. Each pattern below uses these categories. Each has different characteristics, measurements, and audiences.

Internal User Behavioral Outcomes (UBOs)

These describe a change in what a user can do. For business portfolios, the user is typically an external customer or end-user.

But for platforms, users can be internal users — engineers, PMs, designers, ops roles — in other portfolios. The outcome is expressed as the user’s new capability, not the platform’s deliverable — outcomes over outputs, pointed inward.

Example. “Teams can provision a production-ready CI/CD pipeline in under an hour.”

Metrics. Adoption, time-to-first-success, consumer satisfaction, retention, and task completion rate.

Platform Capability Outcomes

These describe new or extended platform surface area — the APIs, data pipelines, event streams, graph endpoints, SDKs, CLI tools, templates, dashboards, documentation, and runbooks that are the platform’s goods and services for its consumers. They’re distinct from user behavioral outcomes because they describe what the platform makes available, not what consumers can do now. A given capability outcome usually enables downstream user behavioral outcomes; they’re complementary, not interchangeable.

Capability outcomes are especially relevant during Stage Two and Stage Three of platform evolution, when the platform is expanding the surface area that enables future self-service.

Example. “Notification Delivery API v1 published, with channel abstraction documentation, SDK support in Java and Go, and an on-call runbook for operational support.”

Metrics focus on the surface area itself and its fitness for consumption:

Surface area defined. Number of endpoints, events, graph types, or interfaces published and documented.
Interface stability. Frequency of breaking changes; percentage of API surface under a published versioning contract. These often appear as Service Level Agreements (SLAs) or Service Level Objectives (SLOs).
Adoption readiness. Consumer-facing SLOs published; support model declared; deprecation policy in place.
Usage metrics. How many uses of the new platform surface are there? These indicate how frequently and how much consumers are using platform primitives.
KTLO reduction. If a platform is creating new goods and services, this reduces “ticket storms” and manual labor by productizing repeat requests instead of handling each as a one-off.

When to use this outcome type. Platforms can model outcomes as either Internal User Behavioral Outcomes or Platform Capability Outcomes, depending on what’s being measured. Use an Internal UBO when the platform is accountable for a consumer behavior change (adoption, time-to-first-success, task completion). Use a Platform Capability Outcome when the platform is shipping surface area that consumers will wrap into their own user-facing outcomes.

When a business portfolio and a platform are collaborating on a user-facing change, the common shape is: the BP carries a UBO for the end-user change, and the platform carries a connected Platform Capability Outcome for the surface area that enables it. Different outcomes, linked by an explicit dependency and a shared timeline.

These are leading indicators. They tell you whether the surface area exists and is consumable. The lagging indicators — adoption, toil reduction, and unblocked consumers — appear alongside user behavioral outcomes and maturation outcomes.

Technical Outcomes

These describe technical work that consumers need to do: migrations, integrations, adoption work, or deprecation-driven changes. They appear on consumer roadmaps (business portfolios or other platforms), not on the producing platform’s roadmap. They’re typically furnished by the platform that requires the work, with wording, scope, and effort estimate prepared so consumers can drop them onto their own roadmaps without having to figure out what the work even is. (See Pattern 4’s Flavor A Phase 2 and Flavor B.)

Scope note. This section is about technical work that platform teams prepare and furnish for their consumers to execute, not a platform team’s internal technical improvements to its own services. Team-level technical outcomes (a team improving its own services) typically live on team roadmaps and don’t need to surface at portfolio or quarterly-review level. Large or cross-team technical work can surface on the portfolio roadmap so peer portfolios can see capacity allocation.

Example. “Migrate services to the container orchestration standard.”

Metrics. Completion against the deadline, adoption coverage across consumers, and remaining holdouts.

Pattern 1: Shared Outcome, Split Scope

Primary Quality: Clearly Defined Boundaries. Secondary: Governed Freedom.

A business portfolio and a platform are jointly pursuing a user-facing outcome — typically through a cross-portfolio virtual team or an embedded engineer arrangement.

How it works:

Both roadmaps carry the same outcome statement. The scope is different.

The business portfolio roadmap shows the outcome, with scope focused on their specific use cases — the user-facing behavior change, the product surface, and the integration into their experience.
The platform roadmap shows the same outcome, with scope focused on identifying the right boundary, building reusable primitives, and designing an interface that works for this consumer and the next.

Example: Checkout and Notifications share the outcome “Customers receive real-time order status updates across their preferred channels.” On the Checkout roadmap, the scope is the checkout UI changes that let customers select channel preferences and the Checkout-specific status update events. On the Notifications roadmap, the scope is the channel delivery API, the template rendering pipeline, and the contract that Marketplace or Subscriptions could consume next.

What to get right at T-6 / T-4:

Confirm the shared outcome statement is identical on both roadmaps.
Agree on the scope split — use the boundary map if you have one, or treat this as a forcing function to produce one. (See: Draw the Boundary Map.)
Name the virtual team or collaboration arrangement. (See: Form Cross-Portfolio Teams with a Mission and End Date.)
Agree on a hard end date for the collaboration. It goes on both roadmaps.

Pattern 2: Building to Consumer Demand

Primary Quality: Business Value. Secondary: Adoptability.

A platform identifies consumer demand and builds a capability to serve it. The demand signal can come from two places, and the roadmap mechanics follow the same shape — one pattern, two flavors.

How it works:

Demand shows up in one of two ways:

Flavor A — Internal demand (mined). The platform spots repeat patterns in tickets, support queues, intake boards, or onboarding friction before the need appears on any BP roadmap. The platform builds proactively. BP roadmaps may carry a dependency note or a “blocked by” flag, but no build item of their own. Once the capability ships, the BP picks up its own outcome to integrate and adopt it.
Flavor B — Consolidated demand (visible). The platform scans BP draft roadmaps at T-6 and spots the same build item appearing in two or more places. The platform absorbs the shared need and builds it once. Affected BPs drop their individual versions and replace them with a dependency on the platform capability plus their own integration scope (which stays on their roadmap).

In both flavors:

The platform roadmap shows a user outcome for internal consumers (or a connected Platform Capability Outcome) with the originating portfolios or demand sources named.
Business portfolio roadmaps carry a dependency and, for Flavor B, an integration scope.

Example (Flavor A — Internal demand): The DevEx platform, from ticket data mining, identifies that teams spend an average of 3 days setting up CI/CD for a new service. The platform roadmap states the outcome as “Teams can provision a production-ready CI/CD pipeline in under an hour.” No business portfolio carries this outcome, but Checkout and Marketplace both have items flagged as dependent on it.

Example (Flavor B — Consolidated demand): Checkout, Marketplace, and Subscriptions all have variants of “send order confirmation notifications” on their near-term roadmaps. Instead of three implementations, the Notifications platform picks up “Business portfolios can send customer-facing notifications through a single delivery integration.” Each business portfolio’s roadmap shifts to an integration outcome that depends on Notifications delivering the capability.

What to get right at T-6 / T-4:

Validate the demand signal. For Flavor A, mine your tickets and intake patterns and document the evidence. For Flavor B, scan BP roadmap drafts at T-6 for overlapping build items. (See: Don’t Build What Nobody Asked For; Scan Consumer Roadmaps for Shared Needs.)
Bring a back-of-the-envelope ROI: estimated hours saved, number of portfolios unblocked.
Make dependencies explicit. In Flavor A, BPs counting on the capability add a “blocked by” flag with a target date. In Flavor B, BPs drop the individual build item and pick up a dependency plus integration scope. Either way, it shows up on the BP roadmap.
Agree on sequencing — who’s the first consumer? The platform ships the smallest thing that satisfies that first consumer, then expands. (See: Ship the Smallest Thing That Satisfies the Need.)
Design the interface before building. Even if no one is co-building with you, sketch the API or workflow consumers will interact with. (See: Design the Interface Before the Solution.)
Every capability on the platform roadmap has names attached — real portfolios that asked for it, or specific internal demand signals documented.

Pattern 3: Platform Maturation

Primary Quality: Adoptability. Secondary: Governed Freedom.

The platform is investing in its own evolution, reducing toil, increasing self-service, and improving adoption, independent of any specific business portfolio feature request.

How it works:

These are outcomes the platform owns entirely. They don’t appear on business portfolio roadmaps, but they should be visible to consumers and reviewed in the portfolio review.

The platform roadmap shows maturation outcomes: reducing KTLO, increasing self-service coverage, improving time-to-onboard, or growing adoption of a specific capability.
Business portfolio roadmaps are unaffected, but business portfolios benefit indirectly — and the platform should be able to draw that line.

Example: Identity & Access identifies that 40% of intake tickets are manual access requests. The platform roadmap carries “Self-service access provisioning — eliminate manual access request tickets by the end of Q2.” No business portfolio carries this, but the metric (ticket volume reduction, self-service ratio) appears in the portfolio review.

What to get right at T-6 / T-4:

Justify these with data, not intuition. Use your ticket queue, intake board, and consumer feedback to gauge the problem’s size. (See: Mine & Delete Toilsome KTLO.)
Keep maturation outcomes to a reasonable share of the roadmap. If the entire roadmap is inward-facing and no business portfolio sees any direct value, something is off. (See also: Maturation Drift in the anti-patterns below.)
Make the metrics visible, and pick them so they can’t be gamed. (See: Using Metrics Responsibly.) These outcomes should be reviewed at the portfolio review alongside consumer-facing work.

Pattern 4: Adoption & Migration

Primary Quality: Adoptability. Secondary: Clearly Defined Boundaries.

Adoption and migration are two sides of the same shift: bringing consumers onto something new, or moving them off something old. They often chain — introducing a new standard eventually retires the old way, and deprecating an old capability typically forces adoption of a replacement. The roadmap treatment differs by flavor, but the core discipline is the same: the platform carries the support commitment, consumers carry the adoption or migration work, and timelines align.

Flavor A — Driving adoption of a new capability (pull to push)

A platform capability exists, and early adopters are using it, but the organization needs broad adoption to realize the full value. The capability needs to move from voluntary opt-in to an expected standard.

The underlying dynamic:

Platform adoption follows a curve. Early on, the right strategy is to pull — create something valuable and let business portfolios opt in. The platform earns adoption by making the capability easy, useful, and better than the alternative. Early adopters validate the capability, surface rough edges, and build the proof points that make the case for everyone else.

But pulling alone won’t get you to full adoption. At some point, a critical mass of early adopters has proven the capability, and the remaining teams either don’t see the urgency, have competing priorities, or are comfortable with what they already have. This is the gap between early adoption and broad adoption — what Geoffrey Moore calls “crossing the chasm.” Closing it requires a shift from pull to push: leadership air cover, a firm timeline, and a mandate.

How it shows up on roadmaps:

Phase 1 — Pull (early adoption): The platform roadmap carries the capability as an outcome. Business portfolio roadmaps that opt in carry their own adoption or integration outcomes voluntarily. The platform tracks adoption metrics — how many teams are consuming, how fast they onboard, and what friction they hit. This phase is about proving the value and refining the experience.
Phase 2 — Push (broad adoption): Once critical mass is reached and leadership decides to mandate, the platform furnishes a prepared technical outcome that remaining business portfolios place on their roadmaps. This is a technical outcome — not a user behavioral outcome — and it represents the work to migrate, integrate, or adopt the platform standard. The platform’s roadmap carries the corresponding support commitment: migration tooling, documentation, facilitation, and a deadline.

Example: The Infrastructure & Ops platform ships a new container orchestration standard. In Phase 1, the DevEx and Data platforms adopt voluntarily — they see the value, they’re early movers, and their adoption surfaces issues the Infra team fixes. After three portfolios are running on the new standard and the operational benefits are proven, leadership mandates adoption org-wide. Infra furnishes a prepared technical outcome — “Migrate services to the container orchestration standard” — with a migration guide and a target date. Remaining business portfolios place this outcome on their roadmaps. Infra’s roadmap carries the support side: “Migration support and tooling for the container orchestration standard — all portfolios onboarded by end of Q3.”

Flavor B — Deprecating an existing capability

The platform is replacing or sunsetting an existing capability. Business portfolios need time to migrate.

How it shows up on roadmaps:

Both sides carry roadmap items, but they’re different items with a shared timeline.

The platform roadmap shows the new capability (if applicable) and the deprecation plan, including the sunset date, migration support commitment, and cutoff.
Business portfolio roadmaps show migration work: the effort to move off the old capability and onto the new one, with a deadline that aligns with the platform’s cutoff.

Example: The Data platform is retiring a legacy query API in favor of a new self-service data access layer. The platform roadmap carries “Legacy Query API sunset — migration support through Q3, hard cutoff Q4.” Checkout and Marketplace each carry migration outcomes on their own roadmaps with target dates ahead of the Q4 cutoff.

When both flavors are in play at once

A new standard replacing an old one is common — apply Flavor A to the new side and Flavor B to the old side. The platform roadmap carries both the adoption-driving outcome for the new thing and the deprecation timeline for the old thing. BP roadmaps carry the migration work once, sized to the combined lift.

What to get right at T-6 / T-4:

For Flavor A Phase 1, don’t put adoption on anyone else’s roadmap. Let early adopters pull it in. The platform’s job is to make adoption easy and track who’s using it.
Track adoption metrics from day one, for both flavors. You’ll need them for Flavor A to make the case for the Phase 2 mandate, and for Flavor B to confirm consumers are migrating on schedule.
The shift from pull to push (Flavor A Phase 2) is a leadership decision, not a platform team decision. The platform brings the data; leadership provides the air cover.
For Flavor B (deprecation), announce early — ideally two planning cycles before the cutoff. BPs must acknowledge by putting migration work on their roadmap; if it’s not on the roadmap, it won’t get staffed. (See: Deprecation Patterns in Stage Four.)
In both flavors, the platform pairs the mandate or cutoff with real support on its own roadmap: migration tooling, documentation, facilitation time, deadlines. Mandate without support is forced adoption. (See: Forced Adoption in the Platform Evolution Playbook, and Technical Outcome Dumping in the anti-patterns below.)
Use the quarterly sync to review progress. For Flavor A: are you still in pull territory? Is it time to push? For Flavor B: are both sides tracking the same cutoff? Are holdout teams flagging legitimate blockers?

Pattern 5: Platform-to-Platform Dependencies

Primary Quality: Clearly Defined Boundaries. Secondary: Business Value.

One platform depends on another platform to ship. Because most platforms also have downstream business portfolio consumers, the dependency chain compounds: a business portfolio is waiting on Platform A, which is waiting on Platform B. When that chain isn’t visible, risk hides two links deep.

How it works:

Each platform’s roadmap carries its own outcome. They’re different outcomes with a shared timeline, and the consuming platform is treated as a first-class customer of the producing platform — with the same rigor as a business portfolio dependency.

Producing platform roadmap shows a platform capability outcome with the consuming platform named as its first (and sometimes only) consumer. Surface area, interface contract, and adoption readiness metrics apply.
The consuming platform roadmap shows its own platform capabilities or user behavioral outcomes, with an explicit dependency flag pointing upstream.
Downstream business portfolio roadmaps (if any) see the dependency as a second-order risk. The consuming platform carries the transparency burden: if your ability to deliver depends on another platform, that needs to be visible, not hidden behind a direct commitment to the BP.

Example: DevEx wants to ship a standardized, golden-path CI/CD template that deploys into a containerized runtime. That depends on Infra/Ops delivering container orchestration at a specific spec. Checkout and Marketplace are both waiting on the DevEx template.

Infra/Ops roadmap: “Container orchestration standard available for platform consumers” — DevEx named as first consumer, capability outcome with surface-area metrics (published API, runbook, SDK coverage, SLOs).
DevEx roadmap: “Standardized CI/CD pipeline template with containerized deploys” — explicit dependency flag on Infra/Ops with the target date.
Checkout and Marketplace roadmaps: “Migrate to standardized CI/CD pipeline” — dependency flag on DevEx, with a note that DevEx’s delivery depends on Infra/Ops (the second-order risk).

What to get right at T-6 / T-4:

Scan roadmaps from other platforms, not just BP roadmaps. Platform PMs should read each other’s draft roadmaps at T-6. Same discipline as Pattern 2 Flavor B, applied to platform peers.
Negotiate the dependency as a first-class customer. The consuming platform runs the same Cross-Portfolio Dependency Review checklist it would use as a BP consumer: what is needed, when, who owns delivery, how validated, what if it slips. Same rigor, same artifacts.
Make the chain visible downstream. If BPs depend on you and you depend on another platform, flag that explicitly. This isn’t pessimism; it’s an honest risk. The alternative — “platform telephone,” where BP consumers think they’re waiting on you but really the timeline risk lives two links deep — is worse.
Mind the Invisible Chain failure mode. Platform A commits to BPs without flagging its own upstream platform dependency. When Platform B slips, BPs are caught flat. Flagging the dependency upfront lets BPs plan contingencies.
Align on interface contracts early. Same as Pattern 1’s scope split: if you’re co-building, design the interface together. Document it. Both sides build against the contract.

Roadmapping Anti-Patterns

These are failure modes specific to how the platform works (or fails to work) on roadmaps. They complement the broader anti-patterns in the Platform Evolution Playbook; name them when you see them, and use the corresponding pattern to correct.

Phantom Outcome. A platform capability outcome appears on the platform roadmap with no named consumer. Variant: “We’ll need this eventually.” Why it’s dangerous: this is the Field-of-Dreams failure, expressed on a roadmap. It signals the platform is building on speculation, not demand. Fix: every platform capability outcome should have names attached — specific BP teams, specific other platforms, or a documented multi-consumer demand signal from ticket mining. (See: Don’t Build What Nobody Asked For.)

Roadmap Duplication. Two or more BP roadmaps include the same build item (e.g., three separate “send order confirmation” entries), and no platform has adopted the consolidated capability. Why it’s dangerous: guarantees three implementations, three integration patterns, and three bills. Fix: this is what Pattern 2 Flavor B exists to catch. Platform PMs scan BP draft roadmaps at T-6 specifically to prevent this.

Invisible Migration. A deprecation has been announced in a Slack message, email, or town hall, but it isn’t on any roadmap — not the platform’s, not the consumers’. Why it’s dangerous: migration work doesn’t get staffed. The cutoff arrives, and consumers are caught flat. Fix: Pattern 4 Flavor B requires the deprecation on the platform roadmap with a sunset timeline, and migration work on consumer roadmaps with deadlines ahead of the cutoff. No roadmap entry, no migration.

Orphan Dependency. A BP roadmap carries a “blocked by platform” notation with no corresponding item on the platform roadmap. Why it’s dangerous: the dependency exists in the consumer’s mind, but the platform doesn’t know it, isn’t committed to it, and isn’t staffing it. Fix: the Cross-Portfolio Dependency Review at T-2 should surface these. Related Frames link both sides; if only one side has the link, it’s not real.

Invisible Chain. Platform A commits to BPs without flagging its own upstream dependency on Platform B. Consumers are surprised when the capability slips because the real risk lived two links deep in the dependency chain. Why it’s dangerous: BPs can’t plan contingencies they don’t know about. Fix: Pattern 5 makes the chain explicit. Platform-to-platform dependencies show up on the consuming platform’s roadmap with the same rigor as BP-to-platform dependencies, and second-order risks are surfaced to downstream consumers.

Maturation Drift. The platform roadmap is dominated by maturation outcomes (self-service, KTLO reduction, internal refactors) with no visible line to business value or consumer demand. Why it’s dangerous: even if individual items are each justifiable, the aggregate signals a platform drifting inward. Leadership stops seeing value. Fix: Pattern 3 allows maturation outcomes at a reasonable share of the roadmap. Every maturation outcome should trace to consumer impact — time saved, tickets eliminated, onboarding accelerated — and that line should show up at the portfolio review.

Technical Outcome Dumping. A platform hands BPs a prepared technical outcome (Pattern 4 Flavor A Phase 2, or Pattern 4 Flavor B migration) without the paired support commitment on the platform’s own roadmap. Why it’s dangerous: this is Forced Adoption. BPs are mandated to adopt with no tooling, documentation, or facilitation. Fix: both flavors of Pattern 4 require the producing platform to carry matching support outcomes — migration tooling, documentation, facilitation time, deadlines. Mandate without support is hostile.

Platform Telephone. BP consumers believe they’re waiting on Platform A, but the actual delivery risk lives on Platform B, which Platform A depends on but hasn’t surfaced. A variant of Invisible Chain specifically about how information flows (or doesn’t) to downstream consumers. Fix: Pattern 5’s transparency burden — the consuming platform flags the upstream dependency explicitly to its own downstream consumers.

Platform Roadmapping: Quick Reference

Pattern	Primary Quality	What’s on the platform roadmap	What’s on the business portfolio roadmap	Key playbook practices
1 — Shared Outcome, Split Scope	Clearly Defined Boundaries	Same outcome, platform scope (primitives, boundaries, interfaces)	Same outcome, portfolio scope (use cases, user experience)	Draw the Boundary Map; Form Cross-Portfolio Teams
2 — Building to Consumer Demand	Business Value	Flavor A: user outcome for internal consumers. Flavor B: consolidated capability naming originating portfolios	Flavor A: dependency flag or “blocked by” notation. Flavor B: dependency on platform + integration scope	Don’t Build What Nobody Asked For; Scan Roadmaps for Shared Needs; Ship the Smallest Thing; Design the Interface
3 — Platform Maturation	Adoptability	Self-service, KTLO reduction, adoption goals	Nothing (indirect benefit)	Mine & Delete Toilsome KTLO; Adoption Signals
4 — Adoption & Migration	Adoptability	Flavor A: capability + adoption tracking (Phase 1); migration support + deadline (Phase 2). Flavor B: sunset timeline, migration support commitment	Flavor A: voluntary adoption outcome (Phase 1); prepared technical outcome from platform (Phase 2). Flavor B: migration work with deadline before cutoff	Deprecation Patterns; Ease of Adoption; Forced Adoption failure mode
5 — Platform-to-Platform	Clearly Defined Boundaries	Capability outcome with consuming platform named; dependency flag if upstream	Dependency flag with second-order risk noted (when applicable)	Cross-Portfolio Dependency Review; Design the Interface