We have seen this enough times that it no longer surprises us. A data platform is approved, the build finishes, and the dashboard loads. Six months later the same decisions are still being made from the spreadsheet or the old system. The technology usually works. What does not exist is a clear decision the platform was supposed to change, and a person who will be measured on whether that decision actually improved.
This is not a new observation. At organizations we have worked with, and with the customers we now support on strategic advisory, we keep seeing versions of the same pattern: platforms that are technically live but operationally optional. The difference now is that the cost of leaving them unused is higher. Licenses renew. Teams keep maintaining pipelines that almost no one relies on for a decision. And when someone finally asks for the baseline, it takes weeks to reconstruct a number that should have existed before the build started.
Why this keeps happening
Most platforms are justified on a broad goal. Single source of truth. Self-service. Better insights. AI readiness. A pilot is marked successful when a report appears in a meeting. The project team moves on. Later, when someone asks how many decisions actually changed, the answer is hard to find.
The gap usually shows up in one of three places:
- No one can name the specific decision the platform was meant to change.
- Even if the decision is named, no one measured how it was being made before the platform existed.
- The person who would be measured on the outcome was not in the room when the build started, or does not accept the measurement after go‑live.
These are not technical failures. They are decisions about scope and accountability that were never made. When they are missing, the platform can be live and the pipelines can run, yet most people continue to work around it.
What the surveys show
The pattern is visible in recent research as well. McKinsey’s 2025 piece on data products notes that organizations often build data products for a single use case and then struggle to reuse them. Incentives reward building something new more than making an existing product usable by other teams. One consumer company example showed that once a data product supported five use cases, the projected cost was about 30% lower than building separate pipelines. An insurance company captured $210 million from a set of use cases; standard one-off approaches would have cost roughly 50% more and taken up to twice as long. The economics only appear when the product is actually reused. Most organizations never reach that point because the second and third use cases are never defined or owned.
Komprise’s 2026 survey of 500 technical decision-makers found a similar mismatch on the data side. Only 4% of organizations had created schema for more than 70% of their unstructured data and made it available to lakehouse and analytics teams. Only 7% had cleaned and classified 70% or more of their unstructured file data for AI use. Two-thirds described their AI programs as mature or maturing. The platforms were in place. Most of the data that would make them useful was not.
Platform investment vs usable data vs decisions moved
Komprise 2026 survey snapshot
What we do when we see this
We do not start by recommending another layer on the platform. We start by testing whether one real decision can clear three checks.
In the first working session we ask the team to write a single sentence: “The platform will change [this decision].” Examples that have worked: “Pricing exceptions above X will be decided from the platform by default,” or “Inventory reorder quantity for these SKUs will come from the platform, not the spreadsheet.” If the sentence cannot be written, we stop further platform work until it can.
Next we ask someone on the client side to pull the last 30–60 days of that number from the system that already has the data. We do not build a new report to create the baseline. If this takes more than ten working days, we treat it as a signal that the decision is not yet ready for the platform.
Then we name the person who will be measured on whether the number improves. That person attends the session where the baseline is reviewed. We ask them, in the room, whether they accept the measurement and the 90-day review. If they do not, the use case does not move to production.
Only after those three exist do we define the smallest change that would make the platform the default place that decision is made. This is usually a view, a simple workflow step, or a notification—not a broad data model rebuild. The acceptance criteria is simple: the owner can complete the decision from the platform in the normal workflow.
At 30, 60, and 90 days we review three things with the owner: Is the decision being made from the platform by default? Has the baseline number moved in the direction we expected? Are people outside the original project team using it without asking for an extract? If any answer is no, we stop adding features and fix the gap before expanding to the next decision.
After one decision is being made from the platform and the owner still believes the number, we apply the same checks to the next decision. The platform grows only when a named decision is already being made from it by someone who is measured on the outcome.
Three checks before you add more
- What decision is this supposed to change? Write it in one sentence.
- How is that decision made today? Can someone produce the last 30–60 days from the current system without building a new report?
- Who will be measured on whether it improved? Name and role. If that person is not in the room before the build starts, the platform usually stays unused for that decision.
What “used” looks like
Ninety days after go‑live, the test is simple. Is the named decision being made from the platform by default? Does the person who owns that decision still believe the number has moved? Are people outside the original project team using it without a separate extract?
If the answer is no, the platform was built. It has not been adopted for the decision it was meant to support.
If a check fails
- No clear decision — Pause. Spend a week naming one decision and writing it down.
- No baseline — Do not add features. Get someone to pull the last 60 days from whatever system already has the data.
- No owner — Do not move that use case to production. Get the owner in the room and confirm they accept the measurement.
Conclusion
The pattern is consistent across the organizations we have worked with and the customers we support now. Platforms get built. Decisions do not move. The surveys show the same gap at scale: investment continues, usable data and actual reuse lag.
The practical response is not another platform or another layer. It is to stop adding scope until one decision can clear the three checks—named in one sentence, with a baseline that already exists, and an owner who accepts the measurement. Once that happens, the same checks apply to the next decision. The platform grows only when it is already being used for something someone is measured on.
If the current plan cannot answer those three questions, the next step is not more technology. It is finishing the checks.