January 2026 · 5 min read
From Data Strategy to Decision Systems: What It Takes
You can have a modern data stack, clean pipelines, and a warehouse that passes every audit, and still have an organization that cannot agree on what happened last quarter. The tooling is not the problem. The decision system is the problem.
Last year, I walked into an operating review where the CMO and the CFO were looking at the same quarter and telling two different stories. Not because someone was wrong. Because they were pulling from different tables, with different definitions of “active customer,” filtered by different date logic, rolled up by different hierarchies.
Both dashboards were green. The business was not green.
This is the thing nobody wants to say out loud: you can have a modern data stack, clean pipelines, a warehouse that passes every audit, and still have an organization that cannot agree on what happened last quarter. The tooling is not the problem. The decision system is the problem.
Your stack is not a system
By now, most companies have the pieces. Snowflake or Databricks. dbt. A BI layer. Reverse ETL. Event tracking. On paper, it looks mature.
Then you sit in the room where the forecast gets built and you watch a director pull a number from a spreadsheet that hasn’t touched the warehouse since someone copied it in January. You watch a product manager build a case for a feature using metrics that don’t exist in the semantic layer because nobody told them the semantic layer existed. You watch a sales leader quote pipeline coverage using a definition of “qualified” that conflicts with the one marketing uses to calculate conversion.
The stack exists. The system does not. And the difference between the two is the difference between having data and using it to make decisions.
Start with entities, not dashboards
I worked with a client last year whose data team had built over 200 dashboards. Usage logs showed that 11 of them got opened more than once a month. The other 189 were artifacts of a culture where “I need a dashboard” was the default request and “here’s your dashboard” was the default answer.
We started over. Not with dashboards. With entities.
What is a customer? Not philosophically. Operationally. When does a lead become a customer? When does a customer become inactive? What is the canonical ID, and where does it live? Same exercise for orders, products, pipeline, partners.
This felt slow. It felt like work that doesn’t show up in a sprint demo. But once the entities were defined and the relationships between them were modeled, three things happened that no amount of dashboard building could have produced.
First, metrics stopped drifting. When everyone agrees on what a customer is, “customer count” means the same thing in every report.
Second, cross-functional analysis became possible without a two-week data engineering ticket. The product team could slice by the same customer segments the CX team used, because the segments were modeled once and governed centrally.
Third, and this is the one that matters most: AI became trustworthy. You cannot layer an LLM on top of inconsistent entity definitions and expect coherent output. Garbage in, confidently wrong garbage out. But with clean entity modeling underneath, the AI layer starts to do something useful.
Leading indicators or lagging reports
Most analytics teams are in the business of telling the company what already happened. Revenue last quarter. Bookings this month. Deals closed last week. All useful. All too late to change.
The shift that changed how I think about this function was moving investment toward leading indicators. Not abandoning lagging metrics, but rebalancing the portfolio.
Pipeline velocity, measured daily. Activity signals: meetings booked, demos run, engagement scores. Coverage ratios by segment. Funnel conversion at each stage, tracked as a time series rather than a snapshot.
We built 90-day moving averages for pipeline generation. Forward-looking forecasts for Q+1 and Q+2 based on trend extrapolation rather than gut. Win probability scores that updated weekly.
The difference is not sophistication. A moving average is not sophisticated. The difference is that the conversation in the operating review shifted from “what happened” to “what is about to happen, and what are we going to do about it.” That is the line between analytics as reporting and analytics as a decision input.
Where AI fits
There is a lot of noise about AI in data right now. Most of it is pointed at the wrong layer.
The mistake I see repeatedly is applying AI directly to raw or poorly structured data. A company with inconsistent entity definitions, fragmented ownership, and unaligned metrics bolts an LLM onto their warehouse and wonders why the answers are incoherent. The model is not the problem. The foundation is the problem.
Where AI starts to matter is at the decision layer, on top of governed, modeled data.
Goal assessment against SMART criteria, where the LLM evaluates whether a stated objective is measurable given the data that exists. Churn prediction tied to specific CSM action plans, not just a score on a dashboard nobody checks. Win probability models that influence deal strategy in real time rather than validating it after the fact.
The pattern emerging now, and this is where I think the next two years get interesting, is agentic systems operating within governed data environments. Systems that monitor continuously, detect anomalies, recommend actions, and trigger workflows. Not replacing human judgment, but compressing the time between signal and response.
But this only works if the foundation holds. Clean entities. Aligned metrics. Trusted pipelines. Clear ownership. Without that, you are not scaling intelligence. You are scaling noise.
The real job
If you are leading data, analytics, or AI today, you are not building dashboards. You are not even building a data platform. You are building the operating system for how your business makes decisions.
The quality of that system, not the sophistication of your stack, is what determines whether the business competes or reacts.
Post one said the hard part starts after the pipeline works. Post two said the hard part is saying no in a way that survives the room. This is the extension: the hard part is building the system that makes the decisions better, not just the data more available.
If you are still focused on tools, you are behind. If you are focused on data, you are close. If you are focused on decisions, you are in the right game.