Positioning IoT to profit through product packaging
This article is the fifth in a six-part series about monetizing IoT. Find the previous article here.
A few common approaches can be used to bring products to market to create diverse revenue streams within IoT. So far, this series about monetizing the IoT stack has defined various elements of the stack that can be monetized, introduced the three dimensions of monetization and described two of the three dimensions of the monetization framework for IoT: monetization models and monetization metrics. This article will address the third dimension of the monetization framework for IoT, known as product packaging.
Product packaging is the methodology for partitioning product functionality to bring different products to market with a variety of offerings, such as a single product leveraged by different SKUs to generate multiple revenue streams. This is another area where art meets science. Product management can be creative in meeting market needs and revenue goals with different approaches to portioning products’ functionality.
Product packaging examples
Product packaging can be a very broad topic, so I will identify a few, common approaches. For example, imagine a fictitious IoT utility equipment provider, Sensorytics. Sensorytics has a SaaS analytics platform that’s sold to various municipalities throughout the world.
The analytics platform ingests utility smart meter information, such as gas, water and electricity, and stores and uses that information to perform various analytics, reporting and alerting. In terms of relating this to the IoT stack, we’ll concentrate on the cloud aggregation and analysis part of the stack, but the principles apply to each level of the stack as well as to multiple elements of the stack combined into larger bundled offerings.
The analytics platform can provide value to the different types of utilities that a municipality offers. The product manager at Sensorytics initially decides to create three multiple offerings, one for each utility:
Market-based structures
The initial step is to create a base analytics package for each of the three different types of utilities, which might see different value from the basic offering that provides a slightly different set of basic reports that are specific for that market. Initially, the product manager has three offerings:
- Analytics for Gas Management
- Analytics for Water Management
- Analytics for Electricity Management
Persona-based structures
Digging deeper into the gas market, the product manager identifies three different, additional specialized offerings to address three different personas who see different values based upon a different analysis and set of alerts provided. Upon release, the product manager has three additional offerings:
- The finance department manager of the utility company is interested in a Gas Analytics for Billing to focus on gas consumption for billing services.
- The service department is interested in Gas Analytics for Services to identify possible problem areas in the gas lines in order to proactively react to problem areas that have been identified.
- The marketing department is interested in Gas Analytics for Usage in order to optimize pricing based upon usage patterns.
The Product Manager decides that the offerings will be structured in such a way that the gas utility company must first buy the Analytics for Gas Management before they can buy the more specialized persona-centric offerings.
Journey-based structures
As customers begin to use the Analytics for Gas Management offering, they start to ask Sensorytics for increased functionality so that the product matches the users’ workflow. Building on the persona-based model described above for gas utilities, the service department decides that it desires richer functions and a wider footprint. This leads to additional products that are available to the service department; the three additional products, which match the workflow of that department, bring the total number of offerings to nine.
Gas Analytics for Services Dispatching. This is a reporting engine that is used by the services department for dispatching service personnel to various locations based upon where the analytics platform identifies problems areas.
Gas Analytics for Services Timecards. This is an extension to the basic analytics platform that now inputs service personnel timecards to aid in services billing.
Gas Analytics for Services Optimization. Used to aggregate information gathered from the utilities end-points, this is combined with services personnel location and expertise to design an optimum workflow personnel utilization plan to maximize coverage and minimize services costs.
Best practices
As you can see, there are a variety of different offering structures that can be utilized to create multiple revenue streams from a single product or platform to match different market, persona and work-flow requirements. This can be further extended to create different bundles of individual offerings or to create offerings as a combination of product function and product metrics.
One word of caution is to keep models relatively simple. Avoid SKU explosion, which is characterized by a situation where 20% of the SKUs generate 80% of the revenue. Balancing the simplicity of the offering with revenue maximization is part of the art of product packaging.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.