Connected data, disconnected decisions

In the early 2000s I worked on enterprise knowledge management systems: large-scale platforms designed to capture expert knowledge from across a global business, make it searchable and route it to the people who needed it. The organisations involved were serious. The investment was substantial. The technology, for its time, was good. The systems failed almost universally, and in ways consistent enough across different organisations and technologies to be worth understanding.

I have spent the last several years building and advising on connected product platforms. The data pipelines are more sophisticated. The storage is cheaper and more capable. The analytical tools are better by an order of magnitude. The failure mode is identical.

---

What went wrong the first time

Enterprise knowledge management failed for reasons that had nothing to do with the technology. The systems worked. The problem was the assumptions underneath them.

People would change their behaviour to use it. They did not. The knowledge portal was a separate system, outside the workflow where decisions were actually made. Using it meant stopping the work, going to a different tool, searching for what was needed, judging whether the result was current and correct, and then returning to the work. Most of the time it was faster and more reliable to ask a colleague.

Aggregated knowledge was the useful form. It is not, or not primarily. The person doing the work does not need the collective intelligence of the organisation. They need the specific answer to the specific question they are facing now, in the context of the specific decision they are making. A system that stores everything and surfaces it through search is a library. What the person at the decision point needs is a well-briefed colleague.

Data quality would maintain itself. This was the most damaging assumption. Documents went out of date. Processes changed. The metadata that made things findable was incomplete.

Once a user found two pieces of information that contradicted each other, or followed guidance that turned out to be wrong, trust in the entire system eroded. They stopped using it. The cycle was fast and almost impossible to reverse once it started.

---

The connected product version

A connected product platform collects telemetry from deployed devices: location, battery state, operating hours, fault codes, sensor readings, usage patterns. The pipeline from device to dashboard is well-understood engineering, and the investment to build it is real. In the majority of deployments I have encountered, the data is being collected and largely not acted on.

The fleet manager has a dashboard. It shows aggregated health across the fleet, a distribution of fault codes, average battery levels and units currently offline. It is accurate and current. Nobody in the field team opens it, because the person standing in front of a specific unit does not need a fleet-level view. They need to know what is wrong with this device, right now, in terms that tell them what to do next.

The maintenance records are captured, or partly captured, in a system that does not connect to the diagnostic tooling, which does not connect to the workshop management system, which does not connect to the warranty claims process. Each system is correct in isolation. The data that would allow early detection of a reliability pattern in a specific production batch is sitting in three separate systems that nobody has connected. That is exactly the kind of signal that saves significant warranty cost if caught early and becomes a significant liability if not.

Then a batch of sensor readings comes back wrong because of a calibration drift that was not caught before deployment. The field team learns to distrust that sensor type. Over time they learn to distrust the platform more broadly. The erosion is quiet, fast and familiar.

---

Starting from the decision

The lesson from knowledge management that transfers most directly is that a useful data system cannot be designed without first understanding the decisions it is supposed to support. In my experience this principle is acknowledged readily and acted on rarely, because it needs a different design conversation from the one engineering teams naturally have. The technology conversation starts with what data can be captured and how. The decision conversation starts with who makes which decision, in what context, and what they would need to know to make it well. The second conversation is harder to have and considerably more useful.

The difference becomes concrete when you try to be specific. Not “operators need visibility of fleet health” but “the workshop technician deciding which unit to prioritise for service needs to know the fault code, the operating hours since last service, and whether this unit is part of a cohort that has shown early signs of a specific failure mode.” Not “management needs performance data” but “the operations director deciding whether to expand into a new geography needs to know the reliability profile across different use conditions, the cost per unit of field intervention, and how those metrics changed over the first twelve months in the previous market.”

Those are different data requirements, at different levels of aggregation, delivered in different contexts to people making different decisions. A single dashboard that attempts to serve all of them will generally serve none of them well.

---

Where the data needs to arrive

The knowledge management lesson that was hardest to act on was also the most important: the data needs to arrive where the decision is made, not in a separate system the decision-maker has to go looking in. The enterprise KM projects kept missing this. They built the repository and assumed people would change their workflow to consult it. People did not, because the cost of the interruption was higher than the perceived value of the information on the other side of it.

For connected products the same principle applies in a straightforward way. The fault alert that matters to the field technician needs to appear in the work order system they actually use, not in a fleet dashboard they do not. The reliability signal that matters to the product team needs to surface in the engineering workflow where roadmap decisions are made, not in a monthly report that arrives after the planning cycle has closed. The warranty cost trend that matters to the finance team needs to be visible in the financial planning tools they work in, not in a separate operations system.

None of this needs unusual technology. It needs the platform to be designed from the beginning to push relevant data to the places where decisions happen, rather than as a central repository that the relevant people are expected to visit.

---

How trust erodes

Data quality in a connected product platform is not primarily an engineering problem. It is a trust management problem, and the consequences of getting it wrong are out of proportion to the apparent scale of the error. I have seen this happen in ways that were very difficult to recover from.

A single batch of miscalibrated sensors producing anomalous readings will be noticed by the people who rely on those readings. They adjust. They discount that sensor type, develop informal workarounds and stop raising issues through the platform, because the platform has shown itself to be unreliable. The signal the system was supposed to surface (the early warning, the developing fault, the reliability pattern in a specific production cohort) goes undetected. The cost of the trust failure is not the bad batch. It is every problem that goes unseen in the period after it, which tends to be a long period, because trust of this kind is slow to rebuild.

The organisations whose connected product platforms actually get used treat data quality as a first-class concern from the beginning, not a maintenance task addressed after launch. That means sensor calibration as a production step rather than an assumption, data validation at ingestion, explicit handling of connectivity gaps so that missing data does not present as normal data, and rapid acknowledgement when a quality issue is identified rather than quiet correction.

That last point matters more than it first appears. A team that sees a problem identified and fixed quickly will typically trust the system more as a result, not less. A team that notices problems nobody acknowledges loses confidence in the whole.

---

Working backwards

The practical implication is that the useful starting point for a connected product data strategy is not the data pipeline, the storage architecture or the dashboard design. It is a clear account of who makes which decisions, when, in what context, and what they would need to know to make them well. The technical architecture follows from that account, and it tends to look quite different from the architecture that emerges from a technology-first approach.

Built in the other order, technology first and workflow second, the architecture is usually correct and the system is usually underused. The investment that was supposed to produce operational intelligence produces a dashboard nobody opens and a data warehouse nobody queries.

This is not a new problem. The connected product industry is rediscovering it, at considerable expense, twenty-five years after the enterprise knowledge management industry learned it the first time.

---

Four things worth taking seriously

For boards: judge a connected product platform by the decisions it improves, not by the volume of data it collects or the quality of its dashboards.

For engineering leaders: start data design with who makes which decision, in what context, and what they need to know. Let the architecture follow from that account.

For product and operations teams: push each signal into the tool where the relevant decision is already made, and connect maintenance, diagnostic, workshop and warranty records so that cohort patterns can be seen.

For anyone responsible for data quality: treat it as trust management. Validate at ingestion, make missing data look missing, and acknowledge problems quickly and openly.

---

I would be interested to hear which decisions in your organisation are still being made without the data you are already collecting to support them.