Chapters

6 IoT History: Forecast Boundaries

applications
iot
history

6.1 Start With the Decision

The two tracks in the linked figure in Part 2 make this failure mode inspectable.

6.2 Route Overview

This is part 2 of 2. Review IoT History: Early Lessons for the preceding evidence.

6.3 Learning Objectives

  • Test forecasts fail when boundaries move with a concrete scenario and pass criteria.
  • Calculate forecast error calculator from stated measurements and limits.

6.4 Chapter Roadmap

  • Forecasts Fail When Boundaries Move
  • Checkpoint: History as Evidence Filter
  • Why IoT History Matters
  • Sensor Squad Time Travel
  • The Time Machine Challenge
  • Key Words for Kids
  • Paradigm Blindness in Real Time
  • Why Incumbents Miss Shifts
  • Key Concepts
  • Minimum Viable Understanding
  • The Question AT&T Couldn’t Answer
  • McKinsey Mobile Forecast Error
  • Forecast Error Calculator
  • Checkpoint: Forecast Scale
  • Continue to Part 2

6.5 Forecasts Fail When Boundaries Move

Forecasting errors often happen when a model treats the product boundary as fixed. IoT changes that boundary: a device becomes part of a fleet, a protocol ecosystem, a cloud or edge pipeline, and a service workflow. Installed base, interoperability, regulation, cybersecurity, and data quality can matter as much as the device bill of materials. A forecast that only multiplies current buyers by current willingness-to-pay will miss a market that appears after the product changes the job, the data, or the service model.

LPWAN forecasts published during the mid-2010s are a useful historical case. Analysts expected rapid connection growth and divided the opportunity among infrastructure, agriculture, consumer, utility, transport, and industrial sectors. Preserve those charts as dated expectations, not as current market measurements. Their value is the hypothesis they expose: that long range, low device energy, and inexpensive small-message connectivity would unlock fleets that conventional cellular and short-range radios served poorly. Their weakness is that a connection forecast compresses several uncertain steps—coverage rollout, standards and operator support, module availability, procurement, installation, recurring fees, battery servicing, and the conversion of a connected asset into a useful workflow—into one rising curve.

A retrospective review therefore separates the forecast date, forecast horizon, unit of measure, technology boundary, geography, and sector definitions from the durable mechanism. It then compares like with like: forecast connections against observed connections, forecast revenue against observed revenue, and a forecast sector share against a consistently classified installed base. If those definitions or sources differ, the comparison is directional evidence rather than a score of whether the prediction was “right.” For a current LPWAN design, replace the old market total with present coverage, device, certification, service-life, and operations evidence. The historical chart can explain why investment accelerated; it cannot select today’s network.

Use log-scale thinking for cost and adoption, but do not assume cost decline solves everything. A LoRaWAN sensor, LTE-M tracker, Matter device, or OPC UA gateway still needs identity, provisioning, permissions, monitoring, update policy, and lifecycle ownership. Hardware cost can fall while total operating cost remains high because truck rolls, false alarms, certificate expiry, firmware updates, privacy review, and support tooling do not shrink at the same rate. The history lesson is incomplete unless the operating model is testable.

The two tracks in the linked figure in Part 2 make this failure mode inspectable. Compare the incumbent metrics on the expert-evaluation track with the new behaviours and markets on the actual-adoption track before deciding that an early prototype has no viable future.

The technical boundary also changes the measurement plan. A pilot should collect not only sensor readings but also missing data, duplicate messages, latency, battery drain, false positives, user overrides, maintenance outcomes, and support cases. If the proposal claims predictive maintenance, the evidence record needs fault labels, lead time, avoided downtime, and enough negative examples to show the model is not just noisy. If it claims workflow improvement, the record needs handoff time, alert fatigue, escalation accuracy, and whether staff actually changed behavior.

  • Adoption boundary: Early users may value a different outcome than mainstream buyers, so measure the segment separately.
  • System boundary: Network effects, standards, integrations, and support channels can create value the standalone device cannot show.
  • Trust boundary: Privacy, safety, security, and maintenance obligations can slow adoption even when the sensor cost falls.

A historical analogy is useful only when it leads to a testable operating model. The model should state the old metric, the new behavior, the technical contract, the adoption assumption, the evidence threshold, and the trigger for stopping or expanding the pilot. That keeps history from becoming a slogan and turns it into a sharper review tool.

AdaCheckpoint: History as Evidence Filter
  • You now know why a historical analogy should widen the question, then return to a specific signal, workflow, owner, and pilot threshold.
  • You can separate an old-frame objection from a useful engineering burden such as power, identity, integration, security, support, or trust.
  • You can ask whether a connected device creates a new action rather than merely adding sensors to an existing object.

6.6 Why IoT History Matters

When a brand-new invention appears, people often judge it by comparing it to something they already know. In the 1870s, a top engineer said telephones were pointless because “we have messenger boys.” In the 1980s, analysts predicted almost nobody would want a mobile phone because landlines already worked well.

