How to brief a connected product

The brief for our first product fits in a sentence. Woolworths wanted a sanitiser station that knew how much liquid it had left, how many people it had served and when something had gone wrong, and that told someone. Everything that followed grew out of that sentence: the board, the modem, the battery, the store app, the fleet platform and, eventually, more than 800 units across 500 stores. It was a good brief because it described a problem and who needed to know about it, and it left the product to the people building it.

Most briefs we receive are longer and say less. Here is what we need from one, what helps if you have it, and what to leave out.

Start with the problem, not the product

The useful part of a brief is the situation it describes. A customer walks up to a dispenser and finds it empty. A household finds out its electricity credit has run out when the lights go off. A parking lane goes quiet in the middle of the afternoon and nobody knows until the month's numbers come in. We have built products around each of those moments. Each one costs somebody money or trust, and each has a person who would act if they knew in time.

A brief that starts with the product skips that step. "We need an app that shows our meters" is a solution, and it may be the wrong one. On a prepaid estate, residents need a warning days before their credit runs out and a way to top up in a few taps, which is what the Unimet app gives them. A meter reading on a screen would satisfy the sentence and miss the problem. The product that comes out of a problem looks different from the one that comes out of a solution, and it is usually smaller.

The three things we need

We have written before that a working slice needs three things from a client. A brief needs the same three, so here they are in more detail.

The one physical thing the product must sense or control. The level in a tank. The reading on a meter. A number plate in a lane. If there are six, tell us which one the product cannot exist without. The other five can wait for the proper build, and some of them will turn out not to matter.

The one decision a person should be able to make because of it. Which stations to carry refills to this morning. Whether to top up tonight. Whether to send someone to lane four. The decision tells us who the user is, what the first screen must show and how fast the data has to arrive. Readings nobody acts on are a cost, and a brief that names the decision has already cut most of them.

A realistic place to try it. A corner of your warehouse, a store that will tolerate a prototype on the wall, one lane at one site. Every sensor works on a desk. We want to see how it behaves where it will live, with a handful of units in real places before anyone commits to a thousand.

What helps, if you have it

How many, and where. Ten units in one building and a thousand across the country are different products, with different radios, different update strategies and different costs to run.

What it must plug into. A stock system, a BI tool, a payment provider, the cameras already in the lanes. Crest's control room takes its plate reads from the lane cameras, each read with a confidence score, and the whole verification flow was built around that score.

The conditions. Mains or battery, indoors or out, what the signal is like at the site, and whether anyone will be nearby when it fails. We have written separately about designing for South African conditions. The short version is that we would rather hear about the power cuts in the brief than in the field.

Hardware you already have. A board, a sensor, a meter with a known protocol, or a half-built product from another supplier. None of it is a problem. All of it changes where we start.

Where you are. Our brief form asks whether you have just an idea, hardware in hand, a prototype, a live product that is scaling, or a product that needs rescuing. Each of those gets a different first phase, and knowing which one you are in saves a round of questions.

Timing and a budget band. Not to the rand. A rough band tells us whether to propose a working slice, a pilot or a full build first, so the first proposal is the right one.

What to leave out

The feature list. A list of forty features, written before anyone knows what the sensor can do, is a specification built on guesses. Bring the three or four the product cannot ship without and let the working slice earn the rest. The list can come to the first call. It should not be the brief.

The technology, unless you have a reason. Some briefs name the microcontroller, the cloud provider and the app framework. Sometimes there is a good reason: an existing fleet, an in-house team who will maintain it, a standard your customer imposes. Say so and we will design around it. Without the reason, a chosen stack is a constraint that costs you options and tells us nothing about the problem.

The polish. A brief is the start of a conversation, and the proposal is the document. Three paragraphs written in an afternoon beat thirty pages written over a month, and they arrive a month sooner.

What happens to it

We read it and come back with questions, because the questions are where the product starts to take shape. Then a first call, about the problem, the users, the devices and the data. Then a proposal with the scope and cost of a first phase. For most products that is a working slice: real firmware on real hardware, a live cloud and a first screen, in your hands in about ten days. Nothing in the brief binds you. It is the thing we argue with, and the better it describes the problem, the better the argument.

If you only have a few lines

Write the three things: the one thing to sense or control, the one decision it should make possible, and where we can try it. If you have the numbers, the systems and the conditions, add them. If you have a feature list, keep it for the call. Then send us a brief, or write to hello@handee.co.za.