How to Build a Data Strategy for Better Decisions

Most documents that get called "the data strategy" turn out, on inspection, to be a tools shopping list with a vision slide on top. A new warehouse, a new BI tool, a new ELT pipeline, a new catalogue, sometimes an LLM gateway, all under a heading about "becoming data-driven". The document never quite answers the question that decides whether any of it produces value: which decisions does the organisation want to make better, and what would have to be true about its data for that to happen.

The result is a recurring pattern. The tools get bought. The dashboards get built. Reporting volume goes up. The actual business decisions, the ones that move revenue, cost, risk or mission outcomes, get made the same way they always were, on the same instincts and the same partial information. A real data strategy starts further back: with the decisions the organisation is trying to make better, and works forward to the data, the systems and the capabilities that would make those decisions sharper.

This article is the leadership version of that conversation. It pairs with the database architecture symptoms article, which catalogues the engineering signals that a data layer needs attention; here, the focus is the strategic layer above them, where the decision the organisation needs to make first is what the data is for.

Five questions, answered in writing and at the right level of seniority, are what separate a strategy from a tools shortlist.

The first is which decisions are we trying to make better, and how often. A data strategy that cannot list the decisions on a single page is not yet a strategy. Pricing decisions made monthly. Capacity decisions made quarterly. Programme allocation decisions made annually. Customer segmentation decisions that drive marketing spend. Each one has a cadence, an owner, and a definition of "better" that the data is supposed to support. Without that list, every dashboard is plausible and none of them are essential.

The second is what would have to be true about the data for those decisions to be sharper. Sometimes the answer is "we have it but cannot trust it". Sometimes it is "we have parts of it scattered across five systems". Sometimes it is "we do not collect it at all". The honest answer is rarely "we have a tooling problem"; it is usually a sourcing, ownership or definition problem.

The third is who owns each dataset, end to end. Not "the data team", but a named function or person who is accountable for the dataset's accuracy, freshness, definitions and access. Most "the data is wrong" complaints are really "the data has no owner" complaints.

The fourth is what we are deliberately not investing in. The strategy that says yes to everything is a wishlist. A real strategy names the data domains that will not get attention this year, the dashboards that will not be built, the integrations that will not happen, so the work that does happen has the capacity it needs.

The fifth is how we will know it worked. Better decisions are hard to measure directly, but the leading indicators are not. How quickly does a leader get the answer to a recurring question. How often does a decision get postponed because the data is not ready. How frequently are the same numbers requested through email instead of pulled from a dashboard. These are the metrics that say whether the data strategy is doing its job.

The most common mistake at the leadership level is to commission dashboards before the decision they support has been named. The reverse order is the one that works.

For each decision the strategy lists, three artefacts close the loop. The decision itself, written in one or two sentences, owned by a named role, with a cadence (monthly, quarterly, on demand). The input the decision needs, written as the smallest possible set of numbers or signals that would actually change the decision. And the delivery surface, which can be a dashboard, an automated alert, an email digest, or a five-minute meeting agenda item; the right surface depends on the decision and the cadence, not on the tool's defaults.

This sequence catches the dashboards that look impressive and never get used. If no decision changes when the number on the dashboard changes, the dashboard is decoration. The fix is rarely a better dashboard; it is to step back and find the actual decision the team thought it was supporting, or to retire the dashboard.

A data strategy that does not name a system of record for each important fact is not yet enforceable. "Customer count" comes from somewhere. "Revenue this quarter" comes from somewhere. "Active users last week" comes from somewhere. When the answer is "depends who you ask", the organisation has a governance problem, not a tooling problem.

Useful governance at the leadership level is narrow and concrete. For each business-critical metric, name the source system, the owner, the definition (active means what, exactly), the refresh cadence, and the path that copies of the metric take through the rest of the stack. Two metrics with the same name and different definitions in different dashboards is the most common cause of leadership distrust in data, and it is a definitions problem that no warehouse will fix.

The other half is access. Who can read a dataset, who can change its definition, who can publish a derived dashboard, and what review process applies. Loose access produces five conflicting versions of the same answer. Strict access produces a queue at the data team. The right setting is in between, and it is a leadership decision, not a technical one.

A data strategy that ignores the capability the organisation actually has is a wishlist. Three honest questions tend to surface the gap.

What roles does the team need that it does not have today, and which of those should be hired, contracted or trained. Most organisations over-hire dashboard builders and under-invest in the analytics-engineer role that bridges between the source systems and the surface where decisions get made.

What tooling does the organisation buy versus build. The default of buying everything has hidden costs (vendor lock-in, integration tax, data leaving the organisation in unexpected directions); the default of building everything has different hidden costs (multi-year roadmap, scarce engineering capacity, the team becoming a tools team). The right answer is rarely all-in on either.

What does the organisation operate today, and what is it willing to operate tomorrow. A strategy that depends on a self-hosted warehouse, a self-hosted catalogue, a self-hosted BI tool and a self-hosted reverse-ETL is committing to operating four products. Most organisations cannot, and should be honest about that at the strategy stage rather than at the incident stage.

A surprising number of data strategies treat reporting and analytics as the same activity. They are not, and conflating them is how organisations end up with a BI tool that is bad at both.

Reporting answers known questions on a known cadence. The weekly sales report. The monthly executive scorecard. The regulator's quarterly file. The audience is large, the questions are stable, and the reliability bar is high. The right tool for reporting is one that ships consistent, refreshed-on-schedule outputs to the people who need them, with as little custom analyst time as possible per cycle.

Analytics answers new questions. Why did revenue dip in this segment last month. What changed about the funnel after the redesign. Which customer behaviours predict churn. The audience is small (one or a few investigators), the questions are not stable, and the value comes from the speed of getting from question to credible answer. The right tool for analytics is one that supports exploration: ad hoc SQL, notebooks, fast iteration over the warehouse.

A strategy that names both jobs separately, with separate tooling and separate ownership, produces fewer compromises than one that asks the same tool to do both badly.

A data strategy is not a list of tools, a vision deck, or a warehouse migration. It is the document that decides which decisions the organisation is trying to make better, what would have to be true about the data for that to happen, who owns each piece, and what the organisation is deliberately not investing in this year. The organisations that get measurable value from their data are not the ones with the most dashboards; they are the ones whose strategy is specific enough that someone could disagree with it, and whose engineering and governance are sized to actually deliver it.

The wider context, including the engineering and operational decisions that turn a data strategy into something that runs in production, is collected in the data systems and performance insights cluster. And when the question moves from "we should have a data strategy" to "we have one and we now need someone to design the dashboards, the analytics workflows and the governance that bring it to life", that is exactly what my data analysis and decision-support practice is built around.