In 2008 that mainly meant: understand a product well, model it correctly, and make sure usable drawings came out. That may look far from product configuration, but for me the base sits exactly there. You learn how a product is really built up, which dimensions matter, and where problems only become visible when someone actually has to make the part.
When I started independently under Kubuz in 2012, I worked among other things on stairs, platforms, commercial-kitchen equipment and machines. Around the same period I also started looking much more seriously at parametric modelling and iLogic in Autodesk Inventor.
That was an important turning point for me.
Not because iLogic itself is magic, but because CAD suddenly became programmable.
First you automate a model
The first step is usually fairly simple.
You have an existing model and you want certain dimensions to follow automatically. If the width changes, a cross member has to change with it. If the height rises, the legs become longer. If an option is off, a certain part disappears. That kind of automation gives a fast return: you avoid repetitive work and reduce the chance that someone forgets to adjust one dimension.
But in this phase you still mainly think from the CAD model.
The model already exists, and you make it smarter.
Then you notice that variation itself has to be modelled
On simple products you get quite far with that.
On more complex products you notice after a while that not every variation is simply another dimension. Sometimes the whole product structure changes. An option adds a component, a material choice limits available thicknesses, and a certain execution asks for a different build-up or production method. Then you are no longer only automating a model. Then you are actually modelling the variation of the product itself.
For me that is the moment when parametric CAD starts to pass into product configuration.
iLogic made that difference visible
Even before my first real configurator I had already experimented with that in industrial CAD work, among other things at AZO.
There I noticed how powerful it is when rules work directly on a technical model. You can calculate parameters, switch parts on and off, drive drawings, and let different executions come out of the same base. But you also notice fairly quickly where the limit sits. If all product knowledge ends up in loose iLogic rules, the model becomes harder to read.
Then other questions appear.
Why does this parameter exist? Which choice is real input and which dimension is only a consequence? Which combinations are valid, and how do you know which logic has to run first? Those are actually no longer pure CAD questions. Those are questions about the product model.
Around 2019 it became a real configurator
At Technics & Applications I built, around 2019, my first real product configurator in an industrial context.
There the focus shifted very clearly. It was no longer only about adjusting a model. The configurator had to understand choices, make calculations, and finally deliver information that went further toward production. On their pool covers, for example, the shape of the pool determines the length of each individual slat. With curves and fillets those lengths are not all equal, and that information then also has to be usable for production.
At such a moment you feel that a parameter in CAD is no longer enough.
You need product logic that understands what that parameter means and which consequences follow from it.
A configurator asks different questions than a CAD model
In CAD you often think in terms of geometry.
How long is this part? Where does this face sit? How many holes are in it? Which components are on? In product configuration other questions come on top of that. Which choices may the user make? Which combinations are valid? What is input and what is derived? Which information has to go to pricing, engineering or production?
The CAD model remains important, but it is no longer the complete system.
Tacton changed how I look again
When I started working with Tacton and constraint-based CPQ in 2023, that distinction became sharper still.
Until then I thought strongly in rules and dependencies: if A happens, set B. That works well and I still use it. But on highly configurable products that logic can quickly become a large network. In the door configuration I worked on, construction, material, fire requirements, locks, steel frames and different door types could all influence each other.
Constraint-based configuration then forces you to think less in execution order and more in relations that have to stay valid at the same time.
That took me another step away from “a smart CAD model” and closer to “a model of the product itself”.
Parametric CAD is therefore not the same as CPQ
Those two are sometimes easily mixed up, because both can make variants.
Still they start from something else. A parametric CAD model mainly says: if these parameters change, how does the geometry change? A product configurator also has to be able to describe which configurations exist, which combinations are valid, and what a choice means for the rest of the product.
That difference grows as the product becomes more complex.
A table with three dimensions can live almost fully in CAD. A machine family with different modules, motors, materials, safety options and production methods needs a much more explicit product model.
CAD remains an important base
I therefore do not see product configuration as something that replaces CAD.
My advantage is exactly that I know both sides. If you design mechanically yourself, you feel faster where a configurator becomes too simplistic. A product is not only a dropdown with options. A choice can mean that a plate has to be folded differently, that a profile no longer fits, or that a drawing has to be built up differently. That kind of thing is easily lost when configuration is only looked at from software or sales.
The other way around, software thinking also helps to structure CAD better. You start thinking more explicitly about inputs, dependencies, interfaces and reusable components.
Where I draw the difference today
I now try to keep three things apart.
The product model describes what the product is: structure, parameters, domains, rules, constraints, materials and relations. The engineering logic calculates what follows from that. And CAD or a geometry kernel finally makes the exact geometry and technical output from it.
For simple automation those three may sit close together. I do not want to build an architecture because I can. But as soon as a configurator grows, that separation helps a lot.
It also makes clear why my work shifted so naturally from CAD to configuration and software.
For me that was never really a move to another world.
It was always the same question, but at a higher level:
how do you lock down enough knowledge about a product so that you do not have to design every variant again?