Product decisions age differently in connected systems

Most product advice is written for software that can be changed on a Friday and corrected the following Monday. Connected systems do not work that way. When a product includes hardware in the field, firmware that ships on a slow cadence, and data that only becomes trustworthy after a fleet has been running for a year, the cost of a decision is spread across a far longer stretch of time than the meeting in which it was made. We work in these environments. The most useful thing we tell a technical buyer at the outset is that in a connected system, the decision in front of you is usually less about what the product does now than about what will be expensive to change once the hardware is out in the field.

The lifecycle is the constraint

A piece of transit hardware installed on a vehicle or at a station is expected to run for a long time. Ten years is common. The unit was specified against a procurement document, integrated with systems that have their own replacement cycles, and deployed by crews whose time is scheduled months in advance. None of that moves at the speed of a product roadmap.

That has a direct consequence for how features get scoped. A capability that looks small on a backlog can carry a long tail if it commits the hardware to an assumption. Fixing a wrong assumption in software is a release. Fixing one that has already been baked into a connector, a mounting, a power budget, or a certification is a program, and sometimes a recall. Teams that come from pure software tend to treat those as the same class of problem, and get caught out when they turn out not to be.

When we advise on direction for these products, we ask early which parts of a decision can be undone later and which cannot. The ones that can be undone are free to move fast; the data will correct them soon enough. The ones that cannot deserve far more scrutiny than their apparent size suggests, because the field will hold them in place long after anyone remembers why they were chosen.

Field conditions are the real specification

The specification that actually governs the product is the one the field enforces. The requirements document is a guess at it, written before anyone had to live with the result. A device on a vehicle deals with temperature swings, vibration, intermittent power, cellular coverage that vanishes in tunnels and depots, and maintenance crews who have a few minutes per unit and no patience for a product’s internal model of itself. Those conditions are what decide whether a feature works.

We have watched good ideas fail because the assumption underneath them did not survive contact with any of that, even when the logic was sound. A feature that leans on a steady network connection behaves very differently on a bus that spends part of every day underground. An update mechanism that runs cleanly in a lab falls over when a thousand units wake up in the same few minutes at the start of a service day and saturate a backhaul sized for steady-state traffic.

The discipline that prevents this is dull: write the field conditions into the requirements as first-class items, and test against them before committing to anything. It gets skipped constantly, because the field conditions are inconvenient and the lab is right there. A decision validated only in the lab has been validated against a system that does not exist.

Data from a deployed fleet is a delayed signal

One real advantage of a connected product is that the fleet reports back. Deployed units generate telemetry, and given enough time that telemetry tells you what is actually happening out there. The advantage is real, but it arrives slower and noisier than most teams plan for.

Fleet data comes in on the fleet’s schedule. A failure mode that shows up once per unit per year will appear steadily across several thousand units and may not appear at all in a pilot of twenty for months. That makes early data from a small deployment quietly misleading: the conditions that produce the expensive failures have not happened often enough yet to register. A decision that looks validated by pilot data may only have been validated against the easy part of the distribution.

Underneath that sits a data-quality problem. Telemetry from the field arrives from units on different firmware versions, installed at different times, in different conditions, by different crews. Before any of it can answer a product question, someone has to establish that it means the same thing across all those cases. Teams that treat fleet telemetry as clean and immediately actionable end up making confident decisions on a foundation that is still moving. We put real work into that foundation, because a product decision is only ever as good as the data underneath it, and in a deployed fleet that data is not ready to be trusted on arrival.

What this means for how the decision gets made

The move is to spend the speed you have where it changes the outcome, and to accept that some parts of a connected product will not tolerate that speed at all. The parts that can be undone should move as fast as any software team can manage, corrected by the data as it stabilizes. The parts that the hardware, the field, or a certification will hold in place for years are the ones to slow down, look at hard, and where you can, prototype against real conditions before committing.

The failure we are most often brought in to correct is a mismatch between how fast a decision was made and how long its consequences last. A team ships a hardware assumption at software speed, the fleet locks it in for years, and the bill arrives long after the decision felt cheap. Most of the work of getting product direction right in these systems is learning to tell those two kinds of decision apart, early, and giving each the treatment it needs.

For a technical buyer weighing this kind of work, the question worth putting to any advisor is whether they have actually lived that difference, on real hardware, in the field. The teams that build connected products that last tend to be the ones that took the lifecycle seriously from the first decision.