There is a question that recurs in budget reviews, quarterly business meetings, and leadership offsites with remarkable consistency, and it comes from different people every time.

Sometimes it’s the CFO: „We’ve invested heavily in data infrastructure. Where’s the return?“ Sometimes it’s the Head of Marketing, who commissioned a customer analytics platform that the commercial team still isn’t using. Sometimes it’s the CTO, who built a reporting stack that IT maintains and nobody quite owns. Sometimes it’s Operations, who asked for better visibility six months ago and got a dashboard that doesn’t reflect how the team actually works.

The person asking changes. The question doesn’t.

Most organisations have built something: a data warehouse, a BI stack, an analytics layer, dashboards published on a schedule. The infrastructure exists. The reports go out. And yet when someone asks how data contributed to a specific decision, a revenue outcome, or a measurable improvement in how the business runs, the answer gets vague.

This happens regardless of whether there’s a Chief Data Officer in the building. Data programmes get owned by IT departments, marketing functions, operations leads, customer experience teams, and product organisations – often simultaneously, with no single owner of the outcome. A CDO, where one exists, provides dedicated leadership. But the absence of one doesn’t explain the gap. Plenty of companies with CDOs have the same problem, and plenty without them are further ahead.

The core issue is simpler and more structural: data gets treated as a capability to maintain rather than an asset to operationalise. Investment gets measured. Return doesn’t get designed for.

The organisations that consistently extract business value from data, regardless of who owns it internally, have figured out one thing: the value doesn’t live in the data. It lives in what the data enables someone to do differently.

This article covers what that shift actually requires – in strategy, governance, delivery, and measurement – and where most programmes stall before they get there, regardless of how they’re structured.

The utilisation gap: structural problem, not a technical one

A Seagate/IDC survey of 1,500 global enterprise leaders found that 68% of enterprise data goes unused. That figure is striking but not surprising to anyone who has worked inside a data programme. The issue isn’t that organisations lack data. It’s that most of what they collect never reaches a form that supports decisions.

The same research identifies the top barrier: making collected data usable. Not collecting it. Not storing it. Making it usable – packaged, contextualised, delivered in a format that matches how decisions actually happen. Storage and collection are largely solved problems. Usability is not.

This is a structural gap. You can address parts of it with better tooling, but tooling alone doesn’t close it. Closing it requires treating data as a product with defined consumers, quality standards, and delivery standards – not as infrastructure with undefined users and no accountability for adoption.

Harvard Business Review’s research on data strategy – developed by AIG CDO Leandro DalleMule and MIT/Babson professor Thomas Davenport – frames this as the distinction between data defence and data offence. Defence is governance, standardisation, quality control: the foundation that makes data trustworthy. Offence is using that trusted data to generate revenue, improve decisions, and build competitive advantage. Most organisations invest heavily in defence – pipelines, warehouses, governance policies – and then expect offence to follow automatically. It doesn’t. The transition requires a different set of decisions, not more infrastructure.

Where data value actually comes from

Data produces business value through three distinct mechanisms. Understanding which one you’re pursuing – and designing deliberately for it – is what separates programmes that return ROI from those that produce reports.

Operational efficiency. Data reduces the time and cost of decisions that repeat. Demand forecasting, resource allocation, supply chain optimisation, fraud detection – these share a structure: the same type of decision happens frequently, data can improve its quality or speed, and the cumulative impact is measurable. The value shows up as lower error rates, faster cycles, and reduced waste rather than a single identifiable revenue line. It’s also the fastest path to demonstrable ROI for organisations early in their data maturity, because the use cases are concrete and the counterfactual is easy to measure.

Customer and market intelligence. Data improves the precision of how an organisation serves and acquires customers. Churn prediction, pricing optimisation, personalisation, segmentation – these translate data into commercial leverage. The value is more directly attributable to revenue, but requires clean, consistently defined data and a delivery mechanism that puts insights in front of the people making commercial decisions – not just the analysts building the models. The bottleneck is almost never the analysis. It’s getting the output into the right workflow at the right time.

Data as a product. For a growing number of organisations, data becomes something that can be packaged and delivered to external buyers – customers, partners, or third-party markets. This path has the highest margin potential, but it requires all the foundations of the first two mechanisms plus a commercial layer: defined tiers, entitlements that are enforceable in the product itself, governance that meets external standards, and a delivery experience buyers will actually adopt. Organisations that try to launch external data products before their internal data is trustworthy and consistently governed almost always encounter this as a compliance or quality failure at the worst possible moment.