In every case, the experts were wrong — not because they were bad at their jobs, but because they were thinking about the old way of doing things instead of imagining the new possibilities.

The simple version of what this chapter teaches:

  • People dismiss new technology because they compare it to what already exists. A smart light bulb seems pointless if you only think about turning lights on and off, but it can also save energy, improve health, and help elderly people live safely.
  • Predictions about technology adoption are often too low. A widely reported forecast put the year-2000 mobile market at 900,000 units. ITU recorded 738 million mobile-cellular subscriptions in 2000 — about 820 times the forecast, while noting that subscriptions are not the same as individual phones or users.
  • The most important uses of a new technology are usually ones nobody thought of at first. Text messaging, ride-sharing apps, and health monitoring on watches were never part of the original plans for mobile phones or smart watches.

This same pattern is happening right now with IoT. Many connected devices seem unnecessary today, but history tells us that the most valuable uses have not been invented yet.

6.7 Sensor Squad Time Travel

Imagine you could travel back in time with the Sensor Squad!

6.8 The Time Machine Challenge

One day, Temperature Terry found a magical time machine in the lab. “Let’s go back and see what people thought about new inventions!” he said. The whole Sensor Squad — Sammy, Light Lucy, Motion Marley, and the battery-management controller — jumped in!

Stop 1: The Year 1878 — They arrived in London and met a man named Sir William who worked for the Post Office. Sammy asked, “Sir, would you like a telephone to talk to people far away?” Sir William laughed: “Why would we need that? We have plenty of messenger boys to deliver messages!”

Lila whispered to Sammy, “He can’t imagine how useful phones will be because he’s only thinking about what he already knows!”

Stop 2: The Year 1983 — Next they visited a big phone company in America. Max showed them a mobile phone the size of a brick. “Imagine carrying this around!” The engineers shook their heads: “Why would anyone want to walk around with a phone? People have phones on their desks!”

Bella calculated: “The forecast says 900,000 units. But ITU recorded 738 MILLION mobile subscriptions in 2000! The actual-to-forecast ratio is about 820 to one.”

Stop 3: Back to Today — When they got home, Sammy looked at all the connected devices around them. “You know what’s funny?” he said. “Right now, people are saying ‘Why does a fridge need Wi-Fi?’ and ‘Why connect a light bulb?’ Some day, kids like you will wonder how anyone lived WITHOUT smart things!”

The Big Lesson: When someone says a new technology is “silly,” remember Sir William and his messenger boys. The best inventions create things nobody even imagined yet!

6.9 Key Words for Kids

WordWhat It Means
ParadigmA way of thinking about how things work (like “phones stay on desks”)
DisruptionWhen a new invention totally changes the old way of doing things
ForecastA guess about what will happen in the future
InnovationCreating something new and useful that didn’t exist before
AdoptionWhen lots of people start using a new thing

6.10 Paradigm Blindness in Real Time

The big picture: Experts consistently miss technology paradigm shifts because they evaluate new innovations using old frameworks. This “paradigm blindness” follows a predictable 4-stage pattern that repeats across every major technology shift.

Step-by-step breakdown:

  1. Stage 1: Anchoring to Current Behavior (Evaluation trap): Expert asks “Who among CURRENT users would want this worse product?” instead of “What would NEW users do with new capabilities?” - Real example: McKinsey asked “Who needs a $4,000 mobile phone?” instead of “What happens when it costs $200 in 15 years?”
  2. Stage 2: Measuring by Old Metrics (Comparison trap): Expert evaluates new tech by metrics that favor the old paradigm, missing what the new tech uniquely enables - Real example: Sir William Preece measured telephones against messenger boys (delivery speed), ignoring instant voice communication that messengers can’t provide
  3. Stage 3: Linear Extrapolation (Math trap): Expert assumes costs or adoption follow linear curves when they can follow much steeper S-curves - Reported example: a 900,000-unit mobile forecast compared with ITU’s 738 million subscriptions in 2000 (about an 820x actual-to-forecast ratio)
  4. Stage 4: Ignoring Second-Order Effects (Imagination trap): Expert evaluates direct use case only, missing emergent applications that create the real value - Real example: Mobile phones planned for voice calling, but SMS, mobile internet, app stores, ride-sharing, and mobile banking created 80%+ of the value

Why this matters: This pattern is happening RIGHT NOW with IoT. When someone dismisses “Why connect a light bulb?”, they’re anchoring to current behavior (flip switches), measuring by old metrics (lumens per watt), thinking linearly (cost won’t drop), and ignoring second-order effects (health monitoring via light usage patterns, Li-Fi communication, emergency evacuation guidance). The connected bulb that seems silly today becomes essential infrastructure tomorrow.

6.11 Why Incumbents Miss Shifts

Time: ~15 min | Level: Intermediate | ID: P03.C01.HIST

