PD fallacy #8: the bill of materials has the highest priority

Traditional companies building products including mechanics, electronics and software tend to focus on the bill of materials (BOM), standard unit cost (SUC) or some other KPI tracking the per-product instance cost during manufacturing. When manufacturing large numbers of the same product for extended periods, this makes perfect sense as every penny saved is multiplied over all the manufactured instances.

The challenge arises when companies are undergoing a digital transformation of their product portfolio and aim to deliver value to customers continuously. A typical model is to adopt DevOps as a mechanism to push new software to products in the field frequently. The moment the company transitions to this model, the BOM focus of the mechanical and electronics engineers becomes a significant hurdle as their decisions tend to lead to designs with very little ‘headroom’ in terms of CPU and memory resources.

The consequence is a clash between two paradigms of product development. On the one hand, it obviously is a good idea to minimize the cost of the product as it allows for better margins. On the other hand, not leaving headroom in the product destroys the ability to deliver value over time. Especially during the transition, it’s often very easy to quantify the short-term gains of squeezing the BOM and very hard to quantify the potential gains through continuous value delivery. This leads to companies continuing to focus on the BOM for way longer than what would make sense from a business perspective.

The BOM perspective tends to cause multiple challenges of which I want to discuss the three primary ones. The first, most obvious, is that not leaving headroom in the product destroys the ability of the company to build a continuous value delivery model. Especially for long-lived products that have years, if not decades, of expected life span, this is a major issue as the current product generations will hamper the company’s digital transformation for years to come.

The second challenge, often less well understood, is that an excessive focus on the BOM tends to introduce strong dependencies between different subsystems. Engineers are allowed to introduce any shortcut that results in a reduced BOM and consequently, the system will exhibit high coupling. When adopting DevOps for products, this tends to lead to an increased number of quality issues as it’s hard to validate and test all the intricate dependencies in the system.

Finally, especially in platform companies, allowing for BOM optimization tends to result in a significant deviation from the common platform architecture of the product portfolio. This causes what’s often referred to as a versioning hell as every product and every generation of every product needs its own specific, unique version of the software. This is acceptable if we have the build the software once, but when we adopt DevOps, it means that we have to generate new software for every configuration every two to four weeks. This gets expensive and labor intensive really fast.

To address these challenges, one of the key actions required is to ensure that you monetize the continuous value delivery through DevOps in some way. If there’s no revenue associated with new functionality being delivered to customers, the entire organization will drag its feet as it will only add cost at the promise of some vague ‘customer preference’ promise.

Of course, we can monetize through maintenance or subscription fees, but an effective approach can be to use the outcome metrics your customer is concerned with as a basis. Assume your system generates 100 units per hour for the customer and you can increase the output to 110 units per hour by deploying new software. In that case, it’s entirely reasonable for the customer to share some of the additional revenue with you. This requires, however, a clear understanding of what the key value factors are that your customer cares about. This understanding is surprisingly limited in most of the companies I work with as they focus on the product itself.

The second key action is to focus on bringing your entire offering portfolio into a single platform and make each product a configuration of that single platform. This allows for a vastly improved return on investment for most R&D efforts as much of the newly developed functionality can be shared among all products in the portfolio. Test infrastructure, deployment infrastructure, data collection infrastructure, and so on, can all be shared as well.

Although I’ve covered this topic before, I still run into people and cases that make me realize that the message hasn’t been received everywhere. An excessive focus on the bill of materials leads to significant challenges for companies that are undergoing a digital transformation and adopt continuous value delivery. The lack of headroom, high coupling and versioning hell may easily cause an explosion of R&D expenditure over time. Instead, ensure to monetize continuous value delivery and platformize your entire product portfolio to address these concerns. From a focus on the bill of materials, we need to shift to lifetime value. In the end, we want a continuous relationship with our customers and this is one of the best ways to strengthen that.

Like what you read? Sign up for my newsletter at?[email protected] or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).