The sequence matters. Internal use cases aren’t a fallback, they’re the proving ground that builds the capabilities and credibility needed to take data products external.

The governance gap: why most data programmes stall at the foundation

A Harvard Business Review Analytic Services survey of 343 executives found that 60% believe their organisations are under-investing in their enterprise-wide data strategy. Eighty-seven percent said data governance is the most critical capability needed to achieve high-quality enterprise data. Fewer than half said their governance is actually working.

The pattern is consistent: governance gets recognised as foundational, under-funded in practice, and then encountered as a delivery problem downstream. Data silos, conflicting definitions between departments, numbers in reports that don’t match, compliance risk surfacing the moment someone tries to share data externally – these are governance failures that show up as analytical failures.

The deeper issue is how governance gets designed. In most organisations, it exists as a policy layer: rules about who can access what, definitions documented in a catalogue, standards that exist on paper but aren’t enforced at the point where data is consumed. That’s necessary but not sufficient.

Governance produces business value only when it’s operational – when the person accessing a report, exporting a dataset, or receiving data through an API is operating within enforced access controls, consistent definitions, and an auditable boundary. The difference between governance as policy and governance as operational reality is the difference between a compliance exercise and a foundation for scale.

Organisations that build governance into their delivery infrastructure from the start – rather than treating it as a layer to add later – are the ones that can grow data access without growing risk. That ability is what makes data democratisation sustainable rather than chaotic.

The operationalisation gap: from insights to decisions

The most common failure mode in data strategy isn’t bad data or bad analysis. It’s the gap between producing insights and operationalising them – getting the right output, in the right form, to the right person, at the point where a decision actually happens.

This gap is structural because analytics teams and business teams have different needs that rarely get explicitly reconciled. An analyst wants a flexible exploration environment. A business team leader wants a curated view of the three or four numbers that tell them whether they’re on track and what to do if they’re not. These are different products. Building one and expecting it to serve both audiences is how you end up with dashboards that get published and never opened.

Closing this gap requires treating delivery as a product discipline. That means defining the audience before building the output, designing the delivery format around how that audience actually works, enforcing access controls that reflect governance policy, and measuring adoption rather than just availability.

It also means recognising that the marginal cost of delivery matters. When every new team, customer, or use case requires a custom implementation, the „data programme“ is actually a services engagement that can’t scale. When delivery is repeatable – the same governance model, the same provisioning process, the same quality standards applied to each new audience – costs fall as deployment grows. That’s what separates a data project from a data business.

Strategy: sequencing offence and defence

The DalleMule and Davenport framework identifies a pattern that plays out predictably: organisations that try to pursue data offence without a functional defence foundation spend enormous energy cleaning up data quality failures, resolving conflicting definitions, and managing compliance risk that should have been architected out from the start.

The strategic implication is sequencing. Defence first: establish what data is trustworthy, define it consistently, govern access in a way that can be enforced at scale. Then offence: use that trusted foundation to generate decisions, revenue, and eventually products. The organisations that execute this well aren’t necessarily the ones with the largest data teams. They’re the ones that made governance operational before trying to monetise.

This matters especially for organisations without a dedicated data function – which is most of them. Deloitte’s research on data monetisation leadership makes the point directly: effective data leadership can sit with a CIO, a VP of Product, a Head of Marketing, or any commercially-minded executive who understands data as a value generator rather than a cost centre. The title matters less than the accountability structure – whether someone clearly owns the translation from data capability to business outcome, and whether governance and delivery infrastructure is being built with that translation in mind from day one.

Data as a product: what it actually requires in practice

„Data as a product“ has become a widely used phrase with a widely varying definition. In practice, it means applying product management discipline to data outputs: defining consumers, setting quality standards, measuring adoption, and iterating based on what’s actually being used rather than what’s been built.

This changes the accountability structure. When data is infrastructure, no one owns the consumer outcome – the pipeline team owns the pipeline, the analytics team owns the reports, and whether anyone uses them to make better decisions is nobody’s job. When data is a product, someone owns the consumer experience end to end.

Making data-as-a-product operational requires four things that most organisations treat as separate problems:

Defining what the product is. A report, a dashboard, an embedded analytics view, a data application, an API feed – the format determines who can use it, what the adoption path looks like, and how it gets packaged for different tiers of users or customers. This decision shapes everything downstream. (For a detailed framework on choosing between these formats, see Dataset, Report, or Data App: The Value Ladder.)

Defining who gets what. Role-based access, tenant isolation for multi-customer delivery, feature availability by tier, export controls – these are the commercial architecture of the product. If packaging isn’t enforced in the product itself, it isn’t packaging – it’s an aspiration in a spreadsheet.

