"We have a complex product with a lot of variants. Let's configure it."
In practice, I regularly come across configurators that were built from exactly that starting point.
You recognise them by the long list of questions. Question after question. Choice after choice. And sometimes you'll notice that even an experienced product specialist struggles to answer them all correctly. Not because they don't know the product. But because they're wondering: why do I even have to fill all of this in?
I find that telling. Because what you're really doing at that point is translating the complexity of engineering directly into a configurator. Every rule goes in. Every exception goes in. Every dependency goes in. And then you expect sales, or a product specialist, to produce a good configuration from that.
But is that really the goal?
In my view, a good CPQ project starts somewhere else entirely. Not with the question "how do we configure this complex product?" But with: "which variants do we actually sell tomorrow?" And: "which options are really only there as an afterthought, but are rarely chosen and mostly just generate discussion?"
That's the step from Engineering-to-Order to Configure-to-Order: simplifying the product first, before you configure it.
"Not digitising the engineer, but organising the product so you need them less often for one-off projects."
At a client I worked with, historical quotes showed that around 80% of configurations could be built from a limited set of standard modules. We standardised that 80%. Part of the remaining options, it turned out, could also be redesigned slightly to suit multiple applications at once — which reduced the number of variants even further. The remaining 20% stayed deliberate custom work.
The result: for that 80%, engineering time became more than ten times shorter. Read the full case →
And engineering didn't disappear. It shifted: from working out individual projects to building those standard modules themselves.
That's not a minor improvement. That's a different operating model for your quoting process. This is, in my view, where the real step from ETO to CTO begins: not digitising the engineer, but organising the product so you need them less often for one-off projects — and more for building standards.
Do you recognise this from a sales perspective: hesitating over a question in the configurator because you don't know the impact of your choice? And if you already work with a CPQ system yourself: is the product simplified first, or is engineering's complexity built directly into the configurator?