Why Platform 2.0 Fails Before It Starts

Most platform transformations fail before they leave the launchpad. This is rarely due to technology alone. More often, two quiet killers are at work: the reduction of enablement to agency work, and the collapse of real specifications.

From Enablement to Agency

True enablement means creating self-service systems so that teams can act without relying on the platform team. Agency work means performing the work for them. The more a platform team operates as an agency, the more it remains in the critical path, reducing the ability to compound leverage.

Platform 2.0 is more than a collection of tools. It is the deliberate construction of a software factory where repeatable processes, progressive self-service, and measurable leverage are embedded from the outset. It is designed to make teams autonomous, with clear boundaries between ownership of the what and why, and the how. For a full explanation, see our earlier article: Platform 2.0 – Building the Software Factory, Not Just the Tools.

Enablement, in its proper form, is not the platform team building bespoke solutions for product teams. It is the process of identifying and delivering capabilities that allow product teams to grow their domains independently, from a platform-agnostic perspective. Much like a CI/CD pipeline is agnostic of the application code it deploys, a product platform team might provide orchestrators for business flows without dictating their steps, or enable data streaming and capture through schema and registry deployment, etc. The role of the product team is to operate within its domain and to interface with the platform’s systems through programmatic governance.

The platform enables only and the product team brings the business domain context.

In the language of Christopher Alexander’s The Synthesis of Form, the platform provides the surface : the shape that supports and constrains. While domain teams must bring the context. Achieving this requires hiring top performers with strong cross-functional skills, able to step outside their comfort zones and engage in genuine collaboration with platform engineers.

A product platform exists to accelerate business delivery through the creation of leverage. It should not be held accountable for poor use of the systems it provides. Performance metrics must therefore target the conversion of complex, fragmented needs into streamlined capabilities, rather than the downstream business outcomes that depend on how those capabilities are applied.

Platform 1.0 vs Platform 2.0

• Platform 1.0: Centralised tooling, manual onboarding, reactive support, project-based delivery. Success measured by tickets closed.
• Platform 2.0: Progressive self-service, policy-as-code, reusable patterns, measurable leverage. Success measured by capability adoption, time-to-autonomy, and reduced dependency on the critical path.

The shift from 1.0 to 2.0 requires a shared understanding of what enablement actually means and the discipline to protect it from being reduced to service fulfilment.

The Specification Collapse

Specifications should state the problem, not prescribe a pre-packaged solution. Current patterns often look like this:

• “We lack the skills to assess trade-offs.”
• “We will tell the platform team exactly what to build.”
• “The platform team can decide if this is feasible.”

This shifts the burden of product thinking to the platform team, reducing the ability to invest in scalable, generic solutions.

Clear problem statements emerge from establishing a foundational ubiquitous language centred on capabilities. This means defining the essential building blocks, the what, that must be communicated to avoid stakeholders approaching the platform team with instructions on how to build. For example:

• Capability statement: “Customers need to validate document authenticity in under two seconds, regardless of file type.”
• Solution order: “Build a new image processing service with this specific library.”

The first enables platform teams to explore optimal, reusable solutions. The second forces them into narrow, project-specific execution.

Ambiguity invites speculation. Speculation drives solution definition rather than problem framing.

The Vicious Loop

Poor specifications force platform teams into execution mode, leaving little time for systemic enablement. This in turn produces weaker specifications.

The resulting deadlock generates harmful side effects: increased entropy, erosion of credibility in platform leverage within already strained environments, the rise of blame cultures, and the absence of space for growth or the development of genuine ownership and accountability.

In highly political, ego-driven environments, blaming the platform team often becomes the convenient choice. Politics then distorts priorities, forcing platform teams to spend as much effort defending their existence as building capabilities, making the transition to Platform 2.0 almost impossible.

The Way Out

Platform 2.0 succeeds when the platform team owns the how and product teams own the what and why. Leaders should:

1. Reinforce that enablement is about capability creation, not concierge work.
2. Require high-quality problem statements supported by a precise capability language.
3. Protect platform capacity for systemic investment.
4. Reward cross-functional excellence rather than throughput.

If enablement looks like agency work and specifications read like orders, the organisation is not building a platform. It is outsourcing ownership and ensuring it will remain trapped in Platform 1.0.