Skip to content

PATTERN

Pilot to platform via internal demand

Intent

When a single team successfully deploys a novel capability for its own use case, let inbound interest from other internal teams serve as the validation signal that the capability should be productised as an org-wide platform — rather than letting each team independently re-implement the same primitive, or pre-building a platform before any team has proven the capability works.

This is a phased organisational pattern for platform construction:

  1. Team-scoped pilot — one team solves its own problem with a novel capability, validating the technology + design choices against a concrete use case.
  2. Internal-demand signal — other teams with similar problems hear about the pilot and request access / adoption.
  3. Platform build-out — pilot team evolves their solution into a reusable, multi-tenant platform serving all interested teams, turning every pilot-phase manual step into a platform feature.

Problem

Engineering organisations face a chronic tension when novel capabilities (new protocol, new vendor, new architecture) come online:

  • Premature platformisation. Building an internal platform before any team has proven the capability solves a real problem wastes investment on the wrong abstractions.
  • Fragmentation. Letting every team independently adopt the capability produces N-incompatible deployments with duplicated ops cost and no governance coherence.
  • Political capture. A single early-adopter team may build a team-specific tool that doesn't generalise, but because it works for them they defend against evolving it into a shared platform.

Solution

Follow a three-phase progression:

Phase 1 — Team-scoped pilot

One team picks up the novel capability for a concrete business problem they own. They:

  • Make decisive technology choices (open protocol over proprietary, managed over self-hosted, etc.) driven by their specific needs.
  • Accept manual operations where automation isn't worth building yet (partner onboarding one-by-one, credential delivery by email).
  • Do cross-team collaboration with platform / security / governance teams up front to make sure the pilot passes org standards even if it's small.
  • Measure success against their business problem, not against hypothetical future use cases.

The pilot exists because "our team needs this to work for our problem" — not because "we think this is the right platform for the company".

Phase 2 — Internal-demand signal

Word of the pilot spreads through the organisation. Other teams with similar problems reach out:

"Word of our Delta Sharing pilot began spreading through Zalando's internal networks, generating inquiries from teams across the organisation. Other departments working with partners started reaching out, recognising the potential for their own data sharing challenges."

The number, breadth, and specificity of these inquiries is the signal. If nobody else reaches out, there's no platform to build — the capability was a single-team win, not a company- wide primitive.

Phase 3 — Platform build-out

The pilot team evolves their solution into a reusable platform for all interested teams, with explicit goals:

  • Avoid fragmentation. Rather than each team building their own, offer a single managed primitive all teams can adopt.
  • Codify pilot lessons. Best practices discovered during pilot become platform documentation.
  • Automate manual operations. Every pilot-phase manual step becomes a platform API / feature.
  • Expand governance. Platform needs to support different teams with different compliance needs.
  • Shift operator identity. Team-that-owns-pilot becomes team-that-owns-platform; often needs additional headcount or explicit inner-sourcing contract with consumers.

Canonical instance — Zalando Partner Data Sharing

systems/zalando-partner-data-sharing-platform documents this three-phase progression:

  • Pilot — Partner Tech division deploys Delta Sharing for their own partner-data problem (~200+ datasets, thousands of partners, >€5B GMV). Manual Recipient creation, manual activation-link distribution.
  • Internal demand — "Other departments working with partners started reaching out". Multiple Zalando teams recognised their own data-sharing use cases matched the same architectural shape.
  • Platform — "We're building the infrastructure that will enable any team at Zalando to implement secure, scalable data sharing through Delta Sharing". Partner Tech evolves their solution into a reusable recipient-management platform.

The explicit framing from the post: "Internal demand validates external value. When teams across Zalando started asking how they could leverage similar capabilities, we knew we had built something with broader applicability than our original scope."

(Source: )

Consequences

Upsides

  • Validation comes from use, not committee. The business case for the platform is demonstrated; no architecture-board debate about whether the capability is needed.
  • Pilot team owns platform. Institutional knowledge stays intact; no handoff to a new platform team who has to relearn the domain.
  • Multi-tenancy gets designed in, not retrofitted. Platform phase starts with known-good architecture + known-pain-points from pilot, which informs multi-tenant design.
  • Prevents N-way fragmentation. Acting on internal-demand signal early avoids a later migration from "every team built their own" back to a shared platform.

Downsides

  • Pilot team may not want to become platform team. The skill set for solving our problem differs from operating a shared platform for 12 tenants. Either team grows, splits, or hands off.
  • Pilot may over-fit to pilot team's use case. Platform phase may require substantial re-architecture to generalise; not all pilot abstractions survive.
  • Latency. Phase 2 (internal demand) is out of the team's control; if demand never materialises, the team has a team-scoped solution and no platform. This is fine — it means the capability wasn't platform-worthy.

When not to apply

  • When the capability is obviously platform-scale from day one. (E.g. authentication, observability.) Don't wait for inbound demand; build the platform directly.
  • When internal demand doesn't appear. This pattern explicitly requires a demand signal. A pilot with no inbound interest is just a single-team tool — leave it that way.
  • When pilot team is structurally incapable of becoming platform team (wrong charter, wrong skills). Hand off explicitly at Phase 3, but plan for knowledge transfer cost.

Composition

Seen in

  • — Zalando Partner Tech's Delta Sharing deployment narrates this exact three-phase progression: pilot for partner-tech → "word spread... inquiries from teams across the organisation" → building "a comprehensive platform for recipient management across Zalando". The post explicitly names "internal demand validates external value" as a load-bearing lesson.
Last updated · 428 distilled / 1,221 read