There's a quiet distinction that separates the data platforms people love from the ones people route around, and it isn't the technology. It's whether the platform is treated as plumbing or as a product. Plumbing gets built, connected, and then maintained reactively — you touch it when it breaks, and otherwise ignore it, and the people who depend on it are an afterthought because plumbing doesn't have customers, it just has pipes. A product is different. A product has users whose needs you actively study, a roadmap shaped by what they're trying to achieve, a duty to be reliable and pleasant enough that people want to use it, and a team that measures its success by whether those users succeed. Leading a data platform team has convinced me that this mindset shift — from plumbing to product — is one of the highest-leverage changes an organisation can make to how it does data, and it costs nothing but a change in how you think about the job.
What changes when it's a product
The moment you decide your data platform is a product, a cascade of better questions follows, because products are accountable to their users in ways plumbing never is.
- You start with the users, not the tech. A plumbing mindset asks "what should we build?" A product mindset asks "who uses this, and what are they trying to achieve?" The analysts, data scientists, and report-builders who depend on your platform become customers whose needs drive the roadmap — not tickets to be closed, but people to be served. That single reframe changes what you build and the order you build it in.
- Usability becomes a real goal. Plumbing only has to work. A product has to be good to use — discoverable, documented, pleasant enough that people reach for it rather than around it. This matters enormously, because a platform people find painful is a platform they'll quietly bypass, standing up their own shadow solutions and fragmenting your data all over again. Every act of shadow IT is a review of your platform's usability, and it's usually a bad one.
- You get a roadmap, not a backlog of breakages. Products are built deliberately toward a vision. A product mindset makes you plan where the platform is going and prioritise accordingly, instead of lurching from one reactive fix to the next and calling the absence of fires a strategy.
- You measure success by user outcomes. Not "is the platform up," but "are the people who depend on it actually succeeding" — shipping their analyses, trusting their data, moving faster because of you. That's the metric a product team lives by, and it's a far better compass than uptime alone.
The self-service question, honestly
A product mindset changes how you think about self-service, which is where a lot of platform ambition lives and dies. The plumbing instinct is to lock everything down so nothing breaks. The product instinct is to ask how you enable your users to do more themselves, safely — to give them paved paths that make the right thing easy and the dangerous thing hard. A good data platform, like a good product, empowers its users rather than gatekeeping them, while providing the guardrails that keep that freedom from turning into chaos. That balance — enabling without abandoning — is exactly the kind of design problem product thinking is built to handle and plumbing thinking never even asks.
What it looks like in practice
Concretely, treating the platform as a product changed small things on my team that added up to a big one. We started actually talking to our users — sitting with an analyst to watch where they got stuck, instead of assuming we knew. We wrote a short, honest "here's how to get started" guide aimed at a newcomer's first day, not a reference manual for people who already knew. We published what we were working on next, so people could see the platform had a direction and tell us if we'd got the priorities wrong. And we treated a team quietly building their own shadow pipeline not as rule-breakers to be scolded but as a bug report about our platform — because that's exactly what it was. None of that is technology. All of it is the difference between a platform people endure and one they adopt.
The cultural shift, and the counter-view
This connects directly to something I learned leading a data platform team from its early months: the technical work is necessary but never sufficient. A platform team that thinks of itself as a product team behaves differently — it talks to its users constantly, cares how the platform feels to work with, communicates its roadmap, and takes responsibility for adoption rather than just delivery. It stops saying "we built it, they should use it" and starts asking "why aren't they using it, and what would make them want to?" That's a healthier, more honest relationship with the people you serve, and it produces platforms people actually adopt.
The fair counter-view: product thinking can tip into over-polishing, gold-plating the experience while the fundamentals wobble, or chasing user requests so eagerly you lose the coherent architecture underneath. A data platform still has to be right — secure, governed, sound — and "the users wanted it" is not a licence to compromise the foundations. So hold both: the rigour of good engineering and the empathy of good product management. But if I had to pick the more common failure, it's overwhelmingly the plumbing mindset — platforms built and forgotten, technically fine and quietly unloved, bypassed by the very people they were meant to serve. Treat yours as a product with users worth delighting, and you'll build something people choose. Treat it as pipes, and you'll build something people escape.