How to Conceptualise and Implement a ‘Connected Product’ Through IoT? — Part 2

A reference guide to Product Managers / Business Analysts

10 min readDec 22, 2020

In part 1 of this article, we spoke about how ‘Commoditisation of Hardware’ is driving organisation to transform their Products to become Connected through IoT. We have also seen about different layers in IOT and how WHY — WHAT — HOW approach can be leveraged for the Seamless Implementation of IoT. We focussed on the WHY aspect in the previous article.

This article is going to be more focussed on WHAT and HOW aspects.

WHAT we need to achieve through IoT: Conceptualisation

Once we understand the Business and User problems, Next step is to Identify What are the use cases that will be addressed through the IoT solution and What will be the priority for each use case in terms of User and Business value.

For Identifying Use cases: It’s advisable to start with a ‘How Might We’ problem solving approach on the pain points. A prerequisite to this will be to rephrase the pain points to ‘Problem statement’ and then use the approach for coming up with potential solutions.

Understanding Priority through User Value: By pitching the solution to our customers and the intended users of the Product, we can understand the perceived value for them. We can come up with a priority score (High / Medium / Low) for each solution, based on the user value.

Conceptualisation of Ideas in the B2C Product:

If we look at the Pain Point, ‘Educational Institutions are not able to understand the Product / Application usage by students’

How might We, <Pain Point rephrased to Problem statement>

How Might We, ‘Enable educational institutions to understand how students are using the Product and Application.’

Possible Solutions and Priorities:

By giving the institutions a report on the list of applications that are installed in the Tablet. : Medium Priority
When each application is getting started and stopped by the students to see how receptive the application is to the Users. : High Priority
How is the network connectivity during the sessions. : Low Priority

Conceptualisation of Ideas in the B2B Product:

If we look at the Pain Point, ‘ Enterprise customers want a way to ensure that the installed turbines are working fine with good availability, service continuity withstanding the environmental impact.’

How Might We, ‘Enable enterprise customers to track the turbine health in real time and measure how much Power each turbine is generating’

Possible Solutions and Priorities:

Turbine Health details with certain metrics. : Medium Priority
Environmental Factors — Temperature, Humidity, Pressure etc. : High Priority
By giving enterprise customers a real time report on Power generated from each Turbine. : High Priority
Prediction on whether a Turbine is at the risk of getting malfunctioned before a customer reports it. : Low Priority

Downtime of the assets monitored by IOT mechanism has gone down by over 40 percent in 2019 — India Next

IoT in Power Generation. Pic courtesy: India Next

HOW we can achieve value through IoT: Planning and Implementation

Once the use cases and the corresponding priorities are identified, we need to come up with an approach on How we are going to implement the IoT solution in each layer of IoT. The approach includes a clear Execution plan on whether we are going to ‘Buy or Build’ the needed solutions at each layer of IoT for the use case we have Prioritised.

And for arriving at the Implementation Approach, we need to derive answers to the below Checklist Questionnaire. It’s advisable to start with a ‘Bottom’s Up’ (Product to Digital Services) always.

Checklist Questionnaire for the HOW do we implement the IOT Solution: To identify the needed solution at each layer:

Product Layer: What are the Details required from the device to infer the insight the user is looking for?
Product Layer: For us to infer the insights better, how frequently do we need the above details?
Product Layer: Does the Physical Product have the capability to collect and send the usage details currently?
Sensor / Device Agent Layer: How do we collect those details from the Product? Are we going to write our own Device Agent or Leverage the available sensors in the Market?
Connectivity Layer: Does the Product have the capability to share the collected data to Cloud?
Connectivity Layer: If the answer to the above question is NO, How can we bring in the connectivity to the Product? Do we need to come up with a Gateway ourselves?
Data Storage / Cloud Layer: How to aggregate / accumulate the data we collect from the Product? Should we have On premise Data storage or can we use Private Cloud storage?
Analytics Layer: Do we need to transform the collected data for getting the insights?
Digital Services Layer: How do we want to represent the data in the Application? Should we go for any IoT platform and integrate with it or Do we need to create a Front end Platform Ourselves?
Digital Services Layer: Do we need to update the users on the occurrence of any event?

Arriving at the Needed Solution for the B2C Product:

For Implementation, we will take the High and Medium Priority use case ‘When each application is getting started and stopped by the students to see how receptive the users are to the application, By giving the institutions a report on the list of applications that are installed in the Tablet.’

