Work
A product that is actually part of a whole product family
For a manufacturer of highly configurable doors I worked as CPQ engineer on the more complex product structures in Autodesk Inventor and Tacton.
The client name does not need to sit at the centre here. The useful part of the case is the product complexity and the way that complexity had to be represented.
More than width and height
An industrial door can differ on many more points than dimensions alone.
The construction can contain different layers and materials. Fire requirements affect what is allowed. Locks can be visible or concealed. Frames can be executed in steel. Some variants have very specific applications, including doors for prison environments.
Those are not independent dropdowns. A choice in one part of the product can change what remains possible elsewhere.
What had to be modelled
The work was therefore less about adding options and more about describing a product family.
The model had to represent properties, possible values, product structure and the relations between them. A material choice could affect a fire class. A lock type could put limits on the construction. A frame choice could force or exclude other components.
That is where a product configurator starts to become an engineering model rather than a questionnaire.
My role across Tacton and Inventor
I worked on the project as CPQ engineer, mainly on the more complex door structures in Tacton and Autodesk Inventor.
Tacton was the place where configuration logic and validity had to be expressed. Inventor represented the technical product structure and geometry that came out of those choices. My work sat around that boundary: understanding the construction well enough to model the configurable product without reducing it to a collection of exceptions.
I did not stay for the move into production. I therefore do not claim a production result or downstream KPI that I did not personally follow.
Why constraints make sense here
You can describe a complex product with directional rules, and for many relations that remains the simplest solution.
The difficulty starts when several selections influence each other at the same time. Then long chains of if/then rules become sensitive to execution order and exceptions start to accumulate.
Constraint-based configuration asks a different question: which properties exist, which domains are valid, and which relations must remain true regardless of the order in which the user makes choices?
That was an important step in how I started looking at product configuration.
What I take from this
A complex configurator does not become maintainable by adding more rules.
It becomes clearer when the product model itself becomes clearer: structure first, then the logic needed to keep that structure valid.
That idea now comes back in my work around semantic product models, CAD automation and configure-to-order systems.