At first sight, the development of "hardware" products hardly differs from that of IoT devices. Here you can see the methodology of IoT product development based on an IoT framework by Daniel Elizalde. It’s a convenient and simple model that estimates expenses and potential income, evaluates the technological complexity and at the same time is easily understood by the client. Made by notAnotherOne

2. General parameters of IoT as the system of systems
1. Absence of a single product owner who
is responsible for the whole system
2. Device should add value — nobody is
going to pay for a product or service
subscription if:
• Product or service doesn’t work properly
• They don’t add value to the life or work of
the end-user
• The user has to take care of the device
• The product doesn’t blend in with the life
of the user
3. Complexity, cost of errors and
interdependence are multiplied
4. Higher requirements for security +
various industry requirements and
technical standards
5. Multidisciplinary approach

3. How to deal with it
1. To hire a SoSe (system of systems
engineer) and allocate product owners
for the main disciplines
(design, HW, FW, cloud, apps)
2. To choose a methodology and
build up your internal processes
according to it:
○ Information exchange
○ Risk evaluation
○ Decision-making

4. IoT Development Methodologies
• IIC Framework
• MBSE (Model-based Approach to System Engineering)
• IoT Framework by Daniel Elizalde

5. IIC Framework (Industrial Internet Architecture framework)
Source: The Industrial Internet of Things Volume G1: Reference Architecture
Main disadvantages:
● No elaboration of the design phase;
● Complicated terminology for a client.

6. MBSE (Model-based Approach to System Engineering)
Based on OMG UAF framework
This methodology implies usage of UML2/SysML + DoDAF/TOGAF/
OpenUP UMD + TODEF and other specialized apps. It’s not very
convenient for a client and too complicated for non-IT specialists

7. But everything can be much easier
The original IoT framework developed by Daniel Elizalde analyzes
HW, FW, Communications, Cloud and Apps.
We propose to add the “ID/MD phase” in the project estimation
model.
ID /
MD
design
HW FW Communicati
ons
Cloud Apps
Source: IoT Framework from Daniel Elizalde

8. Something you can build yourself, something can be
purchased
Plant watering solution
ID / MD
design
HW FW Communications Cloud Apps
Try to identify in which area you can create your competitive advantage

9. Production Planning Cycle: Build VS Buy VS Partner
Research
Product
Development
• Backlogs (features, HW,
FW, FW)
• User tests
Product
planning/
Roadmap
• MVP
• Product feature set
prioritization
Product Strategy
Product Launch
Planning
• Go-to-market
plan launch
(marketing, sales,
ops.)
• Customer success
/ customer
development
• Target audience
Definition
• Problem setting / Task
setting
• Value proposition
• Financial forecast
• Sales channels /
distribution channels
• Go-to-market draft
Decision Matrix

10. Decision Matrix in IoT Product Development

11. Data
• What data
needs to be
received and
with what
frequency?
• What is the
way of
processing?
• What is the
frequency of
sending?
• Is analytics
required?
• Is it necessary
to
communicate
with other
devices?
• Requirements to
channel / QoS
• Requirements to
accessibility
• Requirements to
battery
• Volume of
data
transmitted to
application
• Streaming VS
history
• Requirements
to accessibility
• Requirements
to battery
• What volume of
data is required
to be stored and
during what
period of time?
• Real-time or
history
• Is diagnostics
required?
• Is post
processing
required?
ID / MD
design
HW FW Communications Cloud Apps

12. Business: how we spend money
ID / MD
design
HW FW Communications Cloud Apps
• FW
development
• License for
software
components
• Certification
• Data
transmission
costs (GSM / LTE /
etc.)
• Infrastructure
cost
• Development
• Third party
components /
modules
• Licenses
• Subscriber fee
• Support fee
• CPU time cost
• License for
analytics activity
• Third party
components /
modules
• Cost of components
(BOM, Bill of materials)
• Licenses for platform
• Tooling (molds)
• ID/MD development
• Design patent
• Manufacturing
• Packaging
• Certification
• Logistics

13. Business: how me make profit
ID / MD
design
HW FW Communications Cloud Apps
• Paid updates
• Paid access to
API
• Advanced
features
• Licensing
• Bonus program
• Marketplace
• Payment for the
number
(triggering, etc.)
of messages
• Payment for
channel size /
access rate
• Paid licenses /
sets of
functions
• Advertising
• Paid premium
support
• Fee for cloud
services /
extended
storage
• Additional
analytics
• Paid API for
third parties
• Integration for
third parties
• Data sale
• Device sale
• Lease out
• Extended warranty
• Paid installation
• Support / provision of
services
• Paid feature set update
• Training sessions
• Disposal

14. Technology
ID / MD
design
HW FW Communications Cloud Apps
• CPU / ROM / RAM
• Cost
• Conditions of
device operation
• Functional
requirements
• Dimensions /
weight
• Mains or battery
supply
• Life Cycle
• Certification
• Requirements for
accuracy
• Components
• …
• Feature set
• OS
• Protocols
• OTA
requirements
• Security
• Analytics /
monitoring
• Encryption
• Offline mode
• Certification
• …
• Power consumption
• Flow capacity
• Speed
• Distance
• Protocols
• Fixed or mobile
• QoS
• Web or mobile
• Target OSs
• Mobile: web or
native
• Update rate
• Certification
• API / 3rd
party
modules
• …
• Data transmission
protocols (i. e.
MQTT, REST)
• Database type (i. e.
SQL, NoSQL, etc.)
• Analytics (batches
VS real-time)
• APIs
• Privacy
• Requirements to
performance /
uptime
• Open Source VS
Proprietary
• …
• Conditions of
device operation
• Location (hidden
or in open view)
• Dimensions /
weight of device
• Sensors planned
to be used
• TA
• Cost
• Minimum block
• Certification
• …

15. Conclusion
1. An early and comprehensive study of the project can
significantly reduce risks at later stages;
2. IoT is all about partnerships.
Don’t reinvent the wheel if there are some doubts about
whether it’s possible to surpass existing solutions in terms of
functionality and/or cost. This model applies to hardware and
software modules too;
3. Try to elaborate a working scenario with a minimal
dependence of the device on:
• Networks
• Third-party services
• Cloud

16. Conclusion
4. Try to predict the worst-case scenario. Anything can
happen: complete cessation of support for the service by a
partner or failure of cloud infrastructure on your side. In this
case, the device must perform the basic functionality offline.
Unfortunately, this doesn’t apply to all categories of devices,
but if there is such an opportunity, then we should go for it;
5. Ideally, your team should have the product owners for each
subsystem (HW, SW, ID / MD), and the owner of the system.
The system owner should be able to assess how the changes
within one system impact others.