IoT Value and Product Strategy · Study deck
IoT Perspectives: Role Lenses
This first route shows why each role notices a different failure mode and turns those competing lenses into testable questions.
Ada is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Distinguish diverse IoT perspectives: Compare how different stakeholders -- from security teams to makers to data scientists -- prioritize different aspects of IoT systems
- Apply formal definitions: Use academic and industry definitions to classify whether a system qualifies as IoT
- Map the IoT ecosystem: Categorize IoT components across Hardware, Software, Network, Data, and Security layers
- Justify cross-functional collaboration: Explain why no single perspective is sufficient and apply structured conflict-resolution strategies to resolve design trade-offs
Major section
Overview · Start With the Story
They need a way to handle lost links.
- This first route shows why each role notices a different failure mode and turns those competing lenses into testable questions.
- A heating service is enough.
- Each group sees a different part.
- They need help after a fault.
Major section
Phoebe's Field Notes: What 180 mAh Actually Buys, and What Erases It Before the Load Does
The mathematical gist: The chapter's 180 mAh, 3.7 V wearable stores 0.666 Wh by nameplate.
- Its stated AES-256 overhead leaves 153 mAh and 5.95 days; ChaCha20 leaves 166.5 mAh and 6.48 days.
Major section
Each Role Sees a Different Failure Mode · Checkpoint: Role Lenses
IoT design becomes easier once each role is treated as a trained risk detector rather than as a competing opinion.
- IoT perspective work is not about making every stakeholder happy.
- A single connected product crosses physical sensing, embedded firmware, radio behavior, cloud services, data interpretation, security controls, support tooling, and human routines.
- A hardware engineer will ask whether BLE advertising, motor current, and cold-weather batteries still meet the service interval.
Major section
Make the Trade-Off Testable
Instead of saying "UX versus safety," name the exact state where the user could misunderstand an unlocked, jammed, offline, shared, or remotely overridden device.
- The next move is to convert role tension into evidence.
- A team can argue about priorities forever, but it can test latency, battery life, retention, gateway capacity, recovery state, and ownership transfer.
- An engineering perspective asks how large, heterogeneous, dynamic networks can be built and kept reliable.
Major section
Make the Trade-Off Testable (continued)
Instead of saying "security versus battery," name the concrete path: TLS 1.3 or DTLS handshake cost, X.509 certificate storage, secure element use, wake interval, radio airtime, retry policy, and expected service life.
- The same habit appears in the 2006 ubiquitous-computing research agenda: no one approach could carry the whole design problem.
- An experience perspective asks which interaction principles make the system socially acceptable and usable.
- An industrial architect may reject a cloud-only alert path if SCADA, OPC UA, MQTT Sparkplug B, or a local HMI must remain usable during WAN loss.
Major section
Perspective Conflicts by Layer
Most IoT disagreements are cross-layer problems.
- A "simple" user-facing command may touch a mobile app, BLE pairing, gateway translation, MQTT topic policy, cloud authorization, device firmware, actuator timing, local safety interlock, and support tooling.
- Good perspective analysis therefore keeps the artifacts connected.
- A C4 context view can show system ownership.
Major section
Perspective Conflicts by Layer (continued)
Data contracts should define units, timestamps, identity, quality flags, retention, consent status, and authority for changing a field.
- A sequence diagram can expose command timing and failure responses.
- A state machine can show pending, applied, rejected, expired, overridden, and rolled-back states.
- Security contracts should define provisioning, key storage, authorization, audit logs, recovery, and OTA trust.
Major section
Perspective Conflicts by Layer (continued)
AsyncAPI, OpenAPI, Matter cluster definitions, OPC UA information models, or MQTT topic schemas can make integration assumptions explicit enough for several roles to review.
- Under-the-hood evidence should make each perspective visible in the same trace.
- A command trace can show whether authorization, broker policy, device acknowledgement, actuator feedback, and user-visible state agree.
- A telemetry trace can show whether sampling, compression, timestamping, analytics, and alert ownership preserve meaning.
Major section
Perspective Conflicts by Layer (continued)
A failure drill can show whether offline operation, stale data, credential revocation, and support diagnostics are understandable.
- When teams review the same trace, perspective conflict becomes engineering evidence instead of role preference.
- Operations: Include logs, health checks, OTA status, support diagnostics, and manual fallback in the same discussion as product features.
- For example, a mobile app may show "locked" because the cloud accepted a command, while the device is still retrying, the motor has stalled, the door sensor is inconsistent, or the local credential has expired.
Major section
Checkpoint: Testable Trade-Offs · Treehouse Roles Analogy
Planner / Architecture: Makes the subsystems fit together coherently.
- Experience designer / UX: Keeps the product clear, usable, and accessible.
- A highly secure system that people cannot use is still a bad design.
- A sleek user experience with weak authentication is also a bad design.
- The project works only when each role informs the others early.
Major section
Different Perspectives of the IoT · Key Perspectives
The Internet of Things (IoT) is a concept that is often perceived differently by various stakeholders.
- This diversity of perspectives is akin to the story of the blind men and the elephant, where each person perceives only a part of the whole.
- Security asks how people and assets are protected, using patching and detection evidence.
Major section
Perspective Tensions in Practice · Smart Thermostat Design Example
Every card carries the same two lines, and the second is the useful one.
- The first states a real conflict, such as dense telemetry against long battery life, or behaviour data against privacy limits.
- The second does not pick a winner.
Deck summary
Key takeaways
They need a way to handle lost links.
- The mathematical gist: The chapter's 180 mAh, 3.7 V wearable stores 0.666 Wh by nameplate.
- IoT design becomes easier once each role is treated as a trained risk detector rather than as a competing opinion.
- Instead of saying "UX versus safety," name the exact state where the user could misunderstand an unlocked, jammed, offline, shared, or remotely overridden device.
- Instead of saying "security versus battery," name the concrete path: TLS 1.3 or DTLS handshake cost, X.509 certificate storage, secure element use, wake interval, radio airtime, retry policy, and expected service life.
Retrieval practice
Recall check 1 of 3
Ada says: answer from memory, then check your reasoning.
Q1A smart-lock app team approves quick setup. Why should the support lead still review the product?
Show answer
Answer: A Support sees failures across the door, phone, bridge, and cloud that setup speed alone misses.
Retrieval practice
Recall check 2 of 3
Ada says: answer from memory, then check your reasoning.
Q2A team argues about security versus battery life in a smart lock. What would make the discussion testable?
Show answer
Answer: B The chapter converts broad tensions into specific costs and service-life assumptions.
Retrieval practice
Recall check 3 of 3
Ada says: answer from memory, then check your reasoning.
Q3A smart lock has a sensor, firmware, radio, usage records, and device certificates. Which map assigns each to the right concern?
Show answer
Answer: D Correct: each part belongs to the named physical, program, transport, evidence, or protection concern.
Print reference
Answers
Answer key.
- A · Support sees failures across the door, phone, bridge, and cloud that setup speed alone misses.
- B · The chapter converts broad tensions into specific costs and service-life assumptions.
- D · Correct: each part belongs to the named physical, program, transport, evidence, or protection concern.