IIoT customers often demand a fully functional, end-to-end solution. And, most products often fall short of “the last mile” to give these customers exactly what they need. To bridge this gap (i.e., close the deal, or satisfy an important customer) Product Teams often agree to develop one-off features for that particular customer.
Overall, the Product Team has the right intentions, since their goal is to make the customer successful. But in practice, they are digging themselves into a sea of tech debt and one-off features that will hinder growth and threaten the long-term success of the product.
Creating customized versions of your product eats away at your profit margins because your company is not able to amortize the cost of one-off development across multiple customers. Quoting Rich Mironov’s second law of software economics, “All the profits are in the nth copy or nth user.” And if I extend his definition to IIoT we can say: “All the profits are in the nth IIoT system (software and hardware).”
Although we all can relate to Rich’s law of software economics, in practice, it is tough to arrive at this model when selling to industrial customers. The reality is that industrial customers require a certain level of customization to fit their exact needs or to integrate your product with their existing systems.
How can you prevent falling into the “one-off development trap?” How can you meet your customer’s needs for a turn-key solution without outsourcing your roadmap to your customers? And even better, how can you leverage customization to open new potential sources of revenue or to differentiate your product further?
The key lies in your IIoT product strategy.
Make Product Customization a Part of Your IIoT Product Strategy
If you are continually seeing the need to develop one-off features, then you (and your team) need to decide how to approach this in a way that is sustainable and provides new profitable opportunities for your company.
I recommend working with your teams to decide early on how much customization (if any) your core product allows. This decision will become a pillar of your IoT product strategy, so make sure you spend the time evaluating the implications of developing a customizable product.
The decision to build a customizable product will have a significant impact not only on your product roadmap and product team, but also in many other areas of your company.
For example, if you decide to implement a customizable product, then:
- Your company will need a strategy to monetize custom solutions.
- The Product team will need to research new persona types (integrators and developers).
- Engineering (software and hardware) will need to re-architect your product to enable customization.
- Marketing will need to develop new product positioning.
- Sales will need people capable of selling customizable solutions, and they will require additional training to understand what they are selling.
- Business Development will need a new partner strategy.
- Customer Success and Support teams will need to figure out how to support your customers when they have a customized solution.
On the other hand, deciding not to provide a customizable product also has significant implications for your product strategy. In this case, you’ll need a clear messaging on how your product differentiates from competitors that enable customization, and you’ll need to be very diligent in turning down all opportunities to create custom or one-off features.
What Does a Customizable Product Look Like?
There is no one-size fits all approach for how much customization your product enables. You need to make that decision as part of your IIoT product strategy. On one end of the spectrum, you can allow minimum customization on top of your product, and on the other end, you can offer your product as a platform for others to develop their full solution.
When building a customizable product, the first step is to define a clear separation between your core product, the interfaces you expose, and the one-off customizations.
The core part of your product, including the interfaces, belongs to the Product Team. This is the portion of the product that every single customer gets. It has a clear roadmap, lifecycle, and your team maintains it on a specific schedule.
The right side of the diagram shows the modules that are specific to each customer. Each block represents a unique development effort to meet the particular needs of a single company. Companies usually manage this development as a “project” as opposed to a “product.”
To implement this approach, you need to have a clear plan for the division of “product” vs. “project.” The product and project aspects of your offering usually have separate development teams, timelines, and business goals.
In fact, part of your IIoT product strategy is to determine if the “project” team will be part of your company, in the form of an internal Professional Services organization, or if it is better to outsource that component and engage third-party integration firms to develop custom components.
Recommended article: Podcast interview with Peter Bourne, CEO of Bright Wolf, on how integration companies can help realize the value of Industrial IoT.
Where Can You Enable Customization?
As part of your IIoT product strategy, you can decide to open your product up for customizations at any layer of the IoT Technology Stack.
Once you identify the different areas where you’d like to enable customizations, I recommend reviewing the IoT Decision Framework to see how your decisions impact all areas of your product, including user experience, monetization approach, cost structure, security implications, the impact of regulations, etc.
The key to a successful customizable product is having clearly defined interfaces between your core product and the one-off customizations. I use the word “interface” as the generic term for both hardware and software interfaces. For hardware, I’m referring to specific connectors in your PCB that allows third-parties to enhance your hardware offering. For software, I’m talking about Application Programming Interfaces (APIs) that you can expose with the desired functionality.
Here are some examples of customization areas you can offer throughout the IoT Technology Stack. Remember you don’t have to provide customization areas at all these layers. You can pick and choose the ones that make sense for your product and business model.
Device Hardware Customizations:
As you work with your team to define the hardware specifications of your product, you can evaluate some of the most common requirements that change from customer to customer. In this scenario, creating a modular hardware architecture where you can “swap” components without developing a new Printed Circuit Board (PCB) or having to recertify your hardware can be very helpful.
Here are some examples of hardware customizations you could enable:
- Power source: battery module vs. “connected to the wall.”
- Various options for battery duration.
- A generic interface (bus) to connect various types of sensors.
- Options for different sizes of the hard drive.
- Options for swapping or upgrading the processing module (CPU).
- Options for various communication ports.
- Different options for wireless radios (i.e. WiFi, LoRA, Bluetooth, etc.)
By understanding the skills of your integration team, you can provide the ability to swap these modules with just a “plug & play” approach, or it may require a little bit of engineering work to create a new SKU. The level and ease of customization is something you get to decide based on what makes business sense for your company.
Device Software Customizations:
You can open APIs at the Device Software layer to enable third-party integrators to make the most out of your device hardware. The goal of the product team is to provide just enough of the “common denominator” functionality in your device software to have a robust set of APIs that enable integration teams to develop their custom solution.
Here are some examples of customizations you could enable at the edge:
- Provide access to raw data from sensors.
- Enable control of actuators.
- Enable connectivity with other edge devices by providing access to other communication ports (wired or wireless).
- Provide access to your edge analytics to develop custom analysis.
- Provide access to local data storage.
Cloud Platform Customizations:
You can also open Cloud APIs for integrators to enhance your cloud offering. Here are some examples of customizations you could enable:
- Access to raw data from a particular edge device.
- Access to the aggregate data from a group of devices.
- Provide access to your cloud analytics to develop custom analysis.
- Access to the health and operational parameters of edge devices.
- Ability to use data coming from third-party systems as part of your analytics/control mechanisms.
Cloud Application Customizations:
If you open Cloud APIs, integrators will be able to create custom applications for their customers, but not everybody has the expertise or desire to go that route. You can accelerate the development time of third-party (or internal) integrators by providing them a way to connect to your existing front-end applications.
Examples of Cloud Application customizations include:
- Display third-party data in your Cloud Applications.
- Display data generated by custom Device Software applications.
- Provide a white-label application shell integrators can use to accelerate their development.
Creating a customizable product is a great way to meet the exact needs of industrial customers, while at the same time, avoiding the trap of embedding one-off solutions into your core product. But of course, there are challenges that you need to evaluate first to decide if the return is worth the risk.
In addition to the implications to your business model, roadmap, and partnerships, opening your product for customization means that you’ll have to adapt your development process to ensure consistency of any exposed interface for as long as your product exists. You don’t want to break somebody’s custom solution with an API upgrade.
Open interfaces also expose your product to new security vulnerabilities, so you’ll need to have a robust process to ensure your solution is secure.
I’ve written a lot about the challenges of opening APIs in this other article: The Business of APIs, what Product Managers Need to Plan For. I highly recommend you take a look at it as well.
The Bottom Line
Many teams fall into the trap of adding customer-specific features into their product. Now you know how to avoid the trap, so don’t let this happen to your team.
Taking the time to define your IIoT product strategy will give you a clear understanding of how your product can win in the market. That strategy needs to account for how your Industrial IoT product will manage customization requests.
Overall, developing a customizable product is not cheap or easy, but in the long-run, it will save you and your team a lot of headaches, it will open opportunities for new business, and it might be able to secure you as the winning product in your industry.