Data Platform as a Product

What it is

A cloud-native foundation's white paper describes the idea: a platform exists to serve its users' requirements and should be designed and evolved like a software product. A research programme on software delivery describes a platform as best understood as an internal product designed for developers, not a collection of infrastructure tickets.

Most of what has been written concerns software platforms. The data-specific case is made by the originator of data mesh, who notes that the skills needed to provision the infrastructure are specialised and difficult to replicate in each domain. Applying the wider findings to data platforms is DII's inference.

Why it matters

Platforms imposed by mandate meet resistance. DORA's 2024 research found internal platforms raised productivity but lowered delivery throughput and stability, so the platform has to be run for its users.

As reported in the trade press, users of internal developer platforms had 8% higher individual productivity and 10% higher team performance, while throughput and change stability fell by 8% and 14%. The results are mixed, and DII read them through that report, not the research itself.

The problem it addresses

DII editorial view

A platform team measured by tickets closed builds what it is asked for, not what its users need, and teams work around it. Treating the platform as a product changes the measure of success to whether people choose to use it.

Business and organisational relevance

DII editorial view

The change is in how the platform team is held to account: by whether people choose to use the platform and what they say about it, not by tickets closed.

Practical use cases

• A platform team with a product owner and a published roadmap
• Self-service provisioning in place of request queues
• Measuring platform adoption and user satisfaction

Benefits and opportunities

• A platform shaped by the people who use it
• Specialist infrastructure skills provided once, not repeated in every team

Risks, limitations and dependencies

• The white paper's own warning: teams relying on top-down mandates for adoption are almost certain to find resistance and resentment
• Measured results for internal platforms are mixed
• No adoption evidence specific to data platforms has been read

Prerequisites for adoption

DII editorial view

• A product owner for the platform
• A defined set of users and a way to hear from them
• Self-service provisioning, or a plan to reach it

Implementation considerations

• Give it a product owner. Someone must decide what the platform offers and to whom.
• Publish what it offers. Users cannot choose a platform whose services they cannot see.
• Measure adoption and satisfaction. These, not tickets closed, show whether the platform is working.

The DII Radar assessment

Approved DII Radar assessment

DII assesses Data Platform as a Product as Moderate relevance, with direction Stable. Its strategic impact is assessed as Moderate and its enterprise adoption as Emerging. It is in the catalogue and is not one of the ten entries on the current Radar.

DII relevance is our assessment of current significance and momentum, based on evidence, market development and adoption. Direction is the observed trajectory of relevance and adoption. Strategic impact is the potential or current significance to enterprise data capability, and enterprise adoption is the extent of current real-world enterprise adoption; together they set the position on the Radar. The Radar is not a prediction, vendor comparison or performance ranking.

Evidence basis: CNCF Platforms White Paper; DORA platform engineering capability (2026); DORA 2024 findings as reported by TechTarget (7 November 2024); Dehghani, Data Mesh Principles (2020).

What to consider next

DII editorial view

• Give the platform a product owner
• Publish what it offers
• Measure adoption and user satisfaction