Imagine explaining a new IoT proposal to someone who has seen several technology waves overpromised before. This chapter uses history as a filter: follow how earlier computing shifts changed work, then ask which IoT claims are durable enough to survive skepticism, timing, and adoption friction.
Chapter Roadmap
First, use history as a product-review tool rather than as proof that every connected object deserves to exist.
Then, examine the telephone, mobile-phone, internet, smart-watch, and IoT examples as repeated old-frame evaluation failures.
Next, test the adoption and cost calculators so forecast error, S-curve timing, and cost trajectory become concrete.
Finally, apply the SHIFT framework to reframe a dismissed IoT proposal around outcomes, evidence, and competitive risk.
Checkpoint callouts pause the historical flow; deep-dive calculators and quizzes can be treated as verification stops during a first pass.
3.2 Learning Objectives
By the end of this chapter, you will be able to:
Diagnose paradigm blindness: Explain why experts miss technology shifts and how cognitive biases systematically distort technology forecasting
Apply historical lessons: Evaluate IoT opportunities using historical patterns, analogies, and the SHIFT framework
Demonstrate Innovator’s Dilemma awareness: Reframe IoT proposals to address organizational skepticism and internal resistance using value-first language
Assess emerging use cases: Justify why today’s dismissed applications may become essential infrastructure based on historical precedent
Calculate forecast errors: Analyze why technology adoption forecasts consistently underestimate paradigm shifts by orders of magnitude
This chapter assumes no prior technical knowledge. Familiarity with basic business concepts (markets, competition, innovation) and a general awareness of technology history (mobile phones, the internet) will help you get the most from the examples. If you are new to IoT, consider reading IoT Introduction first.
3.5 History Is a Pattern-Checking Tool
History does not prove that every connected product will become important. It helps you notice when a team is using old assumptions to judge a new capability. The useful lesson is not “skeptics are always wrong”; it is “ask what becomes possible when sensing, communication, software, and cost curves change together.” Many forecasting failures happen because experts evaluate the first version of a technology against the job it seems to replace. They ask whether a mobile phone is better than a landline, whether online shopping is better than a store visit, or whether a sensor-equipped pump is better than a well-built pump. The better question is whether the new system can create different behavior.
For IoT, that means looking beyond the first visible feature. A connected pump is not valuable because it has sensors. It becomes valuable if vibration, temperature, pressure, runtime, maintenance logs, and operating context support earlier fault detection, safer scheduling, better parts planning, or a different service contract. A smart hospital bed is not valuable because a bed “needs Wi-Fi.” It becomes valuable if continuous position, pressure, occupancy, and vital-sign context reduce pressure injuries, detect deterioration earlier, or let nurses move from routine checks to exception-based response.
The chapter uses historical examples as a discipline for asking better product questions. The telephone was not only a faster messenger. Mobile phones were not only portable landlines. The web was not only a document store for academics. IoT is not only “put a chip in the object.” In each case, the hard part is seeing the second-order behavior before the market has normalized it. History gives you language for that uncertainty without turning it into hype.
Old-frame question: “Who asked for this device to be connected?”
History-aware question: “What decision or behavior becomes possible only after the device can sense and report state?”
Engineering question: “What has to be true about power, cost, reliability, security, and operations for that new behavior to last?”
A history-aware proposal should therefore name both the promise and the burden. If the new behavior requires reliable telemetry, identity, integration, analytics, security review, and support staffing, say so. If the value depends on uncommon adoption, regulatory approval, workflow change, or trust, say that too. History is most useful when it prevents both premature dismissal and shallow excitement.
3.6 Separate Analogy from Proof
A good IoT proposal uses history to widen the question, then returns to concrete product work. Do not argue that a sensor idea must succeed because mobile phones, SMS, web search, or app stores were underestimated. Instead, use the analogy to identify the blind spot, then test the specific IoT mechanism. If the historical pattern is “analysts measured the old job,” your proposal should show the new job. If the pattern is “incumbents protected a profitable workflow,” your proposal should show which workflow changes and who benefits.
For example, an industrial monitoring proposal should name the measured signal, the fault mode, the sampling cadence, the connectivity path, the decision owner, and the maintenance action. A smart-building proposal should name occupancy sensing, control authority, privacy limits, fallback operation, and integration with systems such as BACnet, KNX, Matter, MQTT, or a building-management platform. A hospital-bed proposal should name the clinical workflow, alarm thresholds, nurse escalation path, electronic health record boundary, patient-consent limits, and what happens when the network or sensor fails.
The practitioner test is evidence-driven. Start with the incumbent metric: purchase price, uptime, manual labor, inspection frequency, energy use, claims cost, or patient safety. Then state the new behavior in operational terms: earlier warning, automatic dispatch, usage-based billing, remote certification, closed-loop control, or exception management. Finally, list the adoption friction that history cannot erase: battery service, install labor, cybersecurity review, data ownership, union or clinical workflow, procurement rules, interoperability, training, and support handoff.
Identify the incumbent metric. Find what the organization currently optimizes: purchase cost, manual inspection, device uptime, energy bill, compliance, or customer support volume.
Name the new behavior. State what people, software, or operations teams can do after sensing and connectivity exist.
Check adoption friction. Include procurement, installation labor, battery replacement, security approval, data ownership, training, and support burden.
When presenting the case, avoid the lazy version of history. “Experts were wrong before” is not proof. A stronger argument is: “The old evaluation metric misses this new action; here is the smallest pilot that can prove whether the new action matters.” That pilot might instrument ten pumps for bearing-fault signatures, monitor one hospital ward for pressure-injury reduction, or connect one refrigerated route to compare manual inspection against telemetry-backed exception handling.
3.7 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.
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.
Figure 3.1: Paradigm blindness has two tracks: experts often compare a new system to the incumbent job while adoption grows around new behaviors, new markets, and reorganized workflows.
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.
Checkpoint: 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.
3.8 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 almost always too low. Experts predicted 900,000 mobile phones by the year 2000. The real number was over 700 million – almost a thousand times more.
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.
3.9 Sensor Squad Time Travel
Imagine you could travel back in time with the Sensor Squad!
3.10 The Time Machine Challenge
One day, Sammy the Sensor 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, Lila the Light Sensor, Max the Motion Detector, and Bella the Battery Manager – 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: “They think only 900,000 people will want these. But by 2000, over 700 MILLION people will have one! They’re off by a thousand times!”
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!
3.11 Key Words for Kids
Word
What It Means
Paradigm
A way of thinking about how things work (like “phones stay on desks”)
Disruption
When a new invention totally changes the old way of doing things
Forecast
A guess about what will happen in the future
Innovation
Creating something new and useful that didn’t exist before
Adoption
When lots of people start using a new thing
3.12 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:
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?”
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
Stage 3: Linear Extrapolation (Math trap): Expert assumes costs/adoption follow linear curves when they’re actually exponential, underestimating by 10-1000x - Real example: McKinsey’s 900,000 mobile phone forecast vs. 700 million actual (1000x error from linear thinking)
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.
3.13 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.
3.14 Minimum Viable Understanding
Core Concept: Established experts consistently underestimate paradigm-shifting technologies because they evaluate new innovations using old frameworks. AT&T predicted 900,000 mobile phones by 2000; the actual number exceeded 700 million. This “paradigm blindness” has repeated in every major technology shift for over 140 years.
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.
3.15 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 actual number? Over 700 million.
McKinsey was off by a factor of nearly 1,000x.
3.16 McKinsey Mobile Forecast Error
1980s forecast vs 2000 reality:
McKinsey prediction for 2000: 900,000 mobile phones.
Actual market in 2000: more than 700,000,000 mobile phones.
Forecast error: about a 777x underestimate, because (700M - 0.9M) / 0.9M is roughly 777.
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.
3.17 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.
McKinsey mobile phones: Predicted 900,000, Actual 700,000,000
IBM’s “5 computers” (1943): Predicted 5, Actual >5,000,000,000
Your own IoT forecast: What error multiplier would surprise you?
Checkpoint: Forecast Scale
You now know how the chapter gets from 900,000 predicted phones and more than 700,000,000 actual phones to a roughly 777x underestimate.
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:
3.18 Sir William Preece, 1878
“The Americans have need of the telephone, but we do not. We have plenty of messenger boys.”
This wasn’t ignorance – it was expertise applied to the wrong paradigm. Preece was a brilliant engineer who understood telegraphy perfectly. His error was evaluating a paradigm-shifting technology through the lens of the paradigm it would replace. He compared the telephone to telegraph delivery (where Britain excelled) rather than imagining how instant voice communication would create entirely new social and business patterns.
One useful way to frame that error is to look one step earlier than the telephone. Spoken language made coordination immediate but local. Gutenberg’s movable type made knowledge durable, cheap to copy, and able to travel without the speaker. Telephony then made conversation remote and synchronous. Each transition changed both the medium and the behavior around it. For IoT, the same discipline matters: do not judge a connected object only by the old manual interaction. Ask what changes when status can be sensed, copied, routed, and acted on without waiting for a person to be physically present.
The birth of the telephone is also a systems lesson, not only an inventor story. Alexander Graham Bell’s early instrument turned voice pressure into a changing electrical signal; practical service then needed a transmitter, receiver, battery, local loop, switching, and eventually long-distance operating rules. A tin-can telephone can show the intuition that a medium carries a varying signal, but the Bell System became valuable when that signal path was reliable enough for households and firms to organize around it. The same pattern continued as printed media moved into digital readers: the object still looked like “a book” at first, but storage, search, synchronization, and network delivery changed the surrounding service.
The control-plane lesson appears when the network has more than two people. If every caller needed a direct line to every other caller, the number of pairs would grow as N * (N - 1) / 2; a neighborhood of 1,000 people would need 499,500 pair connections. Telephone exchanges changed the shape of the problem. A switchboard or central office let each subscriber attach to a smaller shared switching system, where an operator, a Strowger step-by-step switch, a crossbar switch, and later stored-program control selected the path for the call. That is the old telephony version of separating coordination from payload: control logic decides who should be connected, while the established circuit carries the conversation. Modern IoT systems repeat the pattern whenever identity, routing, authorization, and fleet policy must scale without giving every device a permanent private path to every other device.
The data-plane lesson appears after that coordination starts to work. Early telephone adoption grew from 49,000 lines in 1890 to 600,000 in 1900, 2.2 million in 1905, and 5.8 million in 1910, so the payload path had to become an engineered geography rather than a demonstration circuit. Metallic-circuit route maps, interurban trunks, transcontinental lines, and transatlantic cable landing points show the hidden work behind “talking at a distance”: wires, repeaters, amplifiers, rights-of-way, power, landing stations, repair practice, and operational monitoring. Lee de Forest’s Audion mattered in that story because amplification changed how far a weak signal could travel before the conversation became unusable. For IoT, the analogy is practical: a clever control service is not enough if gateways, links, brokers, queues, storage, and backhaul cannot carry telemetry and commands reliably at the scale adoption creates.
Broadcast networks changed the shape again. A switched telephone call connected selected endpoints; broadcast radio sent one transmission to every receiver in range. That required both invention and industry. De Forest’s Audion made weak radio signals more usable, Edwin Armstrong’s feedback and regenerative receiver work sharpened amplification and tuning, and later FM showed that moving information by frequency variation could improve noise behavior compared with amplitude-only thinking. David Sarnoff and RCA turned that technical base into a mass-market receiver, programming, and spectrum business where the network’s value depended on useful content, reliable reception, and operating scale. The IoT lesson is not that sensor networks are broadcast businesses. It is that shared radio systems need the same layered discipline: physical signal quality, channel planning, receiver behavior, gateway capacity, message priority, and application value all have to line up before a fleet can feel like infrastructure rather than a clever demo.
Television made that network-and-content dependency visible at national scale. RCA, NBC, CBS, ABC, PBS, and their affiliates were not valuable because a transmitter existed in isolation; they were valuable because receivers, studio cameras, live events, programming schedules, rights, advertisers, and long-haul distribution could be aligned. A 1950 television network map compared with later national coverage shows the same adoption curve as many connected systems: first the technical reach is sparse, then the service becomes durable when the content and operating model justify more infrastructure. For IoT, “content” may be telemetry, alarms, state estimates, or control actions, but the rule is similar: a network that moves data without a valuable use case remains a transport demo.
AT&T and Bell Labs show the next layer of the same history. Sampling turned continuous speech and sensor signals into digital records; speech coding made voice small enough for constrained links; Claude Shannon’s information theory gave engineers a language for capacity, noise, and uncertainty; the transistor made electronic switching and amplification compact; and C plus Unix made portable systems software practical. The Bell Labs transistor story, from Bardeen, Brattain, and Shockley to practical switching circuits, is also the bridge from room-scale electronic equipment to minicomputers, microcontrollers, phones, cameras, radios, and other endpoint devices. Those topics now live in separate technical chapters, but historically they belonged to one infrastructure problem: how to turn physical signals into reliable, computable, networked services.
That story also has an institutional side. Theodore Vail’s regulated-monopoly Bell System argued that a telephone network became more useful when service was universal, reliable, and centrally coordinated; the same logic gave AT&T stable revenue and obligations that could support long-horizon Bell Labs research. The later breakup of AT&T changed that industrial structure, but not the lesson for IoT infrastructure: network value, regulatory constraints, operating scale, and research investment are coupled. A fleet platform can fail if it treats connectivity as only a technical feature while ignoring who funds the shared infrastructure, who governs access, and how the network keeps improving.
The breakup was not a single switch flipped overnight. The 1914 Kingsbury Agreement connected AT&T long-distance service to independent exchanges, the 1921 Willis-Graham Act allowed more local consolidation under regulated-service logic, and the Justice Department’s 1949 Western Electric case eventually kept AT&T out of the general computer business while protecting its telephone-equipment role. Carterfone in 1968 changed the attachment boundary by allowing non-AT&T devices on the network, and the 1974 antitrust case led to the 1984 divestiture. Later recombinations among Bell Atlantic, NYNEX, GTE, MCI, US West, Qwest, Ameritech, Southwestern Bell, Pacific Telesis, BellSouth, Verizon, SBC, and the new AT&T show that network markets keep reorganizing even after a formal breakup. For IoT, that history is a warning: ownership boundaries, device-attachment rules, platform access, and regulatory bargains can shape architecture as much as a radio or protocol choice.
Bell Labs’ research impact also came from hard infrastructure constraints, not from research being detached from operations. Materials science, solid-state electronics, microwave and optical communication, Unix and C, CCD imaging, laser cooling, quantum-effect work, broadband copper and optical access, cellular systems, heterogeneous networks, and cloud-network ideas all answered problems created by real communication scale. The practical lesson is that a strong IoT research program should be tied to concrete “10x” system challenges: cheaper deployment, lower power, better capacity, safer attachment, stronger interoperability, or more reliable operation under messy field conditions.
C and Unix are part of that same platform history. Ken Thompson and Dennis Ritchie built Unix at Bell Labs, Ritchie created C, and Brian Kernighan and Ritchie’s The C Programming Language helped make systems programming portable enough to travel across machines. AT&T Unix System V, BSD Unix, Linux, Android, macOS, and iOS are not one identical operating system, but they show how a small set of abstractions – files, processes, permissions, pipes, sockets, and portable C interfaces – became the software substrate for servers, gateways, phones, and development boards. A Qualcomm DragonBoard 410c or similar embedded Linux board is therefore not just “a board with chips”; it is the transistor, operating-system, compiler, and network stack story condensed into a bench-top IoT endpoint or gateway prototype.
That history also explains why IoT has had several names before the current shorthand settled. Mark Weiser’s ubiquitous-computing work at Xerox PARC framed the goal as computing embedded into everyday environments until it feels natural. Neil Gershenfeld’s MIT Media Lab work and Kevin Ashton’s Auto-ID framing shifted attention from people browsing the Web to physical things using networked identifiers and data. The ITU’s 2005 Internet report then described networked objects such as appliances, vehicles, RFID tags, and sensors as part of a new communication era. The European Commission’s 2009 action plan emphasized objects with identifiers, IP reachability, sensors, and actuators inside larger systems. Cisco’s later “Internet of Everything” language widened the lens again to people, process, data, and things. For engineering review, these labels are less important than the boundary they keep repeating: small devices, low power, sensing or actuation, wireless communication, internet reachability, programmability, and some local or system-level autonomy must work together before the idea becomes a dependable product.
3.19 A Pattern Across Centuries
The dismissal of transformative technology is not limited to telephones and mobile phones. Consider these additional examples that reveal the depth and universality of paradigm blindness:
Year
Speaker
Quote
What Actually Happened
1876
Western Union memo
“The telephone has too many shortcomings to be seriously considered as a means of communication”
Telephones became the backbone of global communication
1943
Thomas Watson, IBM Chair
“I think there is a world market for maybe five computers”
Over 5 billion people now use personal computing devices
1995
Robert Metcalfe, Ethernet inventor
“The Internet will soon go spectacularly supernova and catastrophically collapse in 1996”
The Internet became the foundation of the modern economy
2007
Steve Ballmer, Microsoft CEO
“There’s no chance that the iPhone is going to get any significant market share”
Apple became the world’s most valuable company, largely through iPhone
Each case follows the same pattern: an expert with deep knowledge of the current system fails to anticipate how a new technology will create entirely new categories of use.
3.20 Telephony to IoT Evolution
The evolution from telephony to IoT reveals a pattern of expanding connectivity that established players consistently underestimate:
The same dismissal pattern repeats: experts judge new connectivity by the old job, while adoption grows around new behavior.
The Pattern of Dismissal:
Era
Dismissive Question
Reality That Emerged
Telephone (1876)
“We have messenger boys”
Instant voice communication became essential infrastructure
Mobile (1983)
“Why walk with a phone?”
5+ billion people carry phones everywhere, all the time
Internet (1995)
“It’s just for academics”
Global commerce, communication, and culture transformed
Smartphones (2007)
“Who needs email on a phone?”
Smartphones became primary computing devices for billions
IoT (2015+)
“Why connect a light bulb?”
Connected devices outnumber people 10-to-1
3.21 Why Experts Miss Paradigm Shifts
The following diagram illustrates the two parallel tracks that occur when a new technology emerges. Experts evaluate it using existing frameworks (left path), while the technology actually creates entirely new possibilities (right path). Both paths converge at “Paradigm Blindness” – the gap between expert predictions and actual outcomes.
Paradigm blindness separates the expert’s old-frame evaluation from the market’s new behavior path.
3.22 The Anatomy of Paradigm Blindness
Understanding why experts consistently fail at predicting paradigm shifts reveals five cognitive mechanisms:
1. Anchoring to Existing Behavior
Forecasters assume people will continue behaving as they currently do. McKinsey asked “Who among current telephone users would pay $4,000 for a worse phone?” instead of asking “What would 100 million NEW users do with portable communication?”
2. Linear Extrapolation of Exponential Change
Technology costs drop exponentially (Moore’s Law), but human minds think linearly. A $4,000 phone in 1983 became a $200 phone by 1998 and a $50 phone by 2005. Each price point unlocked an entirely new market segment.
3. Measuring New Technology by Old Metrics
Sir William Preece measured the telephone against the telegraph – speed of message delivery. He didn’t measure what the telephone uniquely enabled: real-time conversation, emotional connection, immediate coordination. Similarly, IoT critics measure a “smart light bulb” against a regular light bulb’s ability to produce light, missing everything else it enables.
4. Ignoring Second-Order Effects
Mobile phones didn’t just enable mobile calling. They enabled SMS (not planned), which enabled mobile internet (not planned), which enabled app stores (not planned), which enabled ride-sharing, food delivery, mobile banking, and social media – none of which were imagined in 1983.
The revenue shift is a useful warning for IoT forecasts. Voice was the obvious paid service, but tiny text payloads could be priced, bundled, broadcast to many recipients, and later replaced or extended by Internet-native chat, feeds, video, and streaming services. Once phones became software platforms, value moved from the carrier’s voice minute to application ecosystems, operating systems, developer tools, content libraries, and user data. IoT platforms can follow the same pattern: the first connected feature may not be where the durable value or risk finally sits.
5. Survivorship Bias in Expert Selection
The experts consulted are always those who succeeded in the current paradigm. Their success makes them the least likely to see the next paradigm clearly, because they have the most to lose from it.
Checkpoint: Blindness Mechanisms
You now know the five mechanisms this chapter uses to diagnose paradigm blindness: anchoring, linear extrapolation, old metrics, second-order effects, and survivorship bias.
You can connect each mechanism to a concrete IoT review question instead of treating skepticism as automatically wrong.
You can distinguish a weak “experts were wrong before” argument from a stronger claim that names the old metric and the new behavior.
3.23 Historical Lesson Pitfalls
Learning from history is essential, but misapplying these lessons can be just as dangerous as ignoring them. Watch out for these traps:
Pitfall 1: “Everything is the next telephone” fallacy. Not every new technology is a paradigm shift. Some IoT products genuinely are solutions looking for a problem. History shows that paradigm shifts change fundamental human behavior – if a proposed IoT application does not enable a new behavior or solve a previously impossible problem, skepticism may be warranted.
Pitfall 2: Confusing technological possibility with market viability. Just because something can be connected does not mean it should be. A connected toothbrush that tracks brushing habits has technological merit, but the market may remain niche if the data it generates does not lead to meaningful health outcomes or behavior changes. Always ask: “What decision does this data enable that was not possible before?”
Pitfall 3: Ignoring the “hype cycle” timing problem. Even technologies that eventually succeed often go through a painful “trough of disillusionment” (Gartner’s term). Early IoT adopters in 2014-2016 faced real failures – unreliable connectivity, no interoperability standards, and poor security. Acknowledging these real challenges is not paradigm blindness; it is prudent engineering.
Pitfall 4: Assuming cost curves will solve everything. While costs do fall exponentially over time, some IoT applications face barriers that are not primarily about cost – regulatory approval, privacy concerns, infrastructure requirements, and user trust can delay adoption regardless of how cheap sensors become.
Pitfall 5: Overweighting individual anecdotes. The fact that one expert was wrong about telephones does not mean every expert dismissing a specific IoT application is wrong. Evaluate each case on its own merits using the five cognitive mechanisms above, rather than simply pointing to historical examples as proof that all skeptics are wrong.
3.24 Innovator’s Dilemma in IoT
Clayton Christensen’s “Innovator’s Dilemma” (1997) explains why successful companies fail to adopt disruptive technologies. His framework is directly applicable to IoT adoption challenges:
1. Expertise Becomes a Liability
AT&T’s deep knowledge of landline infrastructure made wireless seem inferior
Telecom engineers optimized for voice quality, not mobility
Their expertise in the old paradigm blinded them to the new one
IoT parallel: Manufacturing companies optimized for product reliability may dismiss sensor data as “unnecessary complexity”
2. Customers Don’t Ask for Disruption
In 1983, no AT&T customer was asking for a mobile phone
Customers rarely ask for paradigm-shifting products – they ask for better versions of what they already have
“Faster horses, not automobiles” (attributed to Henry Ford)
IoT parallel: Pump customers ask for more reliable pumps, not sensor-equipped pumps – until a competitor offers predictive maintenance
3. The Math Doesn’t Work (Initially)
Early mobile phones: $4,000, poor quality, 30-minute battery
Early IoT sensors: expensive, unreliable, no clear ROI
Incumbents correctly calculate that the new technology is inferior – for existing use cases
IoT parallel: A $50 sensor on a $500 pump seems like a 10% cost increase for uncertain benefit – until the sensor prevents a $50,000 production shutdown
4. New Use Cases Emerge Unexpectedly
Mobile phones enabled SMS (unexpected killer app)
Smartphones enabled ride-sharing, social media, mobile payments
IoT is enabling predictive maintenance, precision agriculture, remote healthcare
IoT parallel: Smart meters were deployed for billing accuracy, then became grid optimization tools, then enabled demand-response programs worth billions
The Lesson for IoT Professionals:
When evaluating IoT applications, ask not “Does this solve existing problems better?” but rather “What new problems can this solve that were previously impossible?”
The connected light bulb seems silly when compared to a regular light bulb. It becomes revolutionary when it enables:
Automated circadian lighting that improves sleep quality by 23% (Harvard Medical School study)
Occupancy-based energy savings of 30-60% across commercial buildings
Emergency lighting that guides evacuation routes dynamically
Health monitoring through light usage patterns for elderly care
Li-Fi data communication at speeds up to 224 Gbps
3.25 The IoT Adoption S-Curve
Technology adoption follows a predictable S-curve pattern, but the timing and steepness of the curve are consistently underestimated. Understanding where IoT sits on this curve helps frame both opportunities and risks:
IoT segments sit at different points on the adoption curve; integration, policy, and trust can slow even cheap technologies.
Industrial IoT: Years 10-12, adoption ~60% (Late Majority)
Smart Home: Years 8-10, adoption ~35% (Early Majority)
Smart Agriculture: Years 4-6, adoption ~12% (Early Adopters)
3.27 Today’s IoT Questions
Just as “Why walk with a phone?” seemed reasonable in 1983, today’s skeptics ask:
“Why does a refrigerator need Wi-Fi?” –> Automated grocery ordering, food waste reduction (saves 30% of household food waste), energy optimization, recall notifications, dietary tracking
“Why connect a light bulb?” –> Circadian health, security presence simulation, energy savings (30-60%), accessibility for disabled users, Li-Fi communication
“Why put sensors in concrete?” –> Structural health monitoring saves $500K+ per bridge annually, predictive maintenance prevents catastrophic failures, carbon curing optimization
Deep knowledge of current systems can blind you to new possibilities
Behavior changes with technology
Connected devices will change how people interact with the physical world
New use cases emerge
The killer app for IoT may not exist yet – just like SMS didn’t exist in 1983
Second-order effects dominate
The most valuable outcomes are 2-3 steps removed from the initial use case
Cost curves are exponential
What seems economically impractical today becomes trivially cheap within a decade
3.30 Smart Watch Journey
The smart watch story perfectly illustrates how paradigm blindness works – and how it eventually gets overcome.
Phase 1: Dismissal (2013-2014)
When the first Android Wear and Samsung Galaxy Gear watches launched, industry experts declared:
“Phones already tell time” (evaluating by old paradigm)
“Battery life is terrible” (measuring by watch standards)
“The screen is too small to be useful” (comparing to phone screens)
Phase 2: Apple Watch Launch and Skepticism (2015)
Even after Apple entered the market, critics focused on what smart watches did worse than existing products rather than what they uniquely enabled. Swiss watch executives declared Apple Watch would not affect their market.
Phase 3: The Unexpected Killer App (2018-2020)
The breakthrough wasn’t telling time, notifications, or even fitness tracking. It was health monitoring:
Apple Watch detected atrial fibrillation, saving lives
Fall detection automatically called emergency services for elderly users
ECG capability received FDA clearance (first for a consumer device)
None of these use cases were in the original product pitch. They emerged from the combination of sensors + connectivity + processing that only a smart watch on a wrist could provide.
Phase 4: Essential Health Infrastructure (2022-2026)
By 2026, smart watches have become medical devices. Insurance companies offer discounts for wearers. Hospitals integrate smart watch data into patient records. The “silly watch that tells time worse than a Rolex” became a life-saving health monitor.
The IoT Lesson: The value of IoT devices rarely comes from doing existing things better. It comes from enabling entirely new capabilities that were impossible before connectivity.
3.31 Learning from History
Scenario: Your company manufactures traditional industrial pumps. A junior engineer proposes adding IoT sensors to monitor vibration, temperature, and flow rate. The VP of Sales dismisses the idea: “Our customers want reliable pumps, not gadgets. They’ve never asked for this.”
Questions to Consider:
Which historical pattern does the VP’s response mirror?
Answer: This mirrors both “We have messenger boys” (evaluating new technology by old paradigm standards) and “No customer asked for a mobile phone” (customers don’t ask for paradigm shifts). The VP is anchored to existing customer behavior.
What new use cases might emerge that aren’t obvious today?
Answer: Predictive maintenance (pump signals failure before it happens), usage-based billing (pay per gallon pumped), performance optimization (adjust pump settings based on conditions), fleet management (monitor hundreds of pumps remotely), warranty validation (prove operating conditions were within spec), energy optimization (pumps account for 20% of industrial electricity).
What would happen if a competitor added these sensors first?
Answer: They could offer predictive maintenance contracts, reduce customer downtime by 25-40%, build data moats that enable continuous improvement, and potentially shift from selling pumps to selling “pumping-as-a-service” – a recurring revenue model worth 3-5x the pump sale price.
How might you reframe the proposal to address the VP’s concerns?
Answer: Frame IoT not as a “gadget” but as a reliability enhancement – the sensors don’t replace pump quality, they protect the customer’s investment by predicting failures and optimizing performance. Start with a pilot program to generate data on actual benefits. Emphasize competitive threat: “If we don’t offer this, our competitors will.”
The History Lesson Applied: AT&T’s landline expertise made them dismiss mobile. Your pump expertise could make you dismiss IoT. The question isn’t whether your current customers are asking for IoT – it’s whether your future customers (or your competitors’ customers) will expect it.
Checkpoint: Reframing Resistance
You now know how the pump scenario turns a customer-request objection into a predictive-maintenance, usage-based billing, and fleet-service question.
You can describe the incumbent risk without fabricating demand: current customers may not ask for the new category before competitors prove it.
You can carry that framing into the matching, ordering, label, and code quizzes as an evidence-first argument.
Paradigm blindness is a consistent and documented pattern where experts evaluate new technologies using old frameworks, leading to massive forecast errors (McKinsey’s 1,000x miss on mobile phones, Sir William Preece dismissing telephones)
Five cognitive mechanisms drive paradigm blindness: anchoring to existing behavior, linear extrapolation of exponential change, measuring new tech by old metrics, ignoring second-order effects, and survivorship bias in expert selection
The Innovator’s Dilemma explains why successful companies systematically fail to adopt disruptive technologies – their existing customers, revenue streams, and expertise bias them against disruption
Technology adoption follows an S-curve pattern, and IoT segments are at different phases: IIoT and wearable health are accelerating, while smart agriculture and smart cities are transitioning from skepticism to early adoption
New use cases emerge unexpectedly – SMS, ride-sharing, and smart watch health monitoring were never in original product pitches; the most valuable IoT applications likely don’t exist yet
Reframing IoT proposals from “adding gadgets” to “enabling new capabilities” helps overcome organizational resistance to paradigm shifts
3.40 Practical Framework
When evaluating any IoT opportunity, use the SHIFT framework:
Wearables –> continuous health awareness –> preventive medicine
I - Impossible becomes possible
What couldn’t you do before?
Embedded concrete sensors –> real-time structural health monitoring
F - Forecast anchoring
Are you anchoring to current behavior?
“Nobody asked for it” = “Nobody asked for mobile phones in 1983”
T - Technology cost trajectory
What happens at 10x cheaper?
$50 sensor today –> $5 sensor in 5 years –> embed in everything
3.41 SHIFT Proposal Framework
Scenario: Your manufacturing company’s VP dismisses a proposal to add IoT sensors to industrial pumps, saying “Our customers have never asked for this.” You recognize this as paradigm blindness. How do you reframe the proposal using the SHIFT framework?
Original Proposal (Technology-First):
“We should add IoT vibration and temperature sensors to our pumps, enabling cloud analytics and predictive maintenance alerts.”
Why It Failed: Focuses on technology, not value. Sounds like adding cost and complexity. Invites the “nobody asked for this” dismissal.
SHIFT Framework Analysis:
Letter
Question
Application to Pump Sensors
S - Second-order effects
What happens after predictive maintenance succeeds?
Customers reduce downtime by 30%. They increase production capacity without buying additional pumps. This creates demand for MORE pumps (higher production lines), not fewer. Second-order effect: IoT sensors increase pump sales by enabling brownfield expansion rather than forcing greenfield investment.
H - Human behavior change
How might customers behave differently?
Currently, customers schedule maintenance quarterly (conservative, lots of downtime). With predictive data, they shift to condition-based maintenance. This changes procurement patterns: instead of ordering spare parts “just in case,” they order exactly when needed. We could offer just-in-time parts delivery as a subscription service, creating recurring revenue.
I - Impossible becomes possible
What couldn’t they do before?
Customers had NO visibility into pump health between quarterly inspections. Equipment failed unexpectedly, causing $50K-$500K/hour downtime. Now, they get 2-3 week failure warnings, enabling maintenance during planned shutdowns. This was literally impossible with manual inspection – you cannot predict bearing wear by looking at a pump casing.
F - Forecast anchoring
Are we anchoring to current behavior?
YES – that’s the problem. The VP anchors to “customers don’t ask for sensors” but forgets: AT&T customers didn’t ask for mobile phones in 1983. Customers don’t ask for paradigm shifts; competitors offer them first. Question: Do we want to be the AT&T that missed mobile, or the company that defined the category?
T - Technology cost trajectory
What happens at 10x cheaper?
Today’s $50 sensor will cost $5 in 5 years. At $5, adding sensors to EVERY component (not just pumps) becomes economical. First-mover advantage: we develop sensor integration expertise now, while competitors wait for “cheaper sensors.” By the time sensors hit $5, we have 5 years of data moats, algorithm refinement, and customer lock-in.
Reframed Proposal (Value-First, SHIFT-Informed):
“Our customers face $2M-$20M in annual unplanned downtime costs from pump failures. Competitors will soon offer predictive maintenance as standard. We can lead this transition and create three new revenue streams:
Premium pump pricing: +15% for sensor-equipped models (proven ROI in 3-6 months through downtime avoidance)
Subscription analytics: $50/month/pump for cloud dashboards and failure alerts (recurring revenue, 70%+ margins)
Outcome-based contracts: Sell ‘uptime-as-a-service’ at $500/month, guaranteeing 99.5% availability (we own the maintenance risk, but sensors let us manage it profitably)
Market Risk: If we don’t do this, someone else will. Industrial IoT competitors like Siemens and GE already offer this on competing equipment. Our customer survey shows 67% would pay for predictive capability – they’re not asking for ‘sensors,’ they’re asking for ‘no more surprise failures.’
First-Mover Advantage: 5-year head start on data collection creates algorithm moats competitors can’t match. Tesla didn’t wait for customers to ask for OTA updates – they defined the category.”
What Changed:
Before: “Add sensors because IoT is cool” (technology-first, easily dismissed)
After: “Prevent $2M-$20M downtime, create $600/year recurring revenue per pump, beat competitors to market” (outcome-first, financially justified, competitive threat framed)
Result: VP approves $500K pilot on 200 pumps at a single customer site, with success metrics defined upfront. Pilot demonstrates 28% downtime reduction and generates 3 upsell leads. Full product line rollout approved 9 months later.
Key Lesson: Paradigm blindness is defeated by reframing around new outcomes (not new technology) and competitive threats (not customer requests). The SHIFT framework provides the structure for that reframing.
Time: 45 minutes | Difficulty: Intermediate | Challenge: Apply the SHIFT framework to an IoT proposal in your environment
Scenario: Identify ONE IoT application in your industry or organization that leadership has dismissed as “unnecessary” or “too expensive.” Use the SHIFT framework to reframe the proposal.
Your Task:
Document the Dismissal (5 minutes):
What was the IoT proposal? (sensors in X, connected Y, automated Z)
What objection did leadership raise? (customers don’t ask for it, too expensive, not our core business, etc.)
Which historical parallel does this match? (messenger boys, mobile phones, smart watches)
Apply SHIFT Framework (30 minutes):
Letter
Question
Your Analysis
S - Second-order effects
What happens AFTER the first use case?
(Fill in)
H - Human behavior change
How might people behave differently?
(Fill in)
I - Impossible becomes possible
What couldn’t be done before?
(Fill in)
F - Forecast anchoring
Are they anchoring to current behavior?
(Fill in)
T - Technology cost trajectory
What happens at 10x cheaper in 5 years?
(Fill in)
Reframe the Proposal (10 minutes):
Original framing (technology-first): “We should add [IoT technology]…”
Reframed (outcome-first): “Our [customers/users] face [$X cost/Y pain], competitors will soon offer this, we can create [3 new revenue streams]…”
Deliverables:
Completed SHIFT analysis table
Side-by-side comparison: original technology-first framing vs. reframed value-first framing
One-paragraph competitive threat assessment: “What happens if our competitor does this first?”
Success Criteria:
You identify at least 2 second-order effects that weren’t in the original proposal
You name specific competitors or adjacent industries that might enter your space
Example Output:
Original Proposal: “Add GPS trackers to our rental construction equipment.”
Leadership Objection: “Equipment theft is rare. This is a solution looking for a problem.”
SHIFT Analysis: - S - Second-order: Theft prevention → utilization tracking → identifying underused assets → right-sizing fleet → $2M capital savings - H - Behavior: Customers stop hoarding equipment “just in case” → better utilization across all customers → we serve more customers with same fleet - I - Impossible: No visibility into equipment usage patterns → now can optimize maintenance schedules → prevent breakdowns proactively - F - Anchoring: Yes - leadership anchors to “low theft rate” and misses 15-20% of fleet sitting idle - T - Cost: $50/device today → $5/device in 5 years → embed in EVERY tool, not just expensive equipment
Reframed Proposal: “15-20% of our $50M fleet sits idle while customers request equipment we can’t fulfill. GPS tracking enables usage-based pricing ($8K/year per unit revenue vs. $3K/year flat rental), predictive maintenance (40% reduction in breakdowns), and theft recovery ($500K/year losses prevented). Competitors United Rentals and Sunbelt already offer this. ROI: 8.2 months.”
Reflection Questions:
Which of the 5 cognitive mechanisms (anchoring, linear thinking, old metrics, second-order effects, survivorship bias) was strongest in your leadership’s dismissal?
If you had to pick ONE element of the SHIFT framework that’s most compelling for your organization, which would it be?
What parallel from history (telephone, mobile, Internet, smart watches) resonates most for your industry?
Checkpoint: History as Evidence Filter
