How to Reach Scale by Avoiding One-Off Products

To close the deal or satisfy an important customer, Product Teams often agree to develop one-off features for that particular customer. That’s a slippery slope and, in the long run, an innovation killer for B2B product teams.

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 one-off 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).”

Related content: Listen to the interview in my IoT podcast with Rich Mironov. Learn about his 4 laws of software economics and how they apply to IoT products.

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 customers’ needs for a turn-key solution without outsourcing your roadmap to them? 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 IoT product strategy.

Enable Customization as a Part of Your Product Strategy

If you are continually seeing the need to develop one-off features, then you (and your team) need to decide how to enable customization 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 software or IoT product strategy, so make sure you evaluate the implications of developing a customizable product.

The decision to build a customizable product will significantly impact your product roadmap and product team, as well as many other areas of your company.

For example, if you decide to enable customization on your software or IoT 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 message 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 to how much customization your product enables. You need to make that decision as part of your IoT product strategy. On one end of the spectrum, you can allow minimum customization on top of your product; on the other, 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 and lifecycle, and your team maintains it on a specific schedule.

The right side of the diagram shows the modules 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” rather than a “product.”

To implement this approach, you need a clear plan for dividing your offering into “product” and “project.” The product and project aspects usually have separate development teams, timelines, and business goals.

Part of your software or IoT product strategy is determining 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 podcast episode: How to Incorporate Services in Product Companies, with guest, Cesar Gamez, VP of Systems at Emerson.

4 Ways You Can Enable Customization

As part of your IoT 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, and the impact of regulations.

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 allow third parties to enhance your hardware offering. For software, I’m talking about Application Programming Interfaces (APIs) that you can use to expose 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 choose the ones that make sense for your product and business model.

Note: To learn more about the IoT Technology Stack and craft an IoT product strategy, check out my online courses for IoT and Enterprise Sofware Product teams.

1) Device Hardware Customizations:

As you work with your team to define your product’s hardware specifications, 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.

2) 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 product team’s goal 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.

3) 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 implement 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.

4) 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 do so. By providing them with a way to connect to your existing front-end applications, you can accelerate the development time of third-party (or internal) integrators.

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.

Providing the option to enable customization in your product is a great way to meet the exact needs of enterprise 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.

Enabling customization in your product has implications for your business model, roadmap, and partnerships. It means adapting 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 extensively 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 to their product. Now you know a way to enable customization to avoid that trap, so don’t let this happen to your team.

Taking the time to think about how you’ll enable customization as part of your software or IoT product strategy will give you a clear understanding of how your product can win in the market. This strategy must 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.