I think that starts one step too late.
Before a company can configure a product reliably, it has to understand which part of its engineering is truly repeatable, how the product family is structured, and which decisions still belong to engineering. The configurator comes after that.
ETO and CTO are not opposites
Engineer-to-order makes sense when a customer order genuinely requires new engineering. The requirements may change the construction, interfaces, dimensions or performance enough that an engineer has to design a new solution.
Configure-to-order starts from a different assumption. The product already has a defined space of valid variants. A customer order selects a point inside that space rather than starting a new design from zero.
In practice many technical products sit between those two extremes.
A company may have a recurring machine platform, but still engineer a few interfaces for every project. A door may come from a known product family while a rare execution still needs manual review. A process installation may reuse modules without ever becoming a fully configurable product.
The useful question is therefore not whether a company is ETO or CTO.
It is: which engineering decisions repeat often enough to become part of the product model?
Start with repeated decisions, not with software
When engineers build similar products again and again, they usually reuse much more knowledge than the final CAD files show.
They know which modules fit together, which dimensions are derived from others, which material is valid for a certain application, when a heavier profile is needed, or which option forces another component to change.
Some of that knowledge may already sit in CAD parameters or iLogic. Some may live in spreadsheets, calculation sheets, work instructions or simply in the heads of experienced engineers.
That is the raw material for configure-to-order.
The first job is to separate repeatable product knowledge from genuine project engineering. If every exception is forced into the configurator, the model becomes difficult to maintain. If too much remains outside it, the configurator does little more than collect options.
The product family comes before the rules
A common mistake is to start with rules too early.
Rules are useful, but they need something stable to act on. I prefer to first understand the structure of the product family: components, modules, properties, parameters and the possible variants of that structure.
Only then does it become useful to describe the logic between them.
A width may drive the number of supports. A fire requirement may restrict materials. A motor choice may depend on torque. A plate may not be longer than the press brake can handle.
Some of those relations are calculations. Some are directional rules. Some are better expressed as constraints that simply have to remain true.
The exact modelling technique matters less than making the product knowledge explicit.
CAD automation is often an intermediate step
For many companies the first move away from pure ETO does not start with CPQ.
It starts in CAD.
A parametric Autodesk Inventor model can already capture repeated dimensions and component choices. iLogic can automate suppression, replacement, drawing updates and other predictable actions. That can remove a lot of repetitive engineering without changing the commercial process.
But CAD automation and product configuration solve different parts of the problem.
CAD automation mainly answers: given these parameters, how should the model change?
Product configuration also has to answer: which combinations of parameters are allowed, and what product do those choices represent?
That distinction becomes important when configuration has to serve more than the engineer using the CAD model.
Decide where each kind of knowledge belongs
Not all product logic should be pushed into one system.
Geometry-specific logic often fits naturally in CAD or a geometry engine. Commercial rules may belong in CPQ. Product validity may sit in a constraint model. Manufacturing limits may come from factory capability data.
The goal is not to build one enormous application that owns everything.
The goal is to avoid translating the same product knowledge over and over again between sales, engineering and production.
That is why I increasingly look at the product model as the centre, with CAD, pricing, quotation and manufacturing as different consumers of the same underlying definition.
Configure-to-order should continue beyond the quote
A product is not finished when the configuration is valid.
Someone still has to engineer, order and manufacture it.
For a configure-to-order process to become genuinely useful, the configuration should be able to drive technical output: a bill of materials, CAD geometry, drawings, calculated dimensions or production data.
The Technics & Applications case is a simple example. A pool shape was configured, but the useful output continued into the calculated lengths and sequence of the individual cover slats for CNC production.
Inoxplus explores a similar idea from another direction. Product choices, geometry, price and quotation can all refer to the same configured worktop rather than maintaining separate versions of the product.
The closer configuration gets to something engineering and manufacturing can actually use, the less knowledge has to be reconstructed downstream.
What should stay engineer-to-order?
Not everything should become configurable.
Some customer requirements are genuinely new. Some products are sold too rarely for formal modelling to pay back. Some decisions depend on judgement, context or engineering analysis that is difficult to reduce to stable logic.
That is not a failure of configuration.
A good configure-to-order model has a boundary. Inside that boundary, the system can produce a technically valid variant. Outside it, the order becomes an engineering task again.
Making that boundary explicit is much healthier than pretending every future exception can be automated.
A practical progression
I usually see the path as gradual.
First, repeated engineering decisions become visible. Then parameters and product structure become more deliberate. CAD automation removes predictable model work. Rules and constraints define a stable configurable space. Only after that does it make sense to connect sales, pricing, CAD, BOM generation and manufacturing more tightly.
Companies can stop at any of those stages if that already solves the real problem.
The objective is not maximum automation. It is to move repeated work into a reliable model without removing the engineering judgement that is still valuable.
Why this matters to me
I came into product configuration through mechanical design and parametric CAD.
That background makes the ETO-to-CTO question interesting because it sits exactly on the boundary between engineering and software. You cannot solve it only by choosing a CPQ platform, and you cannot solve it only by making the CAD model smarter.
You first have to understand the product well enough to say what is standard, what can vary, what must remain valid and what still deserves engineering.
Once that is clear, the software becomes much easier to choose.