What are the Details required from the device to infer the insight the user is looking for? Details like application usage (it’s Start / Stop time), list of applications installed in the device.
For us to infer the insights better, how frequently do we need the above details? Although the user requires application information from the Device regularly, they may not require them in real time, as they are not going to act upon them immediately. So for this kind of use case, we can have the frequency set as ‘Once or Twice a Day’. But If the user requires more frequent updates, typically in B2C use cases, we always need to be watchful of overdoing this, as frequent data collection will require high power from the Device which in turn impacts its performance.
Does the Physical Product have the capability to collect and send the application usage details currently? No, we don’t have it currently.
How do we collect those details from the Product? Are we going to write our own Device Agent or Leverage the available sensors in the Market? For this use case, It’s better to come up with a needed device agent by ourselves to collect the information about the Application details (Installed ones, Start and Stop time).
Does the Product have the capability to share the collected data to Cloud? Yes, Tablet will be having Wi-Fi and Sim provision. We can use them to bring Internet connectivity to the Product, so that the Tablet can share the collected data to the cloud.
How to aggregate / accumulate the data we collect from the Product? Should we have On premise Data storage or can we use Private Cloud storage? For this use case, It will be better to come up with a Cloud storage for us to start accumulating the data from the Device as the amount of data is also very less. Once the data starts to come into the cloud, we will start to store / aggregate them in a Time series manner so as to make a perfect sense out of it. In this case, data will be synced in the cloud once or twice per day.
Do we need to transform the collected data for getting the insights?Yes, We need to Transform / Analyse the data to Infer and come up with the Insights. Based on when the application is getting Started and Stopped on the device by the students, we can transform how receptive the Students are to the application ‘High’, ‘Medium’ and ‘Low’.
How do we want to represent the data in the Application? Should we go for any IoT platform and integrate with it or Do we need to create a Front end Platform Ourselves? For representation of the Information required to the users, we need an application. In this case, the application is going to have only two categories: Applications Installed and Usage Details for each Tablet. As the use case is minimal, we might not be required to buy any IoT platform for this. Instead, We can build a platform for ourselves.
Do we need to update the users on the occurrence of any event?Depends on the user’s needs. In this use case, It might not be required.

Based on the responses to the above questions, we will come up with the different layers in the Connected Product for managing the applications.

Layers in a B2C ‘Connected Product’:

Arriving at the Needed Solution for the B2B Product:

For Implementation, we will take the High and Medium Priority use cases, ‘Tracking the Turbine Health details with certain metrics, Measuring the Environmental Factors — Temperature, Humidity, Pressure etc and By giving enterprise customers a real time report on Power generated from each Turbine.’

What are the Details required from the device to infer the insight the user is looking for? Details like Turbine Details, Power generated by each Turbine, Predict the health of Turbines to see whether they are at the risk of malfunctioning.
For us to infer the insights better, how frequently do we need the above details? As the use case is too critical from an enterprise customer perspective, We might require to collect the Turbine details in near real time. Since the Power is not a constraint for turbines, frequent data collection will not be a problem.
Does the Physical Product have the capability to collect and send the Turbine details currently? No, we don’t have it currently.
How do we collect those details from the Product? Are we going to write our own Device Agent or Leverage the available sensors in the Market? So, for this use case, we can buy the needed sensors and add them to the Turbines for monitoring the Turbines real time.
Does the Product have the capability to share the collected data to Cloud? Turbines will be located remotely, so they will not be able to share the collected data.
How can we bring in the connectivity to the Product? Do we need to come up with a Gateway ourselves? Since the Turbines are in remote locations, We need to enable the connectivity to the Turbines by technologies like LoWAN, and have them integrated with a connected Gateway which will then share the collected data to the cloud.
How to aggregate / accumulate the data we collect from the Product? Should we have On premise Data storage or can we use Private Cloud storage? For this use case, we can start with a cloud storage first to see the Data and Load pattern. Once the data starts to come into the cloud, we will start to store / aggregate them in a Time series manner so as to make a perfect sense out of it. In this case, data will sync up in near real time. However, Over a period of time, when the Volume and Velocity of data has become really huge and if the Customers have some concerns over Cloud storage, then we can plan for having our own storage.
Do we need to transform the collected data for getting the insights?Transform / Analyse the data to Infer and come up with the Insights. Based on the incoming events from the Turbines, to determine insights on the Turbine Health to ‘High’, ‘Medium’ and ‘Low’ risk.
How do we want to represent the data in the Application? Should we go for any IoT platform and integrate with it or Do we need to create a Front end Platform Ourselves? For representation of the Information required to the users, we need an application. In this case, the needed information could be on the Turbine Management with the Power and Turbine Health details in real time. Also, Prediction about Turbine malfunction risk in the Future. As the use case is at the enterprise level, we can look out for existing IoT platforms (like Thingsboard (open source) or Cumulocity (paid)) that will fit-for-purpose perfectly.
Do we need to update the users on the occurrence of any event?Although, It depends on the user’s needs. In this case, the solution needs to analyse the Turbine data in real time with a high level of intelligence and trigger an alert for the user to act upon.

Based on the responses to the above questions, we will come up with the different layers in the Connected Product for Managing the Turbines.

Layers in a B2B ‘Connected Product’:

As I was mentioning in the Part 1 of this article, we will target Innovators and Early adopters in our customer segment with our Product MVP. We will get the feedback and thereby iteratively improve the Product. But, once the Product steps into the next level growth stage, we will bring the needed Scalability and Security to the solution to reach up to the mainstream user segment.

This approach will help Product Managers / Business Analysts conceptualise and implement Internet of Things (IoT) in a Product to bring up the dual value proposition (of Physical Product and Digital Service) with Enriched User Experience. Along with that, this will enable OEMs to get new feature ideas and develop new business models for their Products as they will be getting faster feedback from the users.