How to Reach Scale by Avoiding One-Off Products

How to Reach Scale by Avoiding One-Off Products
Daniel Elizalde

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 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 IoT product strategy.

Enable Customization as a Part of Your IoT 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 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 enable customization on your 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, 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.

Core Product vs Custom Features

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 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 IoT 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.

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, 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 allow 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.

Note: to learn more about the IoT Technology Stack and crafting 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 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.

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 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.

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 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.

Providing the option to enable customization in your 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, enabling customization in your product 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 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 IoT product strategy will give you a clear understanding of how your product can win in the market. This 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.


  1. Piyusha 3 years ago

    Hi Daniel,
    I was was looking for content today, when i stumbled on your article (4 Ways to customized your IOT product)

    Good stuff! i especially enjoyed (the different ways and specifications for customizing IOT product)

    We are also working in the same domain for the Development IoT products.
    link below-

    Either way, Keep up the awesome work with website.

  2. dileep k 6 years ago

    Opening up an API at the software layer, can help offload decentralized decision making, often with quicker roundabout time, than the alternative of making the decision at the cloud application layer, where the application or person has to respond to an alert signal. For example: Shutting off a particular feature in an IOT device on field, which is experiencing heat sink issues. It (time critical) trades off with the sophistication of decision making in the cloud (insightful, impactful).

Leave a reply

Your email address will not be published. Required fields are marked *