Every engineer has experienced this. You build a prototype. It works perfectly in your office. You hand it to someone else and within five minutes they have found a way to break it that you never imagined possible.
That gap between "works on my desk" and "works in the real world" is where most IoT products quietly die. Not because the hardware failed. Not because the firmware had a bug. But because the team designed for themselves and forgot who would actually be using it.
After 15 years of shipping IoT products across industrial, healthcare, consumer, and infrastructure applications, the single biggest thing I have seen separate production-ready products from expensive prototypes is this: assuming the user knows nothing and designing accordingly.
Not as an insult. As a discipline.
The engineer's blind spot
Engineers make terrible test users for their own products. We know too much. We know which button to press first. We know what the blinking LED means. We know not to power the device on before the antenna is connected. We designed it, so the whole thing makes sense to us.
The user does not have any of that context. They open the box, look at the device, and figure it out from scratch. If the setup process requires reading a manual, most people will not read it. If an error state is communicated with a LED pattern that means something to an engineer but nothing to anyone else, the user will not know what to do. If the device can be configured incorrectly in a way that causes silent failure, some users will configure it incorrectly.
This is not a UX problem. It is a systems design problem. And it needs to be solved at the hardware and firmware level, not patched with better documentation.
Design for the worst case user
The KISS principle, keep it simple, gets applied in engineering all the time. But most engineers apply it to their own workflow: simpler code, simpler architecture, simpler debugging. The more important application is to the user experience of the shipped product.
A production-ready IoT device should be so simple to set up and use that someone with no technical background can do it without help. That is the bar. Not "it comes with a good manual." Not "you can call support." The device itself should guide the user through every state it can be in.
What does that look like in practice? It means thinking through every scenario the device might encounter before you finalize the hardware. Not just the happy path. Every edge case. Every failure mode. Every state the device can end up in, including states the user was never supposed to reach.
What happens if the user powers it on before connecting it to the network? What happens if the battery dies mid-update? What happens if two units are placed too close together and interfere with each other? What happens if the device is installed in a location with poor signal? What happens if the user presses the reset button at exactly the wrong moment?
Each of these is a scenario the device needs to handle gracefully. Not crash. Not lock up. Not enter a silent failure state that looks like normal operation. Handle it gracefully and tell the user what is happening in the simplest possible way.
Feedback is not optional
One of the most common production failures I see is a device that gives the user no feedback during critical operations. No indication that setup is in progress. No confirmation that it worked. No clear signal when something went wrong.
Engineers tend to underinvest in feedback because during development they can see everything in a serial console. They know the device is working because the logs say so. The end user has no serial console. They have whatever you put in front of them: LEDs, a display, a sound, a companion app, or nothing at all.
If the user cannot tell what state the device is in without specialized tools, the device is not production-ready. This sounds obvious but it gets skipped constantly, especially when the feedback mechanism adds cost or complexity to the hardware.
A single well-designed LED can communicate a surprising amount of information if the states are thought through carefully. A simple companion app can make a technically complex setup process feel effortless. The investment is almost always worth it.
Edge cases are not edge cases in production
Here is something that catches teams off guard when they go from prototype to production: the scenarios you dismissed as unlikely happen constantly at scale.
If you ship 10,000 devices and there is a one-in-a-thousand chance of a particular failure mode, you have just guaranteed 10 field failures. If there is a one-in-a-hundred chance, you have 100. The math is unforgiving. Scenarios that felt like edge cases in the lab are real problems in the field.
This is why production-ready firmware handles every state the device can reach, not just the states you expect it to reach. Every input needs validation. Every network operation needs a timeout. Every write to non-volatile memory needs to be atomic or recoverable. Every update mechanism needs a fallback. The device needs to be able to recover from power loss at any point in any operation without ending up in an unusable state.
None of this is glamorous engineering. It is the kind of work that does not show up in a demo. But it is the difference between a product that works and a product that works reliably at scale.
The real checklist
When I am evaluating whether a product is ready for production, these are the questions I ask:
Can a non-technical user set this up without help? Not with a good manual. Without help. If the answer is no, the setup process needs to be redesigned.
Does every state the device can be in communicate something useful to the user? Including error states, update states, and states the user was not supposed to reach.
What happens when things go wrong? Power loss during update. Network dropout mid-operation. Bad user input. Sensor failure. Each of these needs a defined, graceful behavior.
Has someone who did not build it tried to use it? Not a colleague who knows the product. Someone who has never seen it before. Watch them use it without helping. Every moment of confusion is a design problem.
What does the device look like to the user in the worst case scenario? Not the best case. The worst case. If the answer is confusing or invisible, it is not ready.
Prototypes and products are different things
A prototype proves that the idea works. A product proves that the idea works for the people who will actually use it, in the conditions they will actually use it in, without any of the context the engineer had when they built it.
The gap between those two things is wider than most teams expect. And it is almost always filled by doing one thing: assuming the user knows nothing, and designing as if that assumption is a fact.
Next up: How to read a wireless protocol spec without drowning. What actually matters for product decisions and what you can safely ignore.