From Dozens to Millions of Products
Image credit pixabay

From Dozens to Millions of Products

This week I spent time in Denmark at a summit organized by the Manufacturing Academy of Denmark (MADE). During the summit I met several people that expressed pride at the richness of their product portfolio. Some companies have a dozen different products, others may have close a hundred products. All these products are complicated including mechanical, electronic and software components.

Interestingly, most of the products in the product portfolio of these companies, as well as many others that I have worked with in the past, are quite similar. Even though I don’t want to criticize the decision of portfolio management at these companies, but I do notice a number of problems when taking a product-centric approach to such a product portfolio. These problems include duplication of effort, challenging integration issues with external equipment and duplication of similar parts.

The duplication of effort is caused by the fact that each product is developed independently. Consequently, if there are changes required that are cross cutting the portfolio, every individual product needs to be changed in response to this change. For instance, when there are regulatory changes, these tend to affect the entire product portfolio but the implementation effort will have to be repeated for every product.

Integration issues with external equipment are concerned with equipment that interfaces with the products. As customers may buy multiple products out of your portfolio, it is reasonable to assume that each product interfaces with the external equipment. Even if some glue code needs to be built, one could assume that the glue code works for all products from the portfolio. However, when each product is built independently, it is almost guaranteed that the interface to external equipment will be slightly or significantly different and hence incompatible. Obviously, no customer will appreciate this as the cost of the integration will be very high

The third challenge, duplication of similar parts, is that different products in the portfolio will contain similar mechanical and electronic parts. Without careful portfolio management, it is very likely that these parts are developed multiple times for each individual product. Especially for mechanical and electronic parts, this leads to unnecessary part numbers, duplication of effort, lack of scale in orders from suppliers, etc.

Although the aforementioned challenges are real cost drivers for the companies that I work with, by far the largest challenge is the opportunity cost due to the limited variability. Even if you have dozens of products in your portfolio, customers will still ask for a product that is like product X but has some aspects of product Y. The solution is NOT to engineer more products, but rather to transition from a product-centric to a product-platform (or product-family) approach.

A product-platform centric approach is concerned with defining a system architecture that captures the super-set of all capabilities provided by a suite of products in the portfolio. The system architecture defines a set of components with defined interfaces between these components. For each component, there are one or more alternative realizations for each component.

The benefits of this approach are staggering. For instance, for a system consisting of 10 components with an average of 5 variants for each component, we theoretically can offer 5^10 or 9765625 different products to our customers. Of course, in practice it’s typically significantly less as there are dependencies between different variants, but the conclusion is clear: instead of offering dozens of products, you could offer millions of products to your customer.

In the figure below, the principle is illustrated for a smaller product family. The product family architecture specifies the components and their dependencies. For each component, there can be multiple component variants to choose from. Products are (automatically) derived by selected specific component variants and can have some product specific extensions.

Figure: Product platform approach

If the advantages are that significant, why doesn’t every company use this approach? One of the challenges is that a product-platform requires a level of discipline in the organization that is not always present. Customization for specific customers should be avoided. Evolution of component variants has to observe compatibility rules at the interfaces. Evolution of interfaces is complicated and requires significant coordination across the organization. These are some of the challenges, but there are others.

Concluding, although companies often pride themselves on a rich product portfolio, the opportunity cost of failing to adopt a product-platform centric approach is significant. Although there are challenges associated with a product-platform approach, in many cases the advantages outweigh the disadvantages significantly. Presenting customers with a configuration tool where they can configure their specific product instance and then manufacturing it through flexible production means provides a great competitive advantage for most companies. So, let go of your product focus and focus on product platforms instead!

To get more insights earlier, sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).

DaviD Sánchez Mateo

Expert on automating Engineering departments and Technical Office to improve your productivity | Sales & Technical Configurator Expert | Elevator | #LeanEngineering

5y

Totally agree! From INGENIERIA SAMAT we try to give solution to these problems: make a platform for a configurable product so that special or standard adjetive has lost their meaning. We caught the componentes and the rules of every part and the rules of the entire and we are able to get any solution (like the Product platform approach picture of the Author). Then, our client has got an unique product with all the configurations they are able to manufacture. It seems simple... and really it is!

Like
Reply
Hans-Bernd Kittlaus

Software Product Management - ISPMA Training Courses and Certification for Product Managers

5y

While I fully agree with Jan's description of the advantages of the platform approach (and did this kind of platform management myself with IBM), I must say that the overhead cost and complexity is high. This is in conflict with the Agile idea where a self-managed team works quite independently on delivering something cool.There are certainly ways how to apply Agile in platform environments, but the classic Agile productivity measures will suffer from the platform overhead.

Peter D.

Product Development Engineer

5y

Like the article, from a design perspective I think this really gets to the intersection between #Lean #PLM #PDM and #KnowledgeManagement. Just need to pull #Agile alongside ;)

Solid argumentation! Traditional product lines and/or customer business units often lead to separate development organisations per product and/or customer, driving up the cost more than the value created, and preventing cross-product platform approaches. I think one part of the solution is to focus on the "A" (architecture/components) and the "P" (process/way of working) in the BAPO model, instead of jumping directly from a perceived business need to a certain organisational setup.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics