Introduction
When companies discuss product complexity, the conversation often starts in engineering.
How many variants do we support? How many configurations exist? How many options have been introduced? How difficult are product structures to manage?
These are reasonable questions. But over the years I have come to believe that they are also incomplete.
Because complexity is rarely created where it becomes expensive. And that distinction matters.
The engineering organization may feel the complexity first. But the cost of that complexity often appears somewhere else. In sales. In manufacturing. In service. In training. In documentation. In inventory. In decision-making.
This is one of the reasons product configuration has become such an interesting topic for me. Not because configuration itself is the problem. But because configuration reveals how value and complexity move across the lifecycle.
And once you start looking at complexity through that lens, you begin to see costs almost everywhere.
The Request That Seems Harmless
Imagine a familiar situation.
A market opportunity appears. A customer requests a feature. A region requires a specific adaptation. A salesperson identifies a business opportunity. A product manager sees potential revenue.
The request seems reasonable.
Can we add one more option?
Most organizations can. In fact, saying yes is often the easiest decision.
The engineering effort appears manageable. The commercial opportunity seems attractive. The risk looks low. So the option is approved.
A few weeks later the product portfolio has become slightly larger. Nothing dramatic has happened. Nobody notices a significant impact. The decision appears successful.
But something else has also happened.
The lifecycle just became more complicated.
Complexity Never Stays Local
One of the most important lessons I have learned is that complexity travels.
An additional option rarely remains an engineering concern. Once introduced, it starts moving through the organization.
Engineering must define it. Sales must understand it. CPQ logic must support it. Manufacturing must build it. Documentation must describe it. Training material must explain it. Service organizations must maintain it. Spare parts must support it. Future product generations must consider it.
The option becomes a permanent participant in the lifecycle. And every future decision must now account for its existence.
This is where complexity starts behaving differently from cost.
Engineering typically sees the implementation cost. The business experiences the lifecycle cost.
The Configuration Tax
I sometimes think about this as a hidden configuration tax.
Not a tax paid once. A tax paid repeatedly.
- More decisions
- More rules
- More combinations
- More documentation
- More testing
- More change effort
- More lifecycle dependencies
The challenge is that these costs rarely appear in the same budget. They are distributed across functions. Small enough to be ignored individually. Large enough to become significant collectively.
As a result, organizations frequently underestimate the true cost of complexity. Not because the analysis is wrong. Because the lifecycle is larger than the business case.
The Product Nobody Sells
Most industrial companies have examples of this phenomenon.
An option is introduced for a specific customer. Or a specific market. Or a specific opportunity.
Years later the option still exists. Yet very few customers purchase it. Revenue is minimal. The original business driver may no longer exist.
But removing it feels impossible.
Why? Because the option has become embedded throughout the organization.
Sales literature references it. Configuration rules depend on it. Customers may still operate it. Service organizations still support it. Documentation still includes it.
Its commercial value may have disappeared. Its operational footprint remains.
The organization continues paying for complexity long after the business value has faded.
When Complexity Becomes Invisible
This is where things become dangerous. Not because complexity is visible. Because it is not.
Most organizations can tell you revenue, margin, engineering cost and project cost.
Far fewer can tell you:
- Cost per configuration rule
- Cost per variant
- Cost per option maintained across the lifecycle
- Cost of supporting rarely used combinations
- Cost of future engineering constraints
Those costs exist. They are simply difficult to see. Which means they rarely become part of investment discussions.
Complexity often behaves like technical debt. Except the interest payments are spread across the entire company.
The Executive Perspective
This is why I increasingly believe complexity is a leadership issue. Not an engineering issue.
Engineering may create product structures. But leadership determines portfolio strategy. Leadership determines governance. Leadership determines what is allowed to enter the lifecycle.
Every new option creates obligations that can last for years. Sometimes decades.
The important question is therefore not: "Can we add this option?"
The more important question is:
What lifecycle responsibility are we creating?
Those questions often lead to very different decisions.
Why This Matters More Than Ever
Historically, organizations could absorb a surprising amount of complexity. Products evolved relatively slowly. Software played a limited role. Service offerings were simpler.
Today's environment is different.
Products now exist as combinations of hardware, software, services, digital capabilities, regional adaptations and commercial packages.
The number of possible outcomes has exploded. Which means every additional option potentially influences a much larger ecosystem than before.
Complexity compounds. And unlike revenue, it compounds whether we measure it or not.
Rethinking Value
One of the most useful questions I have encountered is surprisingly simple:
What is the lifecycle cost of one additional option?
Most organizations cannot answer it. Not because they lack intelligence. Not because they lack data. But because no single function sees the entire impact.
Engineering sees engineering. Sales sees sales. Service sees service. Finance sees finance. The lifecycle experiences everything.
That makes the answer difficult to calculate. But arguably more important than ever.
Final Thoughts
In many companies, product complexity is viewed as a technical challenge. I think that view is becoming increasingly outdated.
Complexity is a business decision.
Every option added to a portfolio represents an investment. Not only in product development. But in sales, delivery, service, support, training and future change.
The most expensive options are not always the ones that cost the most to build. They are often the ones that quietly accumulate obligations across the lifecycle.
Because complexity does not stay where it is created. It travels. And the further it travels, the harder it becomes to understand its true cost.
That hidden cost is what many organizations are still struggling to see.