When Connected Hardware Teams Stall Between Prototype and Pilot

Why the prototype stops being enough

A prototype can move quickly when one or two people know every shortcut. They know which reset fixes a device, which firmware version to load and what to change in the database. Once other people start building and using it, those unwritten steps become problems.

At this stage, I look at what the product still needs an engineer to do by hand. Those steps often show where setup, testing or support needs more work.

What changes when you build more units

• A demo shows that it can work. A pilot needs to show what happens when it fails, and give your team enough information to find out why.
• An engineer may know how to set it up. A customer or technician needs clear steps and a way to recover if setup goes wrong.
• The app may look right during a demo. During a pilot, check that what it shows matches the device, backend records and what support can see.
• One assembled unit shows that the design can be built once. Each pilot unit also needs an identity, a test record and a way to be set up, updated and supported.

Where I’d look first

• Which failures do you only learn about when a customer contacts support?
• Which steps only one person knows how to do?
• Where does someone have to edit a database record, reset a device or check a log by hand to keep things moving?
• What would break first if you built ten times as many units?

Start with one problem

I’d start by tracing one problem through the system. Take a failed setup, for example: what did the device do, what did the app show and what did the backend record? Put those side by side. You may find a missing event, a stale record or a step that depends on someone remembering to do it.

Turn the findings into a plan

• A sketch of where the device, app, backend and support records disagree.
• Two or three failures you need better logs or tests for.
• A decision on what you can test in the pilot and what you need to fix first.