How to Build a Data Strategy That Actually Gets Used
The board asks for a data strategy. Someone produces a 40 page document with a maturity model, a target architecture and a three year roadmap. Eighteen months later nothing has been built, and the…
The board asks for a data strategy. Someone produces a 40 page document with a maturity model, a target architecture and a three year roadmap. Eighteen months later nothing has been built, and the company still argues about how many customers it has.
Here is what nobody tells you about data strategy. The document is not the strategy. A strategy is a small set of decisions about what you will measure, who owns it, and what you will deliberately not do. Most of what gets written is inventory, not decisions.
This guide covers how to build a data strategy that survives contact with reality, the five decisions that actually matter, and why most of these projects stall. Where the standard advice is wrong, this says so plainly.
What is a data strategy, really?
A short set of choices. Which questions the business needs answered, which data those answers require, who owns each definition, where the data lives, and what you are choosing not to measure yet. Everything else is implementation detail.
The last item is the one people omit. A strategy without exclusions is a wish list, and wish lists never survive a budget conversation.
Why do most data strategies stall?
Because they start with technology instead of questions. Choosing a warehouse before agreeing what a customer is guarantees an expensive system that produces numbers people still argue about.
This is my central argument and it applies at every company size. The genuinely hard problems in data work are organisational. Two teams define active user differently because they are measured on different things, and no amount of engineering resolves a disagreement about incentives.
If you cannot get three people to agree on one definition in a meeting, buying a platform will not help. It will simply make the disagreement faster and more expensive.
What are the five decisions worth making?
Which decisions need data, which metrics inform them, who owns each definition, where data is stored, and what you are postponing. Write those five on one page and you have a real strategy.
- Decisions first. Name the actual choices the business makes repeatedly.
- Metrics second. Only the ones that change a decision. Everything else is trivia.
- Ownership third. One named person per definition, not a committee.
- Storage fourth. A spreadsheet is a legitimate answer at small scale.
- Exclusions fifth. Written down, so nobody relitigates them quarterly.
Ownership is where these documents usually go soft. Data governance stops being abstract the moment one named person is accountable for what active customer means and can settle a dispute in a single message.
How much tooling do you actually need?
Far less than the market implies. Under a few million rows, a well structured spreadsheet or a small database answers nearly every question a growing company asks. Warehouses earn their place when volume or complexity genuinely breaks that.
The transformation layer is where trust is built, whatever your scale. dbt popularised defining business logic in version-controlled SQL, and its documentation teaches a discipline worth adopting even if you never install it.
We go deeper on the practical side of joining systems together in our guide to managing multiple data sources. Strategy decides what to measure. That covers how to actually assemble it.
What about governance and privacy?
Decide retention and access before you start collecting, not after. Data you hold indefinitely is a liability that grows quietly, and deleting it later is far harder than never collecting it.
If you handle personal data in the UK or EU, the regulator publishes genuinely readable guidance for organisations covering lawful basis, retention and access requests. An hour reading it early prevents expensive rework.
Collect less. It is cheaper, safer, and it makes every subsequent question easier to answer.
How do you write one in a week?
Interview the people who make recurring decisions, write down what they wish they knew, pick the three most valuable gaps, and commit to closing those. Publish one page, not forty.
- List the decisions your business makes every month.
- Ask each decision owner what they wish they knew beforehand.
- Pick the three gaps with the clearest financial consequence.
- Define the metrics that close them, in writing, with owners.
- State plainly what you are not doing this year.
- Review it in six months and delete anything nobody used.
Step five gives the document its power. A strategy that says no to something is a strategy. A strategy that says yes to everything is a budget request wearing better clothes.
What mistakes do companies repeat most?
The biggest mistake is hiring a data team before defining a single metric. They arrive, find no agreement about anything, and spend their first two quarters mediating instead of building.
- Buying a warehouse before agreeing what a customer is
- Writing a maturity model instead of making decisions
- Assigning definitions to a committee, so nobody can settle a dispute
- Collecting personal data with no retention policy
- Treating pipelines as finished, when they need genuine ongoing maintenance as source APIs change
Pipelines rot quietly. A sync fails on a Tuesday, nobody notices, and a trusted dashboard becomes confidently wrong. Someone must own that, or the whole strategy decays.
Where should you start?
Go back to that 40 page document and the argument about customer counts. The document was not too short. It answered the wrong question, in enormous detail.
Pick the one number your leadership team argues about most and define it this week, with a named owner. That is how you build a data strategy that actually gets used, one settled disagreement at a time.
My prediction is that storage keeps getting cheaper and definitions stay the bottleneck, which is why the organisations that win here are the ones that treat it as a governance problem rather than an engineering one.
Which single number would your leadership team define differently if asked separately today? Talk to our team about building the reporting once those definitions are agreed, which is usually custom development work.
Related reading
- Affordable Analytics Software for Small Companies
- Role of AI in Predictive Data Models
- Data Visualization Best Practices for Beginners
- Custom Dashboards for Business Intelligence
- Best Tools for Social Media Data Analytics
- Case study: Quanta ops dashboard
- Free tool: Website Maintenance Cost Calculator
Frequently asked questions
What actually belongs in a data strategy?
Five decisions. Which business decisions need data, which metrics inform them, who owns each definition, where data lives, and what you are deliberately not measuring yet. One page, not forty.
Why do most data strategies stall?
Because they start with technology instead of questions. Choosing a warehouse before agreeing what a customer is guarantees an expensive system producing numbers people still argue about.
Who should own a metric definition?
One named person, never a committee. Governance stops being abstract the moment someone is accountable for what active customer means and can settle a dispute in a single message.
Do we need a data warehouse to have a strategy?
No. Under a few million rows, a well structured spreadsheet or small database answers nearly every question a growing company asks. A spreadsheet is a legitimate architectural answer at small scale.
When should we hire a data team?
After defining at least a few metrics. Hire first and they spend two quarters mediating definitional disputes instead of building, which is an expensive way to run a mediation service.
What should the strategy say no to?
Something specific and written down, so nobody relitigates it quarterly. A strategy that says yes to everything is a budget request wearing better clothes.
Need a hand shipping this?
Our team builds high-traffic platforms for fintech, commerce and SaaS.
