Why this post exists
After fifteen years of building connected devices, we’ve seen the same five patterns kill more IoT pilots than every protocol war put together. None of them are technology problems. All of them are knowable in advance, if you ask the right question.
This is the post you read before you sign the next pilot — not after.
1. The stakeholder who quietly stopped attending the standup
Symptom: the operations director was at the kick-off, the protocol selection meeting, and the BOM review. Three months in, they’ve sent their junior to the demos. Six months in, you haven’t seen them in person.
What’s actually happening: the project no longer maps to their KPIs, or they’ve quietly decided it’s going to fail and they don’t want to own the conversation.
The question to ask: “What does success look like for you personally, in your year-end review?” If they can’t answer, you don’t have a sponsor. You have a sponsor-shaped seat in the room.
2. The power budget that was never validated in the actual installation
Symptom: the datasheet says 10 µA sleep current. The lab measurement says 12. The first three months in the field, the batteries are tracking to spec. Month four, two devices die a week.
What’s actually happening: the real-world installation has a duty cycle the lab never simulated. Daytime heating warms the regulator. A nearby motor occasionally couples noise into the sense line. The OTA update process you added in month two adds a 12-second radio burst per week.
The question to ask, before kick-off: “What’s the minimum acceptable battery life, and who is paying to replace the device when it doesn’t make it?” The answer reveals how much engineering rigour the project actually deserves.
3. The back-end roadmap that drifted out from under the firmware team
Symptom: firmware is feature-complete by month four. The back-end team is still re-platforming. By the time the back-end is ready, the firmware needs three new fields, and the field deployment plan has slipped two quarters.
What’s actually happening: nobody owns the protocol contract between firmware and back-end. Each team is optimising locally.
The question to ask: “Who owns the message schema? Where is it documented? When was it last changed and who reviewed the change?” If the answer is more than one person, or “we’re using Confluence,” you have a problem already.
4. The “we’ll figure out manufacturing later” trap
Symptom: prototype works beautifully. First 100 units work. Production batch of 1,000 has a 7% reject rate at the line-end test you didn’t have a budget for.
What’s actually happening: the prototype tolerances are loose, the production tolerances are not, and nobody designed for testability.
The question to ask, ideally at the BOM review: “What’s our line-end test plan, who built it, and what’s the per-unit test time?” If the answer is “we’ll work that out closer to production,” budget another two months.
5. The user the team never spoke to
Symptom: the device works perfectly. The user can’t install it. Or they install it upside down. Or they take it home to charge.
What’s actually happening: the installation context wasn’t in the brief. Engineers tend to design for engineers.
The question to ask: “Who is going to physically install the device, and have you watched one of them try?” The answers will either reassure you or save the project.
What to do about it
For most of these, the fix is the same: name the question, name the owner, and put both in the kick-off pack. The technology will look after itself once these are in place.
If any of these sound familiar from a project you’ve got running, we’d be happy to take a look. First conversation is free.