Data, decision, action: what a connected product is for

First thing in the morning, someone at a Woolworths store checks which sanitiser stations need refilling and carries refills to those, and only those. In the evening, a resident on an estate sees there are about two days of electricity left at the current pace, and tops up in a few taps. In between, an operator in a parking control room sees that a lane has gone quiet and sends someone to look. Three products, built for three clients, doing the same job. A device produced a number. A person decided something because of it. Something changed in the world.

That loop is what a connected product is for: data, decision, action, and round again. Take away any one of the three and you have a sensor, a report or a gadget, and you have still paid for a product.

The loop, three times

Woolworths. Each station measures the level in its tank and counts its sprays. The decision belongs to whoever does the rounds: which stations need a refill this morning. The action is the refill, and the next reading shows the tank full again.

Unimet. The meters measure a home's electricity and water. The decision belongs to the resident: whether to top up tonight. The action is a top-up in a few taps, paid by card and confirmed the moment it lands, and the balance moves.

Crest. A camera reads a plate and gives the read a confidence score. The decision is whether to open the boom, and a rule takes it where it can: above one threshold the boom opens on its own, below another the read is rejected, and between the two an operator decides. The action is the boom, and the session's ticket and payment follow from it.

Design the loop backwards

Most connected products are specified in the order the parts are bought: sensor first, dashboard second, action never. We design them the other way round.

Start with the action. What will somebody physically do because this product exists? Carry a refill, buy credit, send someone to a lane. If there is no action, stop. The product is a report, and a report can be built far more cheaply.

Then the decision that leads to it, and who makes it. A store assistant deciding once a morning, a resident deciding at the kitchen table and an operator deciding while a car waits at the boom need three different products, whatever the sensor is. Decide, too, which decisions need a person at all. A rule that handles the clear cases leaves people free for the unclear ones. Send everything to a person and they learn to ignore it. Send everything to a rule and it is wrong in ways nobody sees.

Last comes the data. Which number, at what rate and to what accuracy, makes that decision easy? This is where the architecture gets decided, whether anyone notices or not. A refill decision made once a morning does not need a reading every ten seconds, and a device that reports once an hour lasts far longer on a battery than one that reports constantly. A boom needs its verdict before the driver loses patience. The decision sets the reporting rate, the reporting rate sets the radio, the battery and the cloud bill, and much of the cost of owning the product follows from how often someone needs to know.

Where loops break

The data arrives and no decision is attached. This is the dashboard with forty charts, built because the data was there. Every chart without a decision behind it costs money to collect, store and render, and earns nothing. Design the screens around the three or four numbers that drive an action. The rest can wait in cold storage until somebody has a question for it.

The action never closes. An alert goes out, nobody owns it, and after a month nobody reads the alerts. A loop has to know that it closed. At Woolworths, usage is reconciled against stock, so every refill is accounted for rather than assumed, and Crest keeps every financial movement in an append-only log. A loop that cannot tell whether it closed is an open loop, and open loops decay.

The number arrives in the wrong unit, or too late. Nobody decides to top up in kilowatt-hours. The Unimet app shows days of cover, worked out from the home's own pace of use, which is why its warning arrives days ahead rather than when the lights go off. Crest's operators used to find a problem on a lane in the month-end numbers. Now each lane is compared with its own usual pattern for the time of day, so the same fault is flagged within the hour. Both fixes work because they sit close to the data, where the context still is.

The loop is tuned once, for everyone. Every site has its own normal, and a camera in an underground car park sees differently from one in daylight. Crest's thresholds are set per site, versioned, and changed as an explicit act that leaves an audit trail. A loop tuned for the average site is wrong at most of them.

One question for every number

For every number your product will produce, ask who decides what because of it, and what they then do. If the answer is "it would be good to have", leave it out of version one. The products that run unattended are the ones where every number has an action at the end of it.

That is also why we build a working slice first. A slice is one loop: one device, one number, one screen, one decision. If the loop works thin, it is worth thickening. If it does not, nothing built around it will help.

Tell us about the decision your product should make possible. Send us a brief, or write to hello@handee.co.za.