Your device works. Your customers still cannot set it up.
The gap between hardware that functions on a bench and a product someone can unbox. What a pilot exposes, and what to build before it does.
The short answer
Hardware pilots usually fail on the software around the device rather than the device itself. Four things account for most of it: pairing that assumes the happy path, no first-run confirmation, no way to see what a unit is doing when it goes quiet, and a companion app organised around the data model instead of the job. All four are cheaper to build before the pilot than to diagnose during it.
The hardware does what it is supposed to. It has done it hundreds of times on a bench, in front of people who know exactly how to hold it. Then twenty units go out to real customers and the support inbox fills with a problem nobody saw coming: they cannot get it connected.
This is the most predictable failure in connected products, and it is a software failure almost every time.
One: pairing that only knows the happy path
On the bench, pairing works because the engineer is standing next to the device, on a known network, with the app already installed and permissions already granted. A customer has none of those things.
The paths that break are mundane and entirely foreseeable: a network that needs a captive portal login, a phone that denies Bluetooth permission on the first ask, a device that was already paired to someone else’s account, two units in the same room. Each one is a branch that has to be designed, and each one becomes a support call if it is not.
- Design the failure states before the success state. There are more of them.
- Every dead end needs a way out that is not "contact support".
- Assume the customer will try again, wrongly. Make retry safe.
Two: no moment where it says "that worked"
A person who has just set up a device needs to be told, unambiguously, that it is working. Not a status icon they have to interpret. A clear first-run state that shows the device doing its actual job, with data from their own unit.
Without it, every pilot user is left privately unsure whether they did it right, and that uncertainty comes back to you as churn rather than as a support ticket, because people do not file tickets about feeling uncertain.
Three: no visibility when a unit goes quiet
In week three of a pilot, one unit stops reporting. Somebody asks what happened to it. If the honest answer requires an engineer with a laptop and a database, your pilot is not instrumented, and you will spend the pilot diagnosing the pilot instead of learning from it.
What a pilot team needs is unglamorous: which unit, when it last reported, what it was doing, what changed, and what to try next. That is a small piece of software, and it is the difference between a pilot that produces answers and one that produces arguments.
Four: an app organised around the data, not the job
The fastest companion app to build mirrors the device’s data model: a list of readings, a settings page, a log. The fastest app to build is almost never the one that makes the product worth having.
The question to design against is not "what does the device produce" but "what is this person trying to find out". Those are rarely the same shape. A sensor that reports a number every thirty seconds is useful to somebody who wants to know whether something is about to go wrong, and a list of numbers does not answer that.
What to build before the pilot, not during it
- 1Onboarding, including the failure branches, tested by someone who has never seen the device.
- 2A first-run state that proves it worked, using the customer’s own data.
- 3Diagnostics your own team can read without an engineer in the room.
- 4One complete workflow that does the job end to end, rather than partial versions of three.
A working pilot is not manufacturing readiness, and it should not be sold to a board as one. What it is, done properly, is the cheapest way to find out whether the product is worth manufacturing.