IoT Value and Product Strategy · Study deck
IoT Project Failure: Promise and Context Risks
Trace one useful outcome from the physical event to the person who acts.
Ada is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Diagnose common IoT pitfalls across consumer, enterprise, and industrial deployments
- Prevent vendor lock-in by choosing interoperable devices and open standards
- Calculate Total Cost of Ownership (TCO) for IoT projects using a 5-year framework
- Secure IoT deployments using defense-in-depth strategies across all layers
Major section
Start With the Story
A building pilot works during a guided tour.
- On Monday, two units are offline, a supplier has changed its terms, the installer has left, and a resident cannot remove old account data.
- The product owner must review the system as a service with people, costs, duties, and recovery.
- It exposes assumptions that need owners and tests.
Major section
Start With the Story (continued)
The system should show what changed, who approved it, and which old state is no longer trusted.
- This review cannot predict every failure or five years of cost from one pilot.
- A blank owner is a design fault, not a future task.
- Queue only work that is still useful later.
- Price the work people tend to omit.
Major section
Start With the Story (continued)
The deeper sections organize consumer, business, industrial, security, privacy, scaling, lock-in, and support pitfalls into questions that can change a design before contracts and hardware make change expensive.
- A neat total is weak if no one can change the inputs.
- A pilot becomes useful when it reveals what must be owned next, not when its best day is treated as the future.
- This chapter follows the failure story backward so each pitfall becomes a design question you can ask before the same mistake is embedded in hardware and contracts.
Major section
IoT Pitfalls Are System Mismatches
An IoT project usually fails when the product promise, the operating environment, and the support model do not match.
- The common failure pattern is not "the sensor was bad"; it is that the surrounding system was designed as if deployment conditions would stay as tidy as the lab bench.
Major section
IoT Pitfalls Are System Mismatches (continued)
A smart-home device that depends on one vendor cloud has an ownership and interoperability risk.
- A factory sensor that cannot buffer data during WAN loss has an operations risk.
- A health or location product that collects more data than it needs has a privacy and trust risk.
- Lifecycle mismatch: The device ships without a funded plan for batteries, SIM contracts, certificates, CVE patches, OTA rollback, spare parts, support scripts, or replacement.
Major section
IoT Pitfalls Are System Mismatches (continued)
A city, retail, or logistics deployment that works only while a dashboard is open has an operational continuity risk, because the physical service still runs when the analytics view, broker, or API is unavailable.
- Environment mismatch: The design assumes clean Wi-Fi, stable power, dry enclosures, predictable radio coverage, or constant cloud reachability when the installation site does not provide them.
- Responsibility mismatch: Product, IT, security, operations, procurement, legal, and support teams do not agree who owns failures after installation.
- Every one is an assumption that survived the pilot because the pilot was small, watched and short.
Major section
Make Pitfalls Observable
A practical pitfall review turns vague risk into something the team can test.
- If the mechanism is not named, nobody can build a test, assign an owner, or budget the mitigation.
- At each point, require a small proof that the design survives the condition it claims to handle.
- For a factory gateway, prove that OPC UA or Modbus data keeps units, timestamps, quality flags, and asset ids intact when it is republished to MQTT or a historian.
Major section
Pitfalls Hide at Boundaries
A device may use TLS correctly but still be unsafe if every unit shares one certificate.
- A gateway may translate Modbus or OPC UA data into MQTT, but analytics can still fail if timestamps, units, quality flags, and retained-message behavior are inconsistent.
- Good architecture makes those boundary assumptions explicit.
- MQTT retained messages need a freshness policy.
Major section
Pitfalls Hide at Boundaries (continued)
Implementation details matter because many pitfalls are created by "almost right" integrations.
- A mobile app may show a friendly success screen even though the device command is only queued and has not reached the actuator.
- For industrial systems, separate safety interlocks from cloud automation so a dashboard outage cannot create an unsafe physical state.
- OPC UA nodes need stable namespace ownership.
Major section
Pitfalls Hide at Boundaries (continued)
For consumer and workplace systems, keep local control and privacy state visible so a product does not become unusable when the vendor API, mobile app, or subscription path changes.
- OTA systems need signed artifacts, staged rollout cohorts, rollback markers, and a way to prove which firmware is actually running.
- Privacy controls need data minimization, role-based access, deletion workflows, audit logs, and retention limits that match the product promise.
- A fleet dashboard may report "online" because the broker connection is alive while the sensor is stuck, uncalibrated, or publishing stale retained values.
Deck summary
Key takeaways
A building pilot works during a guided tour.
- The system should show what changed, who approved it, and which old state is no longer trusted.
- The deeper sections organize consumer, business, industrial, security, privacy, scaling, lock-in, and support pitfalls into questions that can change a design before contracts and hardware make change expensive.
- An IoT project usually fails when the product promise, the operating environment, and the support model do not match.
- A smart-home device that depends on one vendor cloud has an ownership and interoperability risk.
Retrieval practice
Recall check 1 of 5
Ada says: answer from memory, then check your reasoning.
Q1A factory sensor loses its network link. Which behavior best shows graceful degradation?
Show answer
Answer: B The link fault stays visible, records are buffered within capacity, and supported local monitoring uses fresh readings without depending on cloud commands.
Retrieval practice
Recall check 2 of 5
Ada says: answer from memory, then check your reasoning.
Q2A home camera dies with its vendor cloud, a factory logger drops readings during WAN loss, and a health app gathers needless location data. Which review maps the risks correctly?
Show answer
Answer: B Correct: each failure follows a different dependency the pilot may have missed.
Retrieval practice
Recall check 3 of 5
Ada says: answer from memory, then check your reasoning.
Q3A home sensor works only through its maker’s cloud. Which design review best addresses lock-in?
Show answer
Answer: C Export and replacement evidence shows whether the owner can leave the vendor.
Retrieval practice
Recall check 4 of 5
Ada says: answer from memory, then check your reasoning.
Q4A bench prototype publishes readings successfully. What should the team review before claiming deployment readiness?
Show answer
Answer: A The chapter distinguishes basic publishing from the surrounding deployed system.
Q5A smart-building risk register says only connectivity risk. What would make it testable?
Show answer
Answer: A The chapter requires a named mechanism, owner, and proof of intended fallback.
Retrieval practice
Recall check 5 of 5
Ada says: answer from memory, then check your reasoning.
Q6A fleet uses TLS but shares one credential across all devices. Which plan adds protection across the system?
Show answer
Answer: A Correct: separate identity, data access, update trust, and operational evidence protect distinct boundaries.
Print reference
Answers 1 of 2
Answer key.
- B · The link fault stays visible, records are buffered within capacity, and supported local monitoring uses fresh readings without depending on cloud commands.
- B · Correct: each failure follows a different dependency the pilot may have missed.
- C · Export and replacement evidence shows whether the owner can leave the vendor.
- A · The chapter distinguishes basic publishing from the surrounding deployed system.
- A · The chapter requires a named mechanism, owner, and proof of intended fallback.
Print reference
Answers 2 of 2
Answer key.
- A · Correct: separate identity, data access, update trust, and operational evidence protect distinct boundaries.