Key Concepts

  • IoT Architecture: Layered model comprising perception, network, and application tiers defining how sensors, gateways, and cloud services interact.
  • Edge Computing: Processing data close to the sensor source to reduce latency, bandwidth costs, and cloud dependency.
  • Telemetry: Time-stamped sensor readings transmitted from a device to a cloud or edge platform for storage, analysis, and visualisation.
  • Protocol Stack: Set of communication protocols layered from physical radio to application message format that devices must implement to interoperate.
  • Device Lifecycle: Stages from manufacture through provisioning, operation, maintenance, and decommissioning that IoT management platforms must support.
  • Security Hardening: Process of reducing attack surface by disabling unused services, applying least-privilege access, and enabling encrypted communications.
  • Scalability: System property ensuring performance and cost remain acceptable as the number of connected devices grows from prototype to mass deployment.

Understanding IoT’s potential requires learning from history. Every major technology shift has caught established players off guard — and the pattern repeats with striking consistency. The question that seems obvious in retrospect was once dismissed as absurd.

6.12 Minimum Viable Understanding

Core Concept: Established experts can underestimate paradigm-shifting technologies because they evaluate new innovations using old frameworks. A widely reported AT&T/McKinsey forecast put the year-2000 mobile market at 900,000 units; ITU later recorded 738 million mobile-cellular subscriptions for 2000. This example illustrates “paradigm blindness,” but the two measures must be labelled accurately.

Why It Matters: When evaluating IoT opportunities, the key question is not “Does this solve existing problems better?” but “What new problems can this solve that were previously impossible?” New technologies enable new behaviors that create entirely new markets — markets that cannot be predicted by analyzing existing ones.

Key Takeaway: Expertise in the current paradigm can blind you to the next one. IoT’s value often emerges from use cases that seem absurd today, just as “walking around with a phone” seemed absurd in 1983. The most disruptive IoT applications are likely ones we cannot yet imagine.

6.13 The Question AT&T Couldn’t Answer

In the early 1980s, AT&T commissioned McKinsey & Company to forecast the mobile phone market. McKinsey’s analysts, working with AT&T’s best technologists, famously predicted that by the year 2000, the total worldwide market for mobile phones would be… 900,000 units.

The comparison used here is ITU’s 738 million mobile-cellular subscriptions in 2000. A subscription is an active service record, not necessarily one unique phone or person.

The actual-to-forecast ratio is about 820x.

6.14 McKinsey Mobile Forecast Error

1980s forecast vs 2000 reality:

  • McKinsey prediction for 2000: 900,000 mobile phones.
  • ITU’s 2000 observation: 738,000,000 mobile-cellular subscriptions.
  • Multiplicative factor: 738M / 0.9M = 820, so the observation is about 820 times the forecast.
  • Relative error: (738M - 0.9M) / 0.9M = 819, or 81,900%. Do not label this percentage-error calculation as an 819x factor.

Root causes: (1) Anchored to $4,000 price instead of $200 trajectory, (2) Linear adoption curve instead of exponential S-curve, (3) Missed 80%+ value from SMS/apps/internet beyond voice.

IoT parallel: Forecasters predicting 50B IoT devices (2025) risk similar errors if they assume current $50 sensor prices instead of $2 trajectories and miss emergent applications beyond monitoring.

6.15 Forecast Error Calculator

Use this calculator to explore how forecast errors compound. Try the McKinsey mobile phone example, or plug in your own IoT forecasts.

Try these examples:

  • Reported mobile forecast: 900,000 units; ITU observation: 738,000,000 subscriptions
  • IBM’s “5 computers” (1943): Predicted 5, Actual >5,000,000,000
  • Your own IoT forecast: What error multiplier would surprise you?

AdaCheckpoint: Forecast Scale
  • You now know how the chapter gets from a 900,000-unit forecast and 738,000,000 observed subscriptions to an 820x actual-to-forecast ratio, and why that differs from relative percentage error.
  • You can explain why a large forecast miss can come from the market boundary moving, not only from bad arithmetic.
  • You can use the calculator as a review tool before accepting a linear IoT adoption forecast.

The fundamental problem? They couldn’t answer a simple question that seemed ridiculous at the time:

“Why would anyone want to walk around with a phone?”

This wasn’t a failure of analysis — it was a failure of imagination. The analysts correctly understood the technology. They correctly understood the costs. What they couldn’t see was that human behavior would fundamentally change once the technology became available. They extrapolated from the behavior of existing telephone users rather than imagining entirely new users and entirely new uses.

The skepticism toward new communication paradigms extends even further back. When the telephone was first demonstrated in Britain, Sir William Preece, Chief Engineer of the British Post Office, famously declared:

6.16 Continue to Part 2

Continue with IoT History: Paradigm Shifts and Adoption.

6.17 Continue Your Route

This final part closes the route from Forecasts Fail When Boundaries Move through Continue to Part 2. Return to IoT History: Early Lessons or continue from the applications module index.