Defining and Designing a Data Strategy

• 85% of big data projects fail (Gartner's Nick Heudecker, 2017)
• 87% of data science projects never make it into production (VentureBeat, 2019)
• 80% of data and analytics governance initiatives will fail by 2027, for lack of a real or manufactured crisis (Gartner, 2024)
• 67% of AI projects never reach production (Spryfox, 2026)
• And Gartner now expects over 40% of agentic AI projects to be cancelled by the end of 2027

So we have the data. Why isn't it enough?

I've spent years working with organizations on exactly this question, and I keep arriving at a conclusion that sounds almost too simple. Most companies don't have a data problem. They have a data strategy problem. And those are not the same thing.

The six ways data efforts quietly fail

If you sit with teams long enough, the same patterns keep showing up. And none of them are really about the technology being "not good enough."

• There's poor data quality: three reports, three numbers, the same question, and nobody knows which one is right.
• There's technology for technology's sake: three BI tools, two data lakes, and people still rebuild the dashboards in PowerPoint anyway.
• There are skill gaps: "We want to bring in AI, but no one really knows how to approach it in a structured way."
• There are processes that sit far from practice: workflows that look great on a slide and never touch the actual day-to-day.
• There's no data-driven culture: the numbers that actually matter live in Excel files on someone's personal drive.
• And there's not enough governance: when a dataset is wrong, it takes days just to find out who produced it.

Notice what they have in common. Not one of them gets solved by buying another tool. They get solved by deciding something, on purpose, and having the nerve to leave other things out.

So what actually is a data strategy?

Here I lean on Richard Rumelt's book Good Strategy / Bad Strategy. His argument is that a strategy is the deliberate concentration of your resources on the point where they make the biggest difference. Translate that to data and you get three core pieces. Skip any one of them and you end up in the failure stats above.

• First, diagnosis. Where do we really stand?
• Second, a guiding policy. Where do we want to take our data, and what are we deliberately not going to do?
• Third, coherent action. How do we actually get there, and in what order?

A wish list of initiatives is not a strategy. A vision statement is not a strategy. These three things, done honestly and in sequence, are. Let me walk through each one.

Step 1: Diagnosis, or naming the real problem

A diagnosis is not an inventory list, and it's not a generic maturity model. It's an honest read of the situation that ends in a single sentence naming the core tension ("the crux"), plus the structural reason behind it. I usually look at three areas, and I find it helps to picture them as an iceberg with a waterline.

Above the waterline, where things are tangible, is business alignment. Who decides what, and with which data? How well is data actually woven into the business processes? Estimate the level of business alignment with use-case maps, stakeholder analyses, etc. Also tangible is data governance. The architecture, the tech landscape, ownership, data quality. Can you find your sources, document them, trust them, and say who owns them?

And then below the waterline, abstract but absolutely decisive, is data culture. The values, the routines, the lived practice of working with data. It's the hardest thing to measure and it touches everyone, from leadership down to the front line. You can't order a culture into existence by decree.

When you dive deep into those three areas, you will need to listen more than you talk. Choose formats like workshops, one-on-one interviews, usage surveys, and then ... do not produce a tidy report. The whole point of the diagnosis is to produce the crux - that one core tension you must solve with its structural reason behind. Here's what that sounds like in practice.

For a client who had created plenty of reports with heavy investments but little impact on the front line, we put it this way: "Our problem isn't the data sources. It's the gap between the dashboard and the decision." The root cause was that meetings discussed the numbers but never actually decided anything with them.

For a different case, a department was suffering from the responsibility for seven data sources, three parallel tooling initiatives, and no consolidated picture how data and tooling could be adopted company-wide: "We don't have a data-silo problem. We have an accountability vacuum that shows up as silos." The root cause there was that nobody formally owned a domain, so every department ended up maintaining its own version of the truth - based on its own data, tools and processes.

Once you can say the crux out loud, half the work is done. You've stopped counting symptoms and started naming the disease.

Step 2: Guiding policy, or why a strategy without trade-offs is just a vision

This is where most "data strategies" fall apart. They say things like "We're becoming data-driven" and "Every team needs a dashboard." Those aren't choices. They're aspirations everyone already agrees with. They cost nothing to say and they deliver nothing.

A real guiding policy is a deliberate decision about what comes first, and, just as explicitly, what you will not do. It answers the crux, it fits in one sentence, and it creates leverage. Take the two examples from before.

For the decision gap, the policy might be: "We treat decision routines as a data product, not as a reporting appendage." Not "we're becoming data-driven," not "every team needs a dashboard," not "modernize reporting by Q3."

For the accountability vacuum: "We invest in accountability first, then technology. Data owners before tool selection." Not "we need a lakehouse," not "data quality matters to us," not "launch an AI pilot in Q4."

That "not" list isn't a footnote. It is the strategy. What you choose to leave undone is exactly what gives everything else its power.

Step 3: Coherent action, or why sequence beats parallelism

Actions are where strategies are won or lost, and three rules hold them together.

The first is that every action serves the policy. It has to pass through the policy filter. A trendy BI tool with no ownership structure behind it isn't an action, it's a distraction. The second is that actions have to reinforce each other. A single action on its own tends to fizzle. Only the combination works. A data product without an owner is just a file or database. An owner without a platform is frustration. A platform without a use case is money poured into the void. The third is that sequence is itself part of the strategy. Name owners first, then build the inventory, then choose the tool, not the other way around. Trying to do everything in parallel just burns attention without producing any learning.

To make that concrete, here's what fixing the accountability vacuum actually looks like. You cut things down to 5 to 7 core domains (Customer, Product, Order, Finance, People). You name a real owner for each one, with a genuine mandate and veto rights, and you put them on the org chart where everyone can see them. You have each owner maintain their own asset inventory. And only then do you get to the tool question, with requirements that came out of steps one through three rather than out of market hype.

The operational atom: data as a product

The thread running through all of this comes from Zhamak Dehghani's Data Mesh: treat data as a product. There are four principles.

Domain ownership means the data belongs to the domain that knows it best. Data as a product means it comes with an owner, an SLA, documentation, versioning, and user feedback. A self-serve data platform means the platform enables domains instead of getting in their way. And federated computational governance means the standards live centrally while execution happens in the domains.

A good data product is discoverable, addressable, understandable, trustworthy, accessible, interoperable, secure, and valuable on its own. A dataset stops being a loose file and becomes a managed asset: five KPIs with clear definitions, source lineage, versioning, a named owner, and a freshness SLA.

And once you have products like that, you make them findable. A data catalog turns into a data marketplace, basically a shop for data, where people browse, read the detail page, and request access. It does three jobs. Find: which product fits my question? Understand: where does this come from, and how is it calculated? Trust: is quality assured, and am I allowed to use it? Tools like Collibra, Alation, and Microsoft Purview all live in this space.

Why this is the real foundation for AI

Here's the payoff that ties it all together. Curated data products are exactly what large language models and AI agents need: vetted sources, clear permissions, rich metadata. Picture asking an AI agent "Who owns our margin data in EMEA?" and getting back the database, the data asset, and the named owner with their contact details, pulled straight from the catalog.

That's not a moonshot. It's just what happens when the foundation is real. You don't get to trustworthy AI by skipping diagnosis, policy, and ownership. You get there because of them.

Four things to take with you

• Strategy is diagnosis, guiding policy, action. A wish list is not a strategy. The crux names the problem, the policy makes the choice, the actions back each other up.
• A guiding policy without trade-offs is a vision. What you deliberately don't do is as much a part of the strategy as what you do. "Domain owner before tool, every time."
• Data products are the operational atom. Datasets become managed assets with an owner, an SLA, and documentation. The catalog makes them visible, the marketplace makes them consumable.

Start with a crux, not a program. Three months, one data product, one measurable effect. Learn first, then scale.

Where to start

If you read the failure statistics at the top and felt a flicker of recognition, don't start by buying anything. Start by finding your crux.

What's the one sentence that names the real tension in how your organization works with data? If you can't say it yet, then that's the first piece of work, and it's worth more than any tool decision you'll make this year.