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 much longer period than the meeting in which it was made. We work in these environments, and the single most useful reframe we can offer a technical buyer is this: in a connected system, you are rarely deciding what the product does now. You are deciding what it will be expensive to change later.

The lifecycle is the constraint, not a footnote

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.

This has a direct consequence for how features should be scoped. A capability that looks small on a backlog can carry a large tail if it commits the hardware to an assumption. Fixing a wrong assumption in software is a release. Fixing a wrong assumption that is now baked into a connector, a mounting, a power budget, or a certification is a program. Teams that come from pure software tend to treat these as the same class of problem, and they are not.

When we advise on direction for these products, we ask early which parts of a decision are reversible and which are not. The reversible parts can move fast and be corrected by data. The irreversible parts deserve more scrutiny than their apparent size suggests, because the field will hold them in place long after anyone remembers why they were chosen.

Field constraints are the real specification

The specification that matters is the one the field enforces, not the one in the requirements document. A device on a vehicle lives with temperature swings, vibration, intermittent power, cellular connectivity that drops in tunnels and depots, and maintenance crews who have a few minutes per unit and no interest in a product’s internal model of itself. These conditions decide whether a feature works in practice.

We have seen good ideas fail not because the logic was wrong but because the assumption behind them did not survive contact with the field. A feature that depends on a steady network connection behaves very differently on a bus that spends part of every day underground. An update mechanism that works in a lab fails when a thousand units come online within the same few minutes at the start of a service day and saturate a backhaul that was sized for steady-state traffic.

The practical discipline is to write down the field conditions as first-class requirements and to test against them before committing. This sounds obvious. It is skipped often, because the field conditions are inconvenient and the lab conditions are available. A product decision made against lab conditions is a decision made against a system that does not exist.

Data from deployed fleets is a delayed signal

One of the genuine advantages of a connected product is that the fleet reports back. Deployed units generate telemetry, and over time that telemetry tells you what is actually happening rather than what you assumed would happen. This is real and valuable. It is also slower and noisier than teams expect.

Fleet data arrives on the fleet’s schedule. If a failure mode appears once per unit per year, a fleet of a few thousand units will show it steadily, but a pilot of twenty units may not show it for months. Early data from a small deployment can be quietly misleading, because the conditions that produce the interesting failures have not yet occurred often enough to register. A decision that looks validated by pilot data may only be validated against the easy part of the distribution.

There is also a data-quality problem that compounds this. Telemetry from the field is generated by units running different firmware versions, installed at different times, in different conditions, by different crews. Before the data can answer a product question, someone has to establish that it means the same thing across all of those cases. Teams that treat fleet telemetry as clean and immediately actionable make confident decisions on top of an unstable foundation. We spend real effort on that foundation, because a product decision is only as good as the data underneath it, and in a deployed fleet that data needs work before it can be trusted.

What this means for how the decision gets made

None of this argues for moving slowly. It argues for spending the available speed in the right place. The reversible parts of a connected product should move as fast as any software team can move, guided by the data as it stabilizes. The irreversible parts, the ones the hardware or the field or a certification will hold in place for years, deserve to be slowed down, examined, and where possible prototyped against real conditions before they are committed.

The most common failure we are asked to help correct is a mismatch between the speed of the decision and the lifetime of its consequences. A team ships a hardware assumption at software speed, the fleet holds it for years, and the cost shows up long after the decision felt cheap. The work of getting product direction right in these systems is largely the work of telling those two categories apart, early, and treating each one honestly.

For a technical buyer evaluating this kind of work, the question worth asking of any advisor is whether they understand that difference in their bones or only in theory. The teams that build durable connected products are the ones that respect the lifecycle instead of fighting it, and that plan for the field they will actually deploy into rather than the one that is convenient to assume.