The Product-Led Data Platform

Move over data as a product, it's time to build a product focused data platform to drive your success.

TLDR

Most enterprise data platforms are built like traditional infrastructure: costly, slow, and delivering value too late.

A better approach is to treat data platforms as products.

By identifying high-value domains, building thin end-to-end slices, and releasing data services incrementally, organisations can unlock value in weeks rather than years.

Introduction

You’ve probably heard expressions like “single source of truth”, “enterprise data model”, “foundation phase”, or “three-year transformation programme”. They usually come with large budgets, slow delivery, and teams waiting years to see any value.

If this sounds familiar, this article may offer a fresh perspective to help your organisation apply product principles and agile thinking to quickly drive data value.

I first worked on data products when running analytics for a startup telecoms company in Cambridge in the late 1990s. The business’s needs drove the architecture, not the other way around. We had visibility of live systems and access to 24 hours of queryable operational data. At the time, this was unusual.

Ten years later, I rebuilt a similar capability at American Express, combining live transactions with management information.

All of this is to say that, in my experience, it is highly likely that the systems that are the source of your data are rarely what you need now, and when you get what you need, it’ll be too late.

The real issue is not that your company lacks a data platform, but that most are built as infrastructure projects rather than products.

What does this do to your organisation?

In developing new AI products for clients over the past two years, I’ve repeatedly encountered issues with their data, both customer interaction and product data, that forced us to work around their limitations. The problem usually isn’t a lack of data, but rather inaccessible formats in unavailable systems or data only in employees’ heads, any of which takes time to extract.

Data’s importance is rising fast, yet most platforms and approaches are too slow to keep up. This gap puts your organisation at a disadvantage.

Understanding why organisations struggle with data requires looking at what’s changed.

To be honest, some of my colleagues and I got frustrated because we didn’t see why the status quo, getting slightly better, a bit late, should stand. Why should we wait for the data we need?

So we set about asking our data experts the hard questions. Questions about what an MVP data service might look like, what tools you might use, and what you could do without. What are the limitations and risks of doing this? What are the benefits and opportunities?

We took a minimal viable product (MVP) approach to build data capabilities, reviewing which tools allowed rapid iteration and which were limiting, just as we aim for a short, efficient CI/CD pipeline in app development.

What changed isn’t just technology. The real shift is applying product thinking to data platforms.

We decided to show, through practical action, how building a Product-Focused Data Platform can give our organisation a real competitive advantage.

With this product-led perspective in mind, how can you put it into practice?

I won’t reveal our specific solution, because your organisation may require different tools, and sharing details could compromise data security. Instead, I’ll outline the principles and steps you should consider.

1. Learn the language of data platforms

Data platforms have a unique vocabulary: Lambdas, Pipelines, heavy DevOps, and Gold, Silver, Bronze layers. Ingestions, services, event streams, APIs. Talk with your data teams, learn the terms, and stay up to date in this fast-changing field.

2. Create a simple operating model

Model how you’d ingest, process, and supply data, keeping the language accessible for all your colleagues. Visuals are often just complicated architecture diagrams, too complex, and seen as someone else’s expertise. All organisations rely on data, so make your model clear and accessible. Ironically, poor communication leads to lost battles over data.

3 - Take a step back

Proceed by considering which data matters to your organisation and why. You need the big picture. We talk about zooming out, going big, and thinking about what matters now and for the future. Think beyond how you do things today. At Amex, what really mattered was integrity. In a business built on reputation, customers expected us to have integrity. This meant transaction data and customer data were most important. What, one or two things, really matter in your organisation if you zoom out?

4- Domains

Now zoom in on your data domains. Understand how your big-picture view breaks into smaller components. Don’t be constrained by current operations; focus on what matters over the long term. For my team, customers—split by details, context, and behaviour tops our list.

To identify ours, we asked what core was, what mattered, and what was a commodity. This process helps you detail domains and anticipate what may change as your organisation evolves.

5 - Services

Now convert this knowledge into clear services. These are often APIs or Event Streams, depending on needs. APIs answer questions; Event Streams announce events. Choose what delivers the most value to your users. Simple services bundled together create real value. Plan upgrades and ensure most teams’ needs are met most of the time.

6 - Value

Next, identify where your data creates the most value. Since you likely have existing data flows, ask what gaps you can fill now to add value and get momentum.

Building a better way for your organisation to access data is key. We use a simple approach—evaluating value as Reach × Impact—but choose what works for you. Focus on surfacing high-value opportunities.

7. Deliver thin end-to-end slices

Slices in the data world are pieces that ingest, process and supply data to teams that use it to make a difference - value delivered.

To maximise value, build thin, functional slices that teams are going to use now. Once a slice works and delivers value, repeat with more and don’t forget others can use your previously created API’s. This approach accelerates results, uncovers problems early, and limits risk and management overhead.

8 - Build Just Enough

Organisations often try to build the “perfect” data platform before anyone uses it.

Instead, build something usable but minimal: a service that runs weekdays, handles non-critical data, and demonstrates value quickly.

Once teams depend on it, you can harden reliability and scale.

9 - But Stay ahead of the org

Keeping ahead requires both tactical and strategic actions.

Tactically, as more people use your API, it shifts from useful to indispensable. Ensure service quality keeps up, move from 9-5 support to 24x7, from downtime to high availability. The MVP approach grants incremental releases while earning and preserving trust by being ahead of the curve.

Strategically, you’ll want to look ahead to business changes and ensure your model accommodates them. Work closely with the board to get an early view, and your platform will continue to support the organisation rather than become a dead weight.

Building a Product-Led Data Platform is about mindset, not just technology.

Treat data services like products. Deliver value in slices. Stay close to leaders and the teams that use the data. By zeroing in on these takeaways, you can achieve results faster with greater impact and maintain this cadence.

Now it’s your turn to apply these principles and share your story.

I want to hear from you in the comments about your experience with data at your organisation. Can you get the data you need to deliver value, or are you held back? And if there are limitations, where do they come from? Lastly, what are you doing to turn this around and help create a Product-Led Data Platform now?