There was a moment at Data Decoded London 2026 that did not feel like a new idea being introduced, but rather like something important finally being articulated clearly. Darren Wood from the BBC delivered a simple but powerful message, that organisations need to stop treating data teams as factories and start treating data as a product. It is a shift in language, but more importantly, it is a shift in mindset, and one that many organisations have not yet fully made.
At White Rabbit Foundry, this is something we have been working towards for some time. The idea that data should be designed, owned, and evolved in the same way as any other product is not new to us, but hearing it formalised in this way reinforced just how necessary the shift has become. Because in most organisations today, data teams are still not structured around value. They are structured around delivery.
The distinction matters more than it seems.
The Quiet Evolution into a Data Factory
Most data functions do not start out as factories. They become them gradually, almost without anyone noticing. A team is initially formed to support reporting or analytics, often with a clear purpose and a manageable scope. Early dashboards are built, stakeholders begin to rely on them, and requests naturally increase as more parts of the business see the potential value.
Over time, the volume of requests grows faster than the capacity to step back and rethink the approach. Delivery becomes the priority. Teams begin to optimise for responsiveness, measuring success by how quickly they can turn around a report or build a dashboard. Each individual request feels justified, and often urgent, but collectively they shape a system that is focused on output rather than impact.
This is how data teams quietly become factories. Work flows in, outputs flow out, and the system keeps moving. From the outside, it looks productive. Dashboards are being delivered, metrics are being tracked, and the backlog is being managed. But underneath that activity, a more important question is often left unasked. What is all of this actually changing?
As Avinash Kaushik once observed, many organisations are “data rich and information poor.” The problem is not access to data, but the ability to turn it into something meaningful. When data teams operate as factories, that translation step is often where things begin to break down.
When More Data Stops Creating More Value
One of the most striking aspects of Darren’s talk was the simplicity of the questions he posed.
Where would you use this dashboard?
What do you want to learn from it?
What would you do differently if it changed?
These questions seem straightforward, but they reveal a deeper issue. Many dashboards exist without clear answers to them. They may be technically accurate, visually polished, and regularly updated, but they are not always connected to a decision that matters.
This is where scale becomes a problem rather than an advantage. It is increasingly common for organisations to have hundreds of dashboards, each created with good intentions, but not all of them actively used or clearly understood. Over time, this creates fragmentation. Different teams rely on different metrics, interpret results in different ways, and arrive at different conclusions. Instead of creating clarity, data begins to introduce ambiguity.
The cost of this is not always immediately visible, but it is significant. Gartner has estimated that poor data quality and ineffective use of analytics cost organisations millions each year, but the more subtle cost is the erosion of confidence. When teams no longer trust the numbers they are seeing, decision-making slows down. Conversations shift from action to validation, and progress becomes harder to sustain.
The Role of AI, and Its Limits
There is a growing expectation that AI will resolve many of these challenges, and in some respects, it already is. Tasks that once required significant time and effort can now be completed almost instantly. Data can be processed, analysed, and visualised at a scale that would have been difficult to imagine even a few years ago.
However, speed does not automatically translate into value. If the underlying model remains unchanged, if teams are still optimising for output rather than outcomes, then AI simply accelerates the existing problem. It allows organisations to produce more dashboards, more reports, and more insights, but does not guarantee that any of them are more useful.
This is why some organisations are already experiencing what could be described as “dashboard inflation.” As the cost of creating outputs decreases, the volume increases, but the signal does not necessarily improve. In fact, it often becomes harder to identify what actually matters.
AI exposes this tension rather than resolving it. It forces organisations to confront a more fundamental question, not how quickly they can produce data, but whether what they are producing is meaningful in the first place.
Reframing Data as a Product
Treating data like a product offers a different way forward. It shifts the focus from delivery to design, from output to usefulness. A product is not defined by the fact that it exists, but by the value it creates for its users. It is built with a purpose, shaped by feedback, and continuously improved over time.
When this mindset is applied to data, the conversation changes. Instead of starting with a request, teams start with a problem. Instead of building a dashboard because it has been asked for, they explore what decision needs to be supported and what information would actually change that decision.
This approach also introduces a more structured way of thinking about development. Data products are planned in advance, aligned with business cycles, and designed with a clear understanding of how they will be used. They are not static outputs, but evolving tools that adapt as the business changes.
Leading organisations have already begun to adopt this model. Companies like Netflix and Spotify have long treated their internal data platforms as products, complete with roadmaps, user feedback loops, and dedicated product management. The result is not just better access to data, but better use of it.
What Changes in Practice
The shift from factory to product has practical implications that go beyond theory. One of the most immediate changes is in how work is prioritised. In a factory model, prioritisation is often reactive, driven by urgency or visibility. In a product model, it becomes intentional, guided by value and aligned with broader business objectives.
This creates greater transparency, both within the data team and across the organisation. Stakeholders gain a clearer understanding of why certain initiatives are prioritised and how they contribute to overall outcomes. This, in turn, builds trust and reduces friction.
Another important change is in how solutions are designed. Data products are no longer built in isolation, but in collaboration with the people who will use them. This involvement is not just beneficial, it is essential. When stakeholders are part of the design process, the resulting solution is more likely to reflect real-world needs and fit naturally into existing workflows.
This is where adoption becomes organic. Instead of requiring training or enforcement, data products are used because they are genuinely helpful. They answer the right questions, at the right time, in a way that supports action.
A Practical Example
We have seen this approach deliver tangible results in our own work. One client came to us with a familiar situation. Their reporting landscape was extensive, but fragmented, with multiple tools and dashboards providing overlapping views of performance. Insights were often delivered after the fact, limiting their ability to influence outcomes.
Rather than adding another layer of reporting, we stepped back and focused on the decision-making process itself. By mapping the critical path, we identified where data could have the greatest impact and where it was currently falling short.
From there, we developed a set of focused data products. A discovery tool supported campaign planning by grounding decisions in real insight rather than assumption. A segmentation tool helped identify the most relevant audiences based on behaviour. A predictive reporting layer surfaced early signals, allowing teams to anticipate outcomes rather than react to them.
The result was not more data, but better alignment. Teams were able to move from retrospective analysis to proactive decision-making, and the role of data shifted from supporting activity to shaping it.
Structure and Discipline
Treating data like a product also requires changes in how teams are structured and how they operate. Product managers, data engineers, analysts, and delivery leads work together with shared ownership and clear accountability. Processes such as sprints, retrospectives, and regular feedback loops create a rhythm that supports continuous improvement.
This structure ensures that data products are not static, but evolve over time. Feedback is incorporated, priorities are reassessed, and solutions are refined. The focus remains on delivering value, rather than simply completing tasks.
A Final Reflection
The conversation around data is evolving. Organisations are beginning to recognise that the challenge is not the lack of data, but the way it is used. Producing more dashboards will not solve this. Automating more reports will not solve this.
The shift that matters is deeper.
It is about moving from activity to intent, from output to outcomes, and from delivery to design. It is about recognising that data, like any other product, needs to be built with purpose, shaped by users, and measured by the value it creates.
AI will continue to expand what is possible, but the organisations that benefit most will not be the ones that move fastest. They will be the ones that are most deliberate in how they use what they build.
Because in the end, the question is not how much data you can produce. It is whether that data helps you decide what to do next.
And that is where the real advantage lies.
Couldn’t agree more. It was a fantastic session and a brilliant article.