The Platform Isn’t the Product. The Operating Model Is.
A practical guide to segmenting your product portfolio, tailoring your platform offerings, and using Flow Engineering to align strategy with execution.
1. Context: Cloud Adoption, Platform Engineering, and Why This Matters
Over the last decade, “move to the cloud” has become a default strategic goal for large organizations. Most companies today have a cloud-first strategy on paper, a handful of successful cloud-native products, and a growing list of migration projects. Yet when you ask executives what value they are actually getting from the cloud, the answers are often vague: “We are reducing data center footprint,” “We are improving flexibility,” “We are modernizing legacy systems.”
Those are useful directions, but they are not the full picture.
Cloud is not just a different place to run servers. Done well, it is a way to change how products are built and operated — from waterfall projects to continuous delivery, from multi-year CAPEX cycles to dynamic cost optimization, from siloed operations to shared reliability engineering. The real question is not only how do we adopt cloud? but how do we accelerate the value we get from cloud?
That is where platform engineering comes in.
Platform engineering is the discipline of building internal platforms that make it easier, safer, and faster for product teams to use cloud capabilities. Instead of each team reinventing account structures, networks, security controls, deployment pipelines, and observability stacks on their own, a platform team provides:
A Cloud Infrastructure Platform that standardizes cloud accounts, landing zones, networking, identity, security policies, and base runtimes across the organization.
An Internal Developer Platform (IDP) that offers higher-level workflows and golden paths for custom software: CI/CD pipelines, service templates, self-service environments, and developer portals.
If you get this right, platform engineering accelerates both sides of the equation:
Cloud adoption. Migrations become repeatable instead of one-off bespoke projects. Modernization journeys — from bare VMs to managed containers to serverless — follow documented patterns that accumulate organizational knowledge. New products can start on a paved road rather than hacking their own path through an untamed infrastructure jungle.
Cloud value. Product teams spend more time on features and less time on infrastructure scaffolding. Security incidents decrease because guardrails are consistent and centrally maintained. Compliance becomes built-in rather than bolted on. Cost optimization moves from heroic quarterly efforts to a continuous, automated capability.
However, there is a catch. In a large, product-centric organization with dozens of products at different stages of cloud adoption, not every team needs or wants the same kind of platform. Some products primarily operate commercial off-the-shelf (COTS) applications and need reliable, managed cloud operations. Others build custom software and crave a rich developer experience. Some are cloud-mature and autonomy-driven; others are early in their journey and want the simplicity of a managed service.
If you offer a single, monolithic platform to everyone, you will inevitably be too much for some products and not enough for others. You will spend significant time and budget building capabilities that large parts of your portfolio ignore, while the products that could benefit most remain underserved.
This post is about that reality. How do you design cloud operating models across a diverse product portfolio? How do you decide which products should use which model? How do you tailor your Cloud Infrastructure Platform and Internal Developer Platform to different product personas? And how do you use Flow Engineering to connect all of this into a coherent, executable platform strategy?
The answers emerged from working through exactly this kind of environment: an organization in the process of splitting a full-stack platform into a Cloud Infrastructure Platform and an Internal Developer Platform, trying to serve 30+ products with very different needs, skills, and ambitions.
2. The Core Challenge: One Enterprise, Many Products
The illusion of a single target state
When platform teams discuss their long-term vision, a familiar picture tends to emerge: every product becomes a fully autonomous, stream-aligned team that runs on a rich, multi-layer platform, focuses entirely on innovation, and never has to think about infrastructure. It is a compelling ideal, drawn from Team Topologies, the CNCF Platform Maturity Model, and a growing body of platform engineering best practice.
The problem is that this vision assumes a degree of organizational homogeneity that rarely exists in large enterprises. In reality:
Products differ enormously in their workload composition. Some run SAP landscapes, Oracle databases, and off-the-shelf analytics software. Others build microservices, data pipelines, and custom SaaS products. The platform needs of these two groups are fundamentally different.
Products differ in their cloud maturity and skills. One product group may have been running Kubernetes in production for three years. Another has never provisioned a cloud account and relies on a managed data center contract that is about to expire.
Products differ in their desire to adopt a central platform. Some are eager to reduce their operational complexity and will actively contribute to the platform’s development. Others have strong in-house engineering capabilities, a healthy skepticism toward central mandates, and a strong preference for autonomy.
Products differ in their relationship with central IT. Some see the platform team as a trusted partner. Others — often for historically valid reasons — perceive central IT as a bottleneck and view platform adoption as trading one form of constraint for another.
These differences are not edge cases. They are the rule in any organization with more than a handful of products.
What platform teams typically get wrong
The most common mistake is treating platform engineering as a technical problem rather than an operating model problem. Teams invest heavily in tooling — a Kubernetes platform, a developer portal, a CI/CD factory — and then wonder why adoption remains low. The answer is usually not that the tools are bad. It is that the operating model assumed by those tools does not match the operating model that many products actually need.
A second common mistake is what you might call the commander mindset: the belief that if you build the right platform, product teams should simply adopt it because it is centrally mandated or architecturally optimal. In practice, voluntary adoption in a diverse product organization requires something harder than technical excellence — it requires a compelling, differentiated value proposition that meets each product where it actually is. Compliance and standardization can be enforced at the foundation layer. Everything above that is earned through trust and demonstrated value.
A third mistake is confusing the existence of a platform with the acceleration of cloud value. A platform that products do not use, do not trust, or do not find relevant to their workloads is not accelerating anything. It is a cost center that generates internal friction.
3. From a Full-Stack Platform to a Layered Platform Landscape
The starting point: the monolithic full-stack platform
Many organizations arrive at platform engineering by growing a team around a set of useful shared services. Over time, what starts as a small set of reusable Terraform modules and a shared CI/CD pipeline becomes an increasingly complex full-stack offering that tries to cover everything: cloud accounts, networking, security, runtime environments, deployment pipelines, observability, service catalogs, and developer tooling.
This kind of platform is not wrong — it often represents genuine organizational progress. But it creates several structural problems:
Blurry boundaries. When a single team owns everything from IAM policies to application deployment templates, it becomes unclear who is responsible for what. Product teams do not know where the platform ends and their own responsibility begins. The platform team gets pulled into firefighting at every layer.
Wrong abstractions for many products. A product running SAP on VMs does not need golden path templates for container deployments. A product building microservices does not need the platform team to manage their application runtime. A single full-stack platform inevitably over-serves some products and under-serves others.
A single bottleneck for all problems. When one team owns the full stack, every request — from a new landing zone for a migration to a new CI/CD template for a greenfield product — competes for the same capacity. Roadmap prioritization becomes a political exercise, and products with very different needs fight for the same team’s attention.
The separation: Cloud Infrastructure Platform and Internal Developer Platform
The natural response to this complexity is a deliberate split into two distinct platform layers, each with its own team, ownership, and product focus.
The Cloud Infrastructure Platform covers the foundational layer that every cloud workload needs, regardless of its type or maturity:
Cloud account structure and landing zones
Networking, connectivity, and DNS
Identity and access management (IAM)
Security policies, guardrails, and compliance automation
Cost management and FinOps tooling
Base compute runtimes (VMs, container orchestration, managed databases)
Shared observability infrastructure
The Cloud Infrastructure Platform is opinionated about security, compliance, and cost. It is not opinionated about how products build their software. Its primary value proposition is removing undifferentiated heavy lifting at the infrastructure level — so that no product team has to re-solve account structure, VPC design, or security baseline policies on their own.
The Internal Developer Platform (IDP) sits above the Cloud Infrastructure Platform and focuses on the workflow layer for custom software development:
CI/CD pipelines and deployment automation
Service templates and golden paths for common application patterns
A developer portal and self-service catalog
Application-level observability integration
IaC modules and scaffolding for product teams
Inner source contribution mechanisms
The IDP is opinionated about developer workflows. Its primary value proposition is accelerating the pace at which product teams can deliver and operate custom software by reducing the cognitive load of cloud-native development.
This separation matters enormously for what follows. The Cloud Infrastructure Platform is a universal foundation — every product that migrates to the cloud needs it. The IDP is a targeted accelerator — primarily valuable for products that build custom software and are ready to adopt a platform-centric development model.
Getting this separation wrong is costly. Organizations that bundle everything into the IDP end up with a platform that is irrelevant to a large portion of their product portfolio. Organizations that invest only in the Cloud Infrastructure Platform miss the opportunity to dramatically accelerate product development for their most capable teams.
4. The Cloud Operating Model Spectrum
Defining a platform strategy for a diverse product portfolio requires a shared vocabulary. One of the most useful tools is a structured spectrum of cloud operating models — archetypal patterns for how responsibility is split between the platform team and each product.
This spectrum is defined by two fundamental questions:
How much does the platform own?
From nothing (products are on their own) to everything (products only write code).How much does each product own?
From everything (full autonomy on raw cloud) to almost nothing (pure consumption of managed services).
Five archetypal models emerge along this spectrum.
Model A — Cloud-Native DIY
Products operate directly on the cloud provider, making their own decisions about every layer: accounts, networking, security, compute, CI/CD, and everything else. There is no meaningful central platform.
This model preserves maximum autonomy and works well for large, technically mature product teams with deep cloud expertise. It is, however, the direct equivalent of the old on-premise operating model — just in a different location. For the majority of product teams in a large enterprise, this model means reinventing the same infrastructure foundation over and over, accumulating inconsistent security practices, and creating significant organizational risk.
Model B — Managed Landing Zone
The Cloud Infrastructure Platform provides the foundational layer: cloud accounts, landing zones, networking baselines, IAM structures, and security guardrails. Products operate within this foundation and are responsible for everything above it.
This is the most common first step in an enterprise platform strategy. It eliminates the most duplicated infrastructure work and establishes a consistent security and compliance baseline. However, product teams still carry a significant cognitive load — they must manage their own compute, CI/CD, observability, and everything else above the foundation layer.
Model C — Cloud Infrastructure Platform with Product Platform Teams
The Cloud Infrastructure Platform handles the foundation layer. Products with sufficient engineering capacity build their own thin platform on top — a small, focused internal platform for their specific product domain. This federated model gives technically advanced products the autonomy to make their own architectural choices while still benefiting from a shared, secure foundation.
This model suits organizations where some product groups have genuine platform engineering ambitions and the capacity to execute them. It requires very clear interface contracts between the Cloud Infrastructure Platform and the product-level platforms, but it scales well for autonomous, high-capability teams.
Model D — Layered Platform
The Cloud Infrastructure Platform and the Internal Developer Platform together provide a multi-layer offering. Products consume opinionated workflows, golden paths, and higher-level abstractions without needing to manage the underlying infrastructure or build their own tooling. Their responsibility is largely limited to application code and configuration.
This model represents the sweet spot for the majority of product teams in a well-designed enterprise platform strategy. It dramatically reduces cognitive load, accelerates migration and development, and enables standardization without sacrificing meaningful product-level control. It requires significant platform team investment to build and maintain both layers, and it requires product teams to trust the platform — which must be earned through reliability, developer experience, and responsiveness.
Model E — Full Managed Platform
The platform team manages the entire stack end-to-end. Product teams focus exclusively on writing application code. All infrastructure, runtime, deployment, observability, and operations concerns are abstracted away.
This model maximizes simplicity for product teams and enables the fastest possible onboarding for new workloads. It is the aspirational endpoint of the platform engineering journey and the ideal model for small product groups without dedicated infrastructure capacity. However, it requires an exceptionally mature and high-capacity platform team, and it carries the highest risk of the platform becoming a bottleneck and a single point of failure for the entire portfolio.
Key trade-offs across the spectrum
No single model dominates on every dimension. The table below captures the key trade-offs:
The direction is consistent: moving from left to right trades product autonomy and required skills for standardization, speed, and reduced cognitive load. Every step rightward requires more platform investment and more trust between product teams and the platform.
Why Model D Often Wins the Vote — and Why That’s Not the Full Story
When platform teams present this spectrum to product stakeholders, Model D — the Layered Platform — almost invariably wins the most votes. It is easy to understand why. Model D sounds like the best of both worlds: meaningful abstraction without total loss of control, strong central capabilities without total dependence on the platform team. It matches the narrative of CNCF’s platform maturity model, Team Topologies’ stream-aligned team ideal, and most of the influential writing on platform engineering.
But there is a critical gap between “Model D is the ideal we aspire to” and “Model D is the right model for our product portfolio today.”
A full-stack Internal Developer Platform is primarily valuable for products that build custom software, have development teams capable of adopting new workflows, and are motivated to invest in the onboarding process. For these products, the IDP is a genuine accelerator.
But a product group running SAP, Oracle ERP, or a major COTS analytics suite does not need a developer portal or CI/CD golden paths. What they need is reliable managed operations for their packaged software — backup automation, patch management, monitoring, lifecycle support. Giving them an IDP is not just unnecessary; it actively confuses the value proposition and reduces trust.
Similarly, a product group with a large, mature engineering team and a strong autonomy preference may be technically capable of adopting the full IDP — but they do not want to. They will view mandatory platform adoption as a constraint rather than an enabler, and they are likely to build shadow solutions if pushed too hard.
The key insight is this: Model D is a good target for many products, but not for all products. A successful enterprise platform strategy does not pick a single model and force it on a heterogeneous portfolio. It defines a portfolio of operating models and provides tailored platform offerings that meet each type of product where it actually is.
5. The Product Team Adoption Lifecycle: Three Phases
It’s important to distinguish between different adoption lifecycle phases for each internal customer persona, depending on where those are in their journey of cloud or platform adoption. The following framework helps to break the adoption lifecycle into three main phases:
Phase 1 — MOVE — “Get onto the platform safely”
This is the migration and modernization phase: the product team is in transit. Their primary challenge is not yet getting value from the platform — it’s completing the journey without breaking things.
What they care about:
Getting workloads onto cloud and/or onto the platform without disruption.
Understanding what the platform can and cannot do.
Having a safe landing: a stable baseline environment, clear responsibility boundaries, and help when things go wrong.
Transforming their workloads (Rehost → Replatform → Refactor) while keeping the business running.
What the platform must provide:
A reliable on-ramp: landing zones, account setup, migration playbooks.
Guardrails, not walls — enough safety without blocking progress.
Hands-on enablement and migration support.
Clear handover moments: “You’re now live on the platform.”
The platform’s job here is to be a soft landing pad, not a feature showcase.
Phase 2 — LAND — “Operate and stabilize on the platform”
This is the phase you intuitively described as “the platform as a soft landing on cloud.” The product team has arrived. Their workloads are running on the platform. Now the question becomes: can they operate, maintain, and sustain what they’ve built?
What they care about:
Stability, reliability, and predictability.
Operational confidence: monitoring, incident response, patching, cost visibility.
Understanding what good looks like on the platform.
Beginning to feel the first tangible benefits: less toil, faster change, safer deployments.
What the platform must provide:
Managed runtime and operations support (especially for Q1 and Q3).
Observability and cost management as first-class offerings.
Self-service for common operational tasks (so the platform team doesn’t become the bottleneck).
Early proof points: “Here’s what you gained by being on the platform.”
The platform’s job here is to deliver on the promise made during Phase 1.
Phase 3 — EVOLVE — “Extract and grow cloud and platform value”
This is the long-term phase. The product team is stable on the platform. Now they shift focus from “getting it to work” to “getting more out of it.” This is where cloud and platform value compounds.
What they care about:
Cost optimization: FinOps, rightsizing, reserved capacity.
Security posture evolution: not just compliant, but progressively more secure.
Organizational evolution: moving toward stream-aligned teams and reducing platform dependencies through better self-service.
Innovation: using managed AI/ML services, event-driven architectures, advanced data platform capabilities.
Contributing back: Inner Source, sharing patterns with other product teams.
What the platform must provide:
Continuous product evolution — the platform must keep improving or teams outgrow it.
FinOps tooling and cost transparency.
Advanced developer experience and productivity metrics (DORA metrics, developer satisfaction).
Community and contribution model: teams co-evolve the platform.
Enablement for organizational evolution (Team Topologies patterns: enabling teams, reduced cognitive load, shifting team interaction modes).
The platform’s job here is to be a long-term growth engine, not a migration tool.
Crossing the Chasm Mapping
While “Crossing the Chasm” was written in the context of external, end customer products, the same principles apply to platform, if you treat those as products you’re selling to internal product teams. The following diagram maps those 3 adoption phases to different internal customer persona types and shows where Geoffrey Moore’s Chasm applies.
6. Segmenting Products: A 2×2 Matrix
To move from a single monolithic operating model to a portfolio of models, you need a practical way to segment your products. The segmentation should be simple enough to apply to 30+ products quickly, but rich enough to yield meaningfully different platform strategies.
Two dimensions turn out to be particularly powerful.
Dimension 1: Workload profile
This dimension asks: what is the dominant type of workload this product operates?
At one end are COTS-dominant products — product groups where 70% or more of the workload consists of commercial off-the-shelf software, packaged applications, or vendor-managed solutions. Think ERP systems, HR platforms, COTS analytics suites, and similar applications. These products rarely need a developer platform. What they need is reliable, standardized cloud operations: managed runtimes, automated backup and patching, lifecycle tooling, and monitoring.
At the other end are custom-dominant products — product groups where the majority of workloads are custom-built software, microservices, data pipelines, or heavily customized solutions with active development teams. These products are the natural audience for an Internal Developer Platform.
Many products sit somewhere in between. The dimension asks for the dominant profile, not a binary classification.
Dimension 2: Platform maturity and desire
This dimension asks: how ready and willing is this product to adopt a platform model?
At the low end are products that are early in their cloud journey, lack cloud-native skills, or are skeptical of central platforms. They may have had bad experiences with central IT in the past, or they may simply not yet understand the value proposition. They require a very different engagement strategy than products at the high end.
At the high end are products with meaningful cloud experience, a clear understanding of what a platform can do for them, and an active desire to adopt a platform model. They are ready to invest in onboarding, willing to trade some autonomy for platform-level capabilities, and potentially interested in contributing to the platform as inner source collaborators.
This dimension is a compound of several factors that you can assess through surveys and interviews:
Cloud adoption maturity and existing cloud skills
Understanding of and attitude toward platform engineering concepts
Autonomy preference (high autonomy preference correlates with lower platform desire)
Past experience with central IT (positive correlates with higher platform desire)
Urgency of migration and modernization needs
The 2×2 matrix: four product personas
Combining these two dimensions yields a 2×2 matrix with four quadrants, each representing a distinct product persona with meaningfully different platform needs.
How to score a product into the matrix
You can position products on the matrix by scoring them on six to eight short survey questions, covering:
Custom development intensity — How much custom software does this product develop and maintain?
COTS dependency — What percentage of workloads are packaged, vendor-managed, or off-the-shelf?
Cloud maturity — How experienced is this product with cloud services and cloud-native practices?
Platform desire — How strongly does this product want to adopt central platform services?
Autonomy preference — How important is it for this product to make independent infrastructure decisions?
Migration urgency — How much pressure is there to migrate from the existing data center?
Innovation ambition — How important is technology innovation as a competitive differentiator for this product?
Score each dimension on a one-to-five scale, then derive X and Y coordinates: the workload profile axis from dimensions 1 and 2, and the platform desire axis from dimensions 3, 4, and 5 (with autonomy preference inversely weighted). The result is a visual map of your entire product portfolio — a foundation for product-specific platform engagement strategies.
7. Tailoring Platform Offerings to Each Product Persona
The segmentation matrix is only useful if it drives differentiated action. Here is what each quadrant means for your platform team’s offering, engagement model, and value proposition.
Q1 — Operate & Stabilize: The COTS Operators
Profile. These products primarily operate COTS or vendor-managed software. They have small IT teams, limited cloud skills, and low interest in managing infrastructure themselves. Their typical motivation for cloud migration is data center contract expiry or cost reduction rather than innovation. They are not asking for a developer platform — they want someone to take the infrastructure problem off their hands.
Platform needs. The Cloud Infrastructure Platform is essential — these products need a secure, compliant foundation. Above that, they need a managed cloud operations offering: managed runtime environments, automated backup and patching, COTS-specific lifecycle management tooling, monitoring and alerting preconfigured for their application types, and clear SLAs. The Internal Developer Platform is largely irrelevant to them.
Migration strategy. Rehost (lift and shift) as the default, with selective replatforming to managed cloud services (for databases, for example) where the operational benefits are clear and the migration risk is manageable.
Engagement model. Guided migration with a defined handover to a managed service. Ticket-based support with SLA commitments. Quarterly reviews rather than continuous co-creation.
Value proposition. “We operate your packaged software reliably in the cloud — you focus on business outcomes, not infrastructure management.”
Q2 — Lift & Optimize: The Cloud Skeptics
Profile. These products build custom software with their own engineering teams and have a strong preference for autonomy. They may be technically capable — perhaps more so than the platform team in their specific domain — but they are skeptical of centralized platforms. They have their own CI/CD pipelines, their own Terraform modules, their own monitoring setup. They see a central platform as a constraint, not an enabler.
Platform needs. This group needs the Cloud Infrastructure Platform for the foundational layer — and that is often where it stops. Enforce security guardrails at the account and network level. Offer a well-documented, self-service landing zone. Provide office hours and documentation. Do not try to force the Internal Developer Platform on them.
Migration strategy. Products in this quadrant will typically run their own migration programs on top of the Cloud Infrastructure Platform foundation. Support them with clear documentation, runbooks, and optional enablement sessions — but let them own the execution.
Engagement model. Minimal friction. Self-service, documentation-first, optional enablement. The goal is not deep engagement today — it is keeping the door open and letting demonstrated platform value (visible in Q4 products) gradually shift their perception over time.
Value proposition. “We provide a secure, compliant cloud foundation. What you build on top is your decision.”
Strategic note. Do not try to win this quadrant by force. The path to converting Cloud Skeptics is through visible, undeniable success stories from Q4 products. When they see that the IDP genuinely accelerates development velocity, some will become willing adopters. The goal is to create the conditions for a natural pull, not to manufacture artificial demand.
Q3 — Enable & Empower: The Platform-Ready COTS Products
Profile. These products share the COTS-heavy workload profile of Q1, but they have higher cloud maturity and a genuine desire to leverage a platform. They understand the value of standardization and automation, and they are actively looking for ways to reduce their operational burden. They are often willing inner source contributors — they may not build custom applications, but they have operational knowledge worth sharing.
Platform needs. These products benefit enormously from the Cloud Infrastructure Platform combined with a rich COTS operations automation offering: automated lifecycle management for their vendor software, patch orchestration, backup and recovery automation, cost management dashboards, and unified observability. They may also benefit from limited IDP capabilities where they have custom integrations or lightweight automation built around their COTS systems.
Migration strategy. Rehost initially, transitioning to replatforming where managed cloud services can replace self-managed COTS components (for example, migrating a self-managed database to a cloud-managed equivalent).
Engagement model. Guided migration plus ongoing collaboration. Community of Practice membership. Advisory board participation — these products are excellent candidates for co-designing the COTS operations offering.
Value proposition. “We automate your COTS operations — less time on patching and maintenance, more time on the business outcomes your software delivers.”
Q4 — Accelerate & Innovate: The Full Platform Adopters
Profile. These are your lighthouse products. They build substantial custom software, have experienced engineering teams, are either cloud-mature or actively growing their cloud capabilities, and are genuinely motivated to adopt a platform model. They understand the value of golden paths and developer portals, they want self-service environments, and they are likely to become active inner source contributors who improve the platform for everyone.
Platform needs. The full stack: Cloud Infrastructure Platform foundation, complete Internal Developer Platform offering — CI/CD golden paths, container platform, developer portal and self-service catalog, IaC scaffolding, application-level observability, and inner source contribution mechanisms.
Migration strategy. Replatform and refactor. These products should move to cloud-native architectures — containers, managed services, event-driven patterns — rather than simply re-hosting.
Engagement model. Deep co-design. These products should be involved in shaping the IDP roadmap from the start. Use them as design partners for new capabilities, showcase their successes internally, and build inner source mechanisms that let them contribute IDP features back to the platform.
Value proposition. “We accelerate your product delivery by removing infrastructure complexity — so your engineers spend their time on business innovation, not platform maintenance.”
8. Connecting Product Segmentation to the Platform Roadmap
With the 2×2 matrix in place, the critical question becomes: in what order should you build what?
The Cloud Infrastructure Platform is your universal foundation
Every quadrant needs it. Q1 needs it as the base for managed COTS operations. Q2 needs it as the starting point for their own cloud journey. Q3 needs it as the foundation for operations automation. Q4 needs it as the substrate for the full IDP.
This means the Cloud Infrastructure Platform must be your first, highest-priority investment — and it must be designed to serve all four personas simultaneously. Its value proposition varies slightly by quadrant (guardrails for Q2, managed services foundation for Q1/Q3, golden path substrate for Q4), but the underlying capabilities are shared.
The Internal Developer Platform is a targeted investment
The IDP primarily serves Q4 products and partially Q3. It is largely irrelevant to Q1 and actively unwanted by Q2. This has important implications:
Do not build IDP features before you have a clear, committed Q4 audience.
Do not measure IDP success by adoption across the full product portfolio — measure it by depth of adoption and acceleration within Q4.
Avoid the temptation to generalize IDP capabilities to cover Q1 and Q3 COTS use cases — that leads to a bloated, unfocused platform that serves nobody well.
A phased roadmap
Given the above, a well-structured platform roadmap for a diverse product portfolio tends to follow four phases:
Phase 1: Universal foundation (months 1–6).
Establish the Cloud Infrastructure Platform with landing zones, account factory, networking, IAM, security guardrails, and cost controls. This serves all four quadrants and immediately creates value for the first migration waves.
Phase 2: COTS operations automation (months 3–9).
Build managed runtime and COTS operations capabilities on top of the Cloud Infrastructure Platform. This is high-impact for Q1 and Q3, which together may represent the majority of your product portfolio by count. Backup automation, patch orchestration, and COTS monitoring are practical, high-value capabilities that can be delivered incrementally.
Phase 3: Internal Developer Platform for Q4 (months 4–12).
Build out the IDP with lighthouse Q4 products as design partners. CI/CD golden paths, container platform, developer portal, and self-service environments. Use Q4 products as living proof points. Start demonstrating measurable improvements — deployment frequency, lead time, change failure rate.
Phase 4: Inner source and scale (from month 9).
Open the platform for contributions. Introduce Community of Practice mechanisms. Encourage Q3 products to contribute COTS automation patterns. Allow Q4 products to submit and maintain golden path templates. Begin scaling from lighthouse products to the broader Q3 and Q4 population.
This phasing ensures that early investment creates immediate value across the full portfolio, and that the IDP is built with real demand rather than anticipated demand.
9. Using Flow Engineering to Design the Platform Strategy
Platform strategy is not just a technical blueprint
One of the most persistent failure modes in platform engineering is designing a platform that is technically well-architected but strategically misaligned. The team builds excellent infrastructure but serves the wrong outcomes. They deliver capabilities that product teams find irrelevant. They sequence investments in ways that create value for the platform team but not for the organization.
This happens because platform strategy is typically designed bottom-up — start with the technology, then work outward. What you actually need is a way to work from desired outcomes inward to platform capabilities, then outward to sequenced execution. This is precisely what Flow Engineering, as described by Steve Pereira and Andrew Davis, is designed to enable.
Flow Engineering is a practice for improving the flow of work, information, and decisions across organizations through value streams. At its core, it is a set of five visual maps that help teams move from confusion to clarity — from a fragmented understanding of the current state to a shared, executable path toward a better future. In the context of platform strategy, these maps are not just facilitation tools. They are a way of thinking about the problem.
The five maps in a platform strategy context
Map 1: The Outcome Map.
The Outcome Map asks the most fundamental question: what are we actually trying to achieve? In a platform engineering context, this means making explicit the outcomes that the Cloud Infrastructure Platform and the Internal Developer Platform are supposed to deliver — and being specific enough that you can tell whether you have achieved them.
Outcomes like “improve cloud adoption” or “reduce operational complexity” are starting points, but they are not sufficient. An Outcome Map for a platform strategy should define specific, time-bound targets: an adoption rate across the product portfolio, a reduction in time-to-onboard a new cloud environment, a measurable decrease in security incidents, a target migration velocity. It should also capture the benefits from three distinct perspectives — the product teams as customers of the platform, the organization as the entity investing in platform engineering, and the platform team as contributors. And critically, it should surface the known unknowns: the open questions that must be answered before meaningful progress can be made. In the context of 30+ products with heterogeneous needs, known unknowns include questions like: Which quadrant does each product sit in? What is a realistic adoption target? What does each product persona actually consider valuable?
The Outcome Map prevents the platform team from building for their own architectural preferences rather than for real product outcomes.
Map 2: The Current State Value Stream Map.
The Value Stream Map makes visible how work actually flows today — not how it is supposed to flow, but how it really flows. For platform strategy, this means mapping the current experience of representative product teams: what does it actually take to provision a new cloud environment? How long does it take to get from a request to a running application? Where are the waiting times, the handoffs, the rework loops?
Critically, this map will look very different for each of the four product personas. A Q1 COTS product team navigates a completely different value stream than a Q4 custom software team. Making these current states visible — with real timing data, real bottleneck identification, and real frustrations surfaced — is what creates shared urgency and alignment across product teams and platform teams. It also grounds the platform strategy in actual experience rather than assumed pain points.
Map 3: The Dependency Map.
The Dependency Map reveals the organizational and technical dependencies that constrain flow. For platform teams in large enterprises, these dependencies are often the invisible architecture — the network of relationships, approvals, handoffs, and constraints that nobody has ever drawn on a single page.
In a multi-product cloud migration context, the Dependency Map shows why different products end up in different quadrants of the segmentation matrix. A product that appears technically ready for Q4 may be trapped in Q2 behavior because of a dependency on a central networking team that has a six-week provisioning queue. A COTS product that appears to be in Q1 may be far closer to Q3 readiness than anyone realized, because it has a hidden dependency on a modernization program that is already underway.
Making these dependencies explicit has two immediate benefits: it identifies which platform investments will have the highest leverage in unblocking multiple products simultaneously, and it surfaces the organizational changes (in team structures, governance processes, and decision rights) that are just as important as technical platform capabilities.
Map 4: The Future State Value Stream Map.
Where the current state map shows what is, the future state map designs what should be. For each product persona, the future state map describes the target experience: what does it look like when a Q1 COTS product onboards to the managed operations offering? What does the deployment flow look like for a Q4 product using IDP golden paths? How does a Q3 product contribute a COTS automation pattern through inner source?
This map is where the operating model spectrum becomes concrete. Model D or Model E are abstract frameworks. The future state value stream map translates them into specific, tangible experiences for specific product personas — with measurable timing targets and clearly defined platform capabilities that enable them. It connects the persona segmentation directly to the platform product backlog.
Map 5: The Flow Roadmap.
The Flow Roadmap turns everything above into a sequenced plan for evolving the platform. It answers the question: given our current state, our dependencies, and our future state ambitions for each persona, in what order do we build what?
This is where the phased roadmap described in Section 8 gets its foundation. The flow roadmap is not a Gantt chart of platform features — it is a sequence of flow improvements, each one reducing a specific bottleneck for a specific product persona, each one measurable against the outcomes defined in the Outcome Map. Phase 1 (Cloud Infrastructure Platform foundation) addresses the dependency map’s most universal bottlenecks. Phase 2 (COTS operations) addresses the Q1 and Q3 current state pain points. Phases 3 and 4 deliver the Q4 future state and scale it.
How the five maps complete the picture
The product segmentation matrix tells you who needs what. The operating model spectrum tells you how responsibility should be distributed. The Flow Engineering maps tell you why those choices matter, where the real friction and opportunity are, and what to sequence in your roadmap.
Together, they form a coherent methodology for platform strategy that starts with human outcomes, moves through organizational reality, and arrives at an executable plan — rather than starting with technology choices and hoping outcomes follow.
10. From Model to Action: Practical Next Steps
The framework in this article is designed to be actionable without requiring a multi-month consulting engagement. Here is how to start putting it to work.
Run a lightweight product assessment. Design a short survey — no more than two or three pages, eight to ten questions — based on the two segmentation dimensions. Send it to IT leads across your product portfolio. Follow up with fifteen-to-thirty minute interviews for the ten to fifteen most strategically significant products. You do not need perfect data — you need enough signal to make defensible initial placements on the matrix.
Visualize the portfolio. Place products on the 2×2 matrix. Use bubble size to indicate workload volume, migration urgency, or strategic importance. Look for clusters: which quadrant is most densely populated? Where are the largest, most strategically important products? Are there products that are clearly misaligned with the current platform offering?
Identify lighthouse products in Q4. These are your most important design partners and early adopters. Work with them first, co-design the IDP offering with them, and make their successes visible across the organization. Their results are your most powerful adoption tool for the rest of the portfolio.
Co-design the COTS operations offering with Q3 products. Do not build this in isolation. Q3 products know exactly what they need — involve two or three of them as design partners in defining the COTS operations automation capabilities. This creates co-ownership, increases adoption, and produces a better product.
Use Flow Engineering maps for alignment. Even if you do not run the full mapping workshop, start with an Outcome Map. Get your platform team and key product stakeholders in a room (or a shared Miro board) and answer: what are we trying to achieve, who benefits and how, what is blocking us, what do we not know yet, and what are our next three concrete steps? This single session will surface misalignments and clarify priorities faster than any roadmap review or architectural discussion.
Establish a lightweight Advisory Board. Invite one or two representatives from each quadrant to a quarterly platform review. Give them visibility into the roadmap, give them a formal channel to provide feedback, and give them a mechanism to co-steer the direction. Products that feel heard and respected are far more likely to become willing adopters and contributors.
11. Conclusion
Platform engineering is one of the most powerful levers available for accelerating both cloud adoption and cloud value in large organizations. But its power is only realized when the platform is designed for the actual diversity of the product portfolio it serves — not for a homogeneous ideal that most products do not match.
The framework presented in this article offers a practical way to navigate that diversity:
Separate the Cloud Infrastructure Platform from the Internal Developer Platform so that foundational capabilities and developer experience capabilities can evolve at different speeds, for different audiences, with different value propositions.
Define a cloud operating model spectrum (Models A through E) so that stakeholders share a vocabulary for how responsibility is distributed — and so that the conversation is about operating models rather than just tools.
Apply a 2×2 product segmentation matrix to understand where each product actually sits: COTS-dominant or custom-dominant, low or high platform desire. Let that segmentation drive genuinely tailored platform offerings for four distinct product personas.
Use Flow Engineering maps to connect outcomes to current reality to future state to a sequenced roadmap — ensuring that the platform strategy is grounded in real product experiences and driven by real outcomes, not by platform team preferences.
The underlying principle is deceptively simple: meet products where they are, not where you wish they were. A Q1 COTS product that gets a managed operations offering it actually needs will generate more platform trust, more adoption, and more organizational momentum than a dozen half-hearted deployments of an IDP that nobody asked for.
Build from outcomes. Segment with honesty. Tailor with purpose. And let demonstrated value — not mandates — drive adoption.
Have thoughts on operating model design for platform engineering? I’d love to hear how your organization has approached the challenge of serving a diverse product portfolio.