A data platform is not a toolkit. It is a production system, and the difference between the two determines whether teams trust it.
The Shift
There was a moment, somewhere in the past two years, when I stopped thinking about the data platform as a collection of tools and started thinking about it as a product. The tools are the same - BigQuery, dbt, Dagster, Looker, Airbyte - but the mindset shift changed everything about how I prioritise, communicate, and operate.
When you think of it as a toolkit, you optimise for flexibility. You give people access to tools and let them figure it out. When you think of it as a product, you optimise for reliability, developer experience, and trust. You care about onboarding time. You care about error messages. You care about whether someone can ship a pipeline on their first day without asking five people for help.
What Platform Thinking Looks Like
Here is what changed in practice when I adopted this mindset:
CI/CD is not optional. If data engineers cannot test their changes before merging, they will break production. We invested heavily in building a CI/CD pipeline for dbt that mirrors what software engineers take for granted: pull request previews, automated tests, and deployment guardrails. The result was fewer incidents and faster iteration.
Observability is the product. A pipeline that runs but cannot tell you whether the data is correct is worse than a pipeline that fails loudly. We built monitoring that tracks not just whether pipelines complete, but whether the data they produce looks right - row counts, null rates, value distributions. When something is off, the system tells you before the stakeholder does.
Documentation is UX. I used to think documentation was a chore. Now I think of it as the user interface of the platform. If someone has to read code to understand a dataset, that is a UX failure. We started treating dataset descriptions, column documentation, and playbooks as first-class deliverables - not afterthoughts.
Cost is a feature. Running BigQuery queries is easy. Running them efficiently at scale is a discipline. We audited our cost profiles, identified the expensive patterns, and introduced guardrails - partition requirements, query cost limits, archival processes. The savings were meaningful, but more importantly, it built a culture of cost-awareness that compounds over time.
The People Dimension
Platform thinking is not just about technology. It is about how you relate to your stakeholders. When the data platform is a toolkit, the relationship is transactional: "Here are the tools, good luck." When it is a product, the relationship is collaborative: "What are you trying to achieve, and how can the platform help you get there faster?"
This shift matters because trust is earned through reliability. Every time a dashboard loads correctly, every time a pipeline delivers data on time, every time an analyst finds a well-documented dataset - that is a deposit in the trust bank. And trust is what gives you the licence to invest in foundational work that does not have an immediate visible payoff.
I have learned that the best way to justify platform investment is not through architecture diagrams or cost models. It is through a track record of reliability. When the platform just works, people believe you when you say the next investment will make it work even better.
Lessons From the MBA
My MBA at Melbourne Business School taught me to think about businesses as systems of value creation. A product has customers, a value proposition, a delivery mechanism, and a feedback loop. The data platform is no different. Its customers are the analysts, data scientists, and business stakeholders. Its value proposition is reliable, timely, and trustworthy data. Its delivery mechanism is the pipeline and semantic layer infrastructure. Its feedback loop is the incidents reported, the questions asked, and the time saved.
Thinking this way has been transformative. It grounds every technical decision in business impact. Should we invest in a data catalogue? Only if it reduces the time between question and answer. Should we migrate to a new orchestrator? Only if it improves reliability or developer experience. The technology serves the product, not the other way around.
The Aspiration
The ultimate goal of platform thinking is to become invisible. When the platform works so well that people forget it exists, that is success. Nobody praises the plumbing when the tap works. But everyone notices when it breaks.
That invisibility is hard to achieve and even harder to maintain. It requires constant investment, relentless prioritisation, and the discipline to say no to shiny things that do not serve the core mission. But the payoff is a team that moves fast, makes good decisions, and trusts the data they are making those decisions with.
And that, at the end of the day, is why we build platforms.