Running a Data Platform as a Product: Team, Service Model and Funding
A data platform delivered as a project is finished on the day it goes live and declines from then on. Run as a product, it has users whose needs are studied, a team that stays, a stated service and funding that continues. The change is organisational far more than it is technical.
A data platform delivered as a project has a characteristic afterlife. The project closes and its team is reassigned. A few engineers keep the platform running. Requests from analysts wait in a queue, and business units that tire of waiting buy tools of their own. The platform remains technically sound while fewer teams use it.
In that pattern the technology has not failed. The platform was built as a project, with an end date, and then left to be operated as infrastructure. This article argues for a different arrangement: treat the platform as a product with internal customers. It sets out what that means, the team it needs, the service it should define, how to fund it and how to tell whether it is working. It is a position, supported by published thinking from software platform engineering, and it gives no staffing ratios, because none that DII could verify apply across organisations. None of the sources cited was written about data platforms. Applying them to one is DII’s judgement, and no published account of running a data platform as a product was found and read.
What “as a product” means
The idea comes from software delivery, where internal platforms for developers met the same decline. The Cloud Native Computing Foundation’s white paper on platforms makes it the first attribute of a successful one: “Platform as a product. A platform exists to serve the requirements of its users and it should be designed and evolved based on those requirements, similar to any other software products”1.
Google’s DORA research programme describes the same shift in its guidance on platform engineering: “Rather than viewing the platform merely as a collection of infrastructure tickets, it is best understood as an internal product designed specifically for developers”2.
For a data platform, taking that seriously has consequences.
- It has users, and they have a choice. Analysts, data engineers, data scientists and application teams use the platform. If it does not serve them, they will find something else, as the business units in that pattern do.
- Its success is measured by their outcomes. A platform is doing well when the teams on it deliver faster and more reliably. Uptime alone does not show that.
- It is never finished. Needs change, and the platform changes with them, on a roadmap.
- Someone is accountable for it as a whole. One person decides what it will and will not offer.
The white paper is blunt about the alternative. Platform teams that release features without feedback, or “that rely on top-down mandates to achieve adoption are almost certain to find resistance and resentment from their users”1. A mandate to use the platform is a sign that it is not yet good enough to be chosen.
The team
A product needs a team that persists. Team Topologies, a published model of software team organisation, defines the type: a platform team provides “a compelling internal product to accelerate delivery by Stream-aligned teams”3. The stream-aligned teams, in this setting, are the analytics and data teams that build data products for the business. The platform team’s purpose is to make them faster.
The responsibilities below have to be covered. In a small organisation one person may hold several.
Product management. Someone who talks to users, understands what slows them down, decides priorities and maintains the roadmap. Without this role a platform drifts from what its users need. The white paper recommends that “platform teams should include product managers from the start”1.
Engineering. The people who build and evolve the platform’s capabilities: ingestion frameworks, environments, deployment automation, access patterns.
Operations and reliability. Keeping the platform running, responding when it fails and learning from failures. The practices are those described in handling data incidents.
Enablement. Documentation, onboarding, examples and help. A capability nobody knows how to use has not been delivered.
The boundary of the team’s responsibility must be stated. The platform team is accountable for the platform: that the engine runs, that the tools work, that the paved route is sound. The teams that use it are accountable for what they build: their pipelines, their models, their data products. Without that line the platform team becomes the support desk for every query that returns the wrong number.
This is the arrangement that decentralised designs assume. The self-serve platform is one of the foundations of the approach discussed in data mesh vs data fabric, and it is equally useful to organisations that adopt no such design.
The service model
A product has a defined offer. For a platform, that means saying what users can expect, in terms they can rely on. A service model has the parts described here.
A catalogue of what is offered. The capabilities available, and how to get each one. The capabilities described in what a modern data platform is give a structure. For each, the catalogue says what the platform provides and what remains with the user.
A way of obtaining it. The white paper is categorical: “A platform should be self-serviceable”1. Team Topologies names the relationship: in X-as-a-Service, one team provides and one team consumes something as a service3. The aim is that a user can get a new environment, access to a data set or a deployed pipeline without waiting for a person. Every routine request that requires a ticket is a candidate for automation.
Self-service works through paved routes: a supported, documented, default way of doing each common task, with security and standards built in. Users may leave the route. On it, they get speed and support. The white paper’s word for this quality is that a platform should be “Optional and composable”1.
Stated service levels. What availability the platform commits to, when data in shared layers will be ready, how quickly support responds and how incidents are communicated. A small number of commitments that are measured and reported builds more confidence than a long list that is not.
Project delivery and product operation compared
| Platform as a project | Platform as a product | |
|---|---|---|
| Ends | At go-live | When retired |
| Team | Assembled, then disbanded | Standing |
| Driven by | A specification agreed at the start | User needs, continuously studied |
| Access to capabilities | By request to the team | Self-service on paved routes |
| Success measure | Delivered on time and budget | Adoption and the outcomes of user teams |
| Funding | One-off capital, then minimal running cost | Continuing, tied to the service |
| Adoption | Mandated | Earned |
Funding
How a platform is paid for shapes how it behaves. Three models are available, and each has a characteristic weakness. The assessment is DII’s.
Central funding. The platform is paid for from a central budget and is free at the point of use. This is simple and encourages adoption. Its weakness is that users have no reason to economise, and the platform’s budget is set without reference to the demand placed on it.
Chargeback. Each team is billed for what it consumes. This aligns cost with use and gives teams a reason to be efficient. Its weaknesses are administrative overhead, disputes about allocation and a disincentive to adopt, since staying off the platform appears free.
A hybrid. The shared foundation, including the platform team and the core capabilities, is funded centrally, and variable consumption is attributed to the teams that cause it, by showback at first and by charge later if wanted. This keeps the incentive to adopt while making consumption visible.
DII regards the hybrid as the reasonable default, for a reason that the FinOps Foundation’s principles state well: “Everyone takes ownership for their technology usage”4. Teams can own only what they can see, so whichever model is chosen, each team should be shown what its use costs. The mechanics are set out in controlling data platform costs, and the Data Platform Cost / FinOps Tracker provides a structure for the attribution.
One funding point matters above the model. The platform team itself must be funded as a continuing cost. A platform whose engineers are paid for from project budgets will lose them when the projects end, which is the decline described at the start of this article.
Knowing whether it is working
A product is judged by evidence. The kinds worth collecting are below, and none needs elaborate tooling.
- Adoption. How many teams and workloads use the platform, and whether the number is growing by choice.
- Time to first value. How long it takes a new team to go from request to a working pipeline or report. This is the most telling single measure of self-service.
- Reliability against the stated service levels. Reported openly, including the misses.
- User feedback. Asked for regularly and acted on visibly. A short survey and a standing conversation with each major user team are enough.
Activity measures, such as tickets closed or features shipped, show effort and say little about value. A platform team that closes many tickets may be one whose users cannot serve themselves.
A practical first quarter
For a platform currently run as infrastructure, the move does not need a reorganisation. It can be started in a quarter by the steps below, which are DII’s suggestion.
- Name the product owner. One person accountable for what the platform offers.
- Find out who the users are and ask them. What takes longest? What do they work around?
- Write the catalogue. One page on what the platform offers today and how to get it. The gaps will be obvious.
- Pave one route. Choose the most frequent request and make it self-service.
- Publish two or three service levels and report on them.
New demands test the arrangement. AI workloads bring users with different needs from those of analysts, and a platform run as a product has a way to hear and prioritise them; the readiness questions are in is your data platform ready for AI workloads?.
At the end of that quarter the test is concrete. There should be a named owner, a one-page catalogue that users have seen, one request that no longer needs a ticket, and a first report against two or three service levels. If those four things exist, the platform is being run as a product in the sense that matters, whatever the organisation chart says. If they do not, the obstacle is worth naming honestly, and it is more likely to be funding or authority than technology.
Two decisions will then be waiting, and both belong to the sponsor and not to the platform team: whether the team is funded as a continuing cost, and whether adoption is to be earned or mandated. This article has argued for continuing funding and earned adoption. An organisation that chooses otherwise should do so knowingly.
DII publishes no public Resource for platform team design or service models. The tracker named above supports the funding and cost-attribution part of this article only.
Sources
- CNCF TAG App Delivery (Cloud Native Computing Foundation). CNCF Platforms White Paper.
- DORA (Google Cloud). Capabilities: Platform engineering. Updated 12 January 2026.
- Team Topologies (Skelton, M. and Pais, M.). Key Concepts (teamtopologies.com).
- FinOps Foundation. FinOps Principles.
This article is general professional information. It is not legal or regulatory advice.