Delivering it consistently at scale. The marginal cost of adding a new team, customer, or partner to a data product should fall over time, not stay constant. If every new deployment requires custom setup, the programme isn’t a product – it’s a project. Repeatability is the structural difference.

Measuring adoption against outcomes. Dashboards published is the wrong metric. Active users by tier, decisions influenced, actions taken, expansion signals – these tell you whether the data product is producing value or just producing reports.

Where Datalook fits: the delivery and operating layer

Most organisations don’t stall on data strategy because they lack a framework. They stall because the gap between designing a data strategy and operating one at scale is substantially larger than it looks.

Building governance infrastructure, delivery layers, tenant models, entitlement systems, and adoption measurement capability simultaneously – with a team already at capacity, against stakeholder timelines measured in quarters – is where most programmes collapse under their own weight.

Forrester’s research on insights-driven business maturity identifies that firms with advanced analytics capabilities are 2.8x more likely to report double-digit growth than those at the beginner stage. The gap between beginner and advanced isn’t primarily about analytical sophistication. It’s about whether insights are reliably reaching the people who act on them – and whether that delivery compounds in capability rather than in cost.

Datalook is built as the delivery and operating layer for data products – the infrastructure between your data stack and your users, whether those users are internal teams, external customers, or partners. It’s a full-service platform: infrastructure combined with the strategic and implementation work needed to actually launch and run a data product at scale.

In practice, four capabilities work together rather than as separate problems.

Governed delivery that scales. Role-based access, tenant isolation, and feature-level controls are the architectural foundation, not a bolt-on. Governance is enforced at the point of consumption – the only place it actually protects anything. Access can grow without risk, and entitlements are enforced in the product rather than managed manually.

Multiple delivery models in one operating layer. Portal delivery, embedded analytics inside existing applications, and custom data workflows coexist and are managed consistently. Different audiences need data in different forms. Rebuilding the delivery layer for each new use case is one of the primary sources of delivery friction – removing it is what makes marginal costs fall rather than stay constant.

Repeatable provisioning through Automated Flow Templates. When a new customer, team, or partner needs onboarding, Automated Flow Templates provision their complete analytics environment – ingestion, transformation, reports, permissions – without manual setup each time. Each deployment is consistent. Scaling from ten customers to a hundred doesn’t require ten times the implementation work.

Adoption measurement built in. Usage analytics, active users by tier, feature consumption, and expansion signals are visible in the platform. „Is our data programme producing value?“ moves from a subjective question to a measurable one – and gives commercial and product teams the signal they need to know where to push for expansion and where adoption is stalling.

This is what makes data value a controllable business capability rather than a series of one-off builds. Governance, delivery, packaging, and adoption measurement become a single operating layer rather than four separate problems assigned to four separate teams.

Measurement: the discipline most programmes skip

Organisations that consistently extract business value from data share one practice that struggling ones almost universally bypass: they define the measurement model before they build the product, not after.

The failing pattern is consistent: outputs get shipped, adoption is assumed, and the ROI story gets assembled retrospectively from whatever happened to be measurable. The succeeding pattern is the opposite: the value hypothesis is defined at the start – what decision improves, for whom, by how much – and the delivery is designed to make that outcome observable.

The metrics that matter are not the same as the easy metrics. Dashboards viewed is easy to count and tells you almost nothing about value. Decisions influenced, actions taken, time-to-decision reduced, cost avoided, revenue directly attributable – these are harder to capture but are the actual evidence that data is changing how the business operates.

This applies equally to internal programmes and external products. For internal: can we demonstrate that this analytics capability changed a specific operational outcome? For external: does usage predict renewal, expansion, or reduced churn? Those are the measurements that make data value legible to the business – and that give data programmes the credibility to earn the continued investment needed to scale.

The takeaway: data value is designed, not discovered

Data doesn’t produce business value by existing. It produces value when it’s operationalised – governed at the point of consumption, packaged in a form that matches how decisions actually happen, delivered consistently to the audiences who need it, and measured against outcomes rather than outputs.

The organisations pulling ahead aren’t necessarily the ones with the largest teams or the most sophisticated models. They’re the ones that have closed the operationalisation gap: trusted data, delivery that reaches decision-makers in a usable form, governance that scales without becoming a bottleneck, and measurement that proves impact.

That’s the foundational work. Less visible than launching an AI initiative or building a data lake. But it’s the work that determines whether everything else compounds – or just costs more.