Shifting Platform Development from Projects to Products
Ben Linders · rss · 2026-07-02 source ↗ Reader 🖥️
Once an internal platform outgrows serving a single team, the project model — upfront scope, milestone delivery, and velocity/completion metrics — stops producing a coherent, usable system, and the platform must instead be run as a product: driven by user problems, hypothesis-based roadmaps, self-service APIs, clear tenancy boundaries, and adoption metrics.
practical · mixed — An InfoQ experience report / Q&A by Ben Linders wrapping a practitioner argument. The article form is expository reporting, but the case it conveys is an argument for action: run a multi-tenant internal platform as a product. Anchored in a single company narrative plus interview quotes rather than a generalized theory, so it argues for a way of working, not for understanding — hence practical.
Structure
| Part | Role |
|---|---|
| Lede: the shift and its three named limitations (one-off deliveries, no product vision, weak feedback loops) | thesis-statement / framing |
| Description of the old project model (yearly planning, upfront scoping, budget, milestone-measured success) | context / the status quo being critiqued |
| The inflection point (platform grew from one Game Streaming service to many internal teams with different needs, 'fundamentally changing the nature of the system') | pivotal premise |
| Enumerated limitations (competing accumulated capabilities, no product definition, internal-only feedback loops optimizing completion over value) | evidence / diagnosis |
| Origins of the shift (systems & product thinking, Project to Product and The Phoenix Project, a community of practice among architects/senior engineers) | intellectual-lineage narrative |
| Technical evolution (Helm/namespace/GitLab IDP → AWS, self-service, multi-tenancy, abstractions, contracts) | illustration of the target state |
| Q&A: signals that forced the change, Scrum skepticism, and the 'internal cloud provider' architecture (service/control/management planes, composable building blocks, contracts) | elaboration / corroboration via interview |
Key terms
- Project approach vs product approach
Project = time-boxed initiatives with upfront scope, fixed budget, defined milestones, success measured by scope/time/delivery. Product = an ongoing offering with a product definition, hypothesis-driven roadmaps, and success measured by adoption and usability. - Internal customers
The other engineering teams that consume the platform, reframed from recipients of infrastructure into customers whose problems must be solved and whose adoption must be validated. - Feedback loops Feedback Loops
Signals from actual platform users about usability and value, contrasted against internal sprint metrics (velocity, completion, quality) that the old model relied on. - Internal cloud provider Platform Engineering
The target model in which the platform exposes infrastructure capabilities (clusters, storage, networking) through self-service, API-driven, Kubernetes-native interfaces, mirroring how public cloud providers behave. - Separation of concerns / contracts / tenancy boundaries Modularity & Coupling
Explicit interfaces and responsibility splits between platform and consumer, and between service/control/management planes, with 'contracts' as stable interfaces between layers.
Propositions
- explicitA platform serving a single service can be developed successfully as time-boxed projects measured by scope, time, and milestones.conf: high
- explicitWhen a platform grows to serve multiple internal teams with different needs, the nature of the system fundamentally changes and project-style delivery no longer fits.conf: high
- explicitProject-based platform work produces one-off deliveries, accumulated capabilities that compete for priority, and no coherent product definition.conf: high
- explicitInternal-only feedback loops (velocity, completion, quality) optimize for completion rather than long-term value because they carry no validation from actual users.conf: high
- explicitGrowing backlogs despite continuous delivery, teams working around the platform, and being unable to tell whether what was built is used, are the diagnostic signals that the project model has failed.conf: high
- explicitThe product approach reframes the shift as three moves: from delivering features to solving user problems, from fixed scope to hypothesis-driven roadmaps, and from output metrics to adoption/usability signals.conf: high
- implicitProduct thinking presupposes measurement infrastructure — you cannot run adoption-based product management without instrumentation to observe whether capabilities are used.conf: high
- implicitProduct thinking requires shifting funding and governance from project budgets (predictable, milestone-scoped, one-time) to ongoing product funding, and granting the platform team authority to prioritize by aggregate value and to say no to individual teams.conf: high
- implicitPart of the shift is constructing a product surface that does not yet exist, not merely reframing an existing one — the platform was 'never a single, unified platform but a set of capabilities that grew organically', so higher-level abstractions (environment/project constructs) must be built to make a 'product' cohere.conf: high
- implicitcorroboratedThe 'internal customer' relationship lacks the exit/choice of a real market, so adoption metrics can be satisfied by mandate rather than genuine demand.conf: mediumsupports ←TBM 430: Incubate, Compound, Refinance, Liquidate · p5 — Both identify the same failure mode from different angles: the InfoQ piece notes internal platforms lack a real market's exit/choice so mandate can substitute for genuine demand; TBM 430's 'Mandate Trap' names the same substitution explicitly as a platform-economics trap.
Arguments
A multi-tenant internal platform should be developed as a product, not delivered as a series of projects. strength: medium
Explicit premises:
- The platform outgrew single-team use and now serves multiple teams with different needs.
- Project delivery produced one-off deliveries, competing accumulated capabilities, and no product definition.
- Feedback loops were internal and optimized completion over long-term value.
- Backlogs grew despite continuous delivery, teams worked around the platform, and usage was unknowable.
Implicit premises:
- Multi-tenant platforms require a coherence and usability that project-by-project delivery structurally cannot produce.
- The organization can and will fund and staff an ongoing product rather than discrete budgeted projects (a project-budget → product-funding shift).
- The platform team is granted authority to prioritize by aggregate user value and to decline individual teams' requests.
- A 'product' surface can be constructed over an organically grown set of capabilities.
- 'Internal customers' have latent needs that must be validated rather than assumed.
Inferences:
- The same failure mode — project delivery breaking at multi-tenant scale — applies to any shared internal capability, not only infrastructure platforms.
- If adoption is the success metric, the platform team must be prepared to deprecate and sunset unused capabilities; yet no retirement mechanism is described, leaving the 'accumulated capabilities' problem structurally unresolved.
- The hardest part of the shift is a funding and governance change, not a technical one — but the article treats the technical evolution as the visible substance.
Product thinking is a better operating frame for platform teams than Scrum. strength: low
Explicit premises:
- Scrum's structure often failed to capture real outcomes or create the right environment for teams (Tonnies).
- Product thinking aligns engineering work, user value, and team experience.
Implicit premises:
- Outcomes and team environment are the right things to optimize.
- Scrum and product thinking are alternatives at the same level of the stack.
Inferences:
- If the two operate at different levels, adopting product thinking need not mean abandoning Scrum — the opposition may be a category error rather than a real trade-off.
Narratives
- A platform originally built to support a single Game Streaming product grew organically to serve many internal teams with different needs, at which point the project model broke.
→ The anchoring case that grounds the entire argument — the concrete inflection point from single-tenant to multi-tenant. - The stack evolved from Helm deployments, namespace-scoped resources, and a GitLab-driven IDP within shared clusters toward AWS-backed self-service, multi-tenancy, and higher-level abstractions; teams grew 'accustomed to self-service infrastructure' from public cloud.
→ Shows public-cloud UX as the external benchmark that reset internal expectations and pulled the platform toward the product model. - Early peers introduced systems and product thinking (Prometheus/Grafana ecosystems); the team engaged with Project to Product and The Phoenix Project, recognized their own pain points, and formed a community of practice among architects and senior engineers to debate alternatives.
→ An intellectual-lineage and change-adoption narrative — the shift arrived via books and peer debate, not top-down mandate (relevant to how ideas actually propagate through an organization). - 'Signals we could no longer ignore': growing backlogs, teams working around the platform, and an inability to say whether capabilities were used or even part of the offering.
→ The diagnostic anecdote that justifies abandoning output metrics for adoption metrics.
Questions addressed
- ✅ Why does the project model stop working once a platform serves multiple teams?
Because the platform becomes a shared, evolving system whose coherence and usability matter more than discrete delivery; project delivery produces incoherent one-offs and provides no user-validation feedback. - ✅ What does running a platform as a product mean concretely?
Behave like an internal cloud provider: self-service, API-driven, multi-tenant, with tenancy boundaries, contracts between planes, hypothesis-driven roadmaps, and adoption/usability metrics. - ✅ What inspired the shift?
Systems and product thinking, Project to Product and The Phoenix Project, a community of practice, public-cloud self-service expectations, and skepticism toward Scrum. - ⭕ How is the transition funded and governed when moving from milestone-budgeted projects to open-ended product work?
Not addressed — the funding/authority change, arguably the hardest organizational shift, is never named. - ⭕ How do you measure 'adoption', and what happens to capabilities that show low adoption?
Not addressed — no measurement mechanism and no deprecation/sunset path, leaving the 'accumulated capabilities' problem unresolved. - ⭕ Does the 'internal customer' analogy hold when internal teams cannot choose an alternative platform?
Not addressed — the captive-customer asymmetry (no exit) is ignored, though it undermines adoption as an honest success signal.
Gaps
- incompleteNo outcome evidence. The piece asserts the product approach is better but supplies zero before/after data — no reduced backlog, no adoption numbers, no user-satisfaction or lead-time improvement. It persuades by resonance with the reader's own pain, not by measured result.
Read next: Mik Kersten, 'Project to Product' (value-stream flow metrics); DORA / SPACE for platform outcome measurement; Evan Bottcher, 'What I Talk About When I Talk About Platforms' (Thoughtworks) for how to evidence platform value. - incompleteThe funding and governance shift is invisible. Moving from project budgets (predictable, milestone-scoped, one-time) to ongoing product funding — and granting the platform team authority to prioritize by aggregate value and to say no — is the real organizational cost of product thinking, and the article never names it.
Read next: Mik Kersten, 'Project to Product' (funding argument); Sriram Narayan, 'Products Over Projects' (martinfowler.com); John Cutler on product operating models and how funding shapes behavior. - incompleteThe piece fuses the mindset shift with one specific cloud-provider architecture (self-service, CRDs, service/control/management planes). It leaves unresolved whether that architecture is a precondition of product thinking, a consequence of it, or merely this team's instance — a lighter platform could adopt product thinking without it.
Read next: Skelton & Pais, 'Team Topologies' (platform-as-product and the 'thinnest viable platform'); John Cutler on separating operating model from tooling. - incompleteThe 'internal customer' analogy is imported without its main caveat: internal customers usually cannot exit or choose an alternative, so adoption can be produced by mandate rather than genuine demand — making adoption a gameable success metric. The captive-customer problem is never addressed.
Read next: Marty Cagan, 'Empowered' / 'Inspired' (do product principles hold for captive internal users?); John Cutler on internal platforms and 'build vs. mandate' dynamics. - incompleteNo deprecation or sunsetting mechanism. The founding complaint is 'accumulated capabilities competing in priority', yet the product model as described adds new abstractions without any account of retiring unused ones — the accumulation problem is diagnosed but structurally left unsolved.
Read next: Kent Beck on removing/simplifying (Tidy First? — subtraction as design work); lifecycle/deprecation practices in platform engineering (e.g., Team Topologies on platform evolution).
Related documents
- AI Is Changing Software Engineering. The Fundamentals Still Matter.
- Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers
- Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project
- Three more static code analysis sensors
- The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices
- How to Build a Superteam That Keeps Getting Better
- John Cutler's Post
- Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability
- Netflix Details Its In-House LLM Serving Platform with Triton and vLLM
- How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery