“We call everything ETO because engineering touches it.” I’ve heard that line in too many steering meetings. It sounds safe. It justifies delays. It also hides the real problem: you haven’t decided what should be engineered and what should be configured.

When sales needs speed but operations needs control, the easiest escape is to blur the line. The cost shows up later as rework, margin erosion, and a system nobody trusts. If you sell complex products, CTO vs ETO is not a taxonomy debate. It’s your operating system.

ETO is not a product strategy - it’s a process you pay for.

The real difference: where variability lives

People think CTO vs ETO is about custom vs standard. It’s not. It’s about where variability lives and who owns it.

In CTO, variability lives inside a defined structure. Options, parameters, and modules are explicit. A constraint engine can validate combinations. From a chosen configuration, you can derive a BOM, routing, price, and documents. You can explain why a choice is valid and what it costs.

In ETO, variability lives before the structure. Requirements are captured, a design is produced, and the BOM is unique. Engineering capacity becomes the bottleneck. Pricing confidence drops because cost is uncertain. Lead time expands and coordination balloons.

Industry research from groups like APQC and Gartner has said this for years: ETO introduces more variability, longer lead times, and higher coordination cost than CTO. You don’t need a study to see it. Look at your last 50 orders. The ones that needed extra meetings will also have more change orders and margin surprises.

Two common mistakes keep teams stuck:

  • Everything is labeled ETO because engineering glances at it. That turns oversight into ownership and quietly normalizes delay.
  • CTO is forced where the product isn’t ready - no modules, weak rules, and pricing held together by discounts. That turns speed into risk.

If sales needs a side spreadsheet to get it right, you’re not in CTO yet.

Why more work is shifting to configure

Customers don’t ask for CTO or ETO. They ask for accurate answers fast. The shift to configure is happening because the market is forcing shorter lead times and more transparency. It’s also because we finally have the tooling and practices to handle complexity without inventing a new product every time.

Here’s what’s different now:

Modularization grew up. Product teams are building families with stable interfaces. Think kit codes as APIs. You don’t rewire the whole system to add an option. You plug it into a well-defined port.

Constraint-based CPQ is mature. Engines like Tacton CPQ can express compatibility and parametric rules cleanly, derive BOMs and routings, and generate documents without heroic Excel. When logic is explicit and testable, it’s an asset, not a liability.

Pricing is becoming composable. Instead of one giant price table that breaks on change, you model components, cost drivers, and the price waterfall. You see where margin goes. You improve it with data, not discounts. As I often remind teams: Perfect pricing is a myth - learning systems win.

AI helps - when it’s constrained. Think of AI as an expert’s apprentice. It speeds up analysis, explanation, and documentation, but only when it sits on top of the structural beams. Without rules, it generates fluent guesses. With rules, it becomes a reasoning assistant.

AI does not replace logic - it depends on it.

The result is a quiet rebalancing. The same variability that used to trigger a drawing is handled by a rule. The same configuration that needed a sign-off is enforced by a constraint. More orders flow through CTO. ETO is still there - but it’s reserved for true innovation, not every edge case.

Rules that keep you out of accidental ETO

Here are the rules I use with teams that sell complex products. They’re simple on purpose. If they sound blunt, it’s because complexity hides in polite language.

Rule 1: Decide where variability belongs. If a customer request repeats 3 times in 12 months, treat it as productized variability. Give it an option code, constraints, and a price. Stop designing it from scratch.

Example: You keep getting a non-standard height on a cabinet. Don’t draw it every time. Set a parametric limit, model cost impact, and expose it safely in CPQ.

Rule 2: Block mistakes early - don’t clean them up later. Force invalid asks to fail in configuration. If you let incompatible options reach engineering, you’ve already lost. The best engineering review is the one you don’t need because the system prevented the mistake.

Example: If voltage, region, and certification conflict, the configurator should explain why, not route a ticket.

Rule 3: Price what you sell, not what you hope. Build pricing from drivers you can explain. Use a price waterfall to separate cost, target margin, and discounts. Don’t hide uncertainty behind bespoke discounts. Uncertainty should trigger an ETO flag with a clear owner, not a quiet margin leak.

Example: If a special paint requires a new process, model the setup and cycle time impact. Don’t bury it under “strategic discount.”

Rule 4: Treat interfaces as sacred. Think of module interfaces like APIs. You can change internals without breaking the quote, but interface changes require governance. This is where CTO lives - stable contracts that survive change.

Example: If the motor interface changes, you don’t change every product. You version the interface and run an impact test suite.

Rule 5: Kill the Foggy Middle. The Foggy Middle is a half-CTO, half-ETO zone where engineering signs off every quote “just to be safe.” It feels responsible. It is slow, opaque, and incredibly expensive. Either codify the rule and stay in CTO, or escalate to ETO with clear scope and pricing consequences.

Every rule you add is a tax on future change. Make it worth paying.

One more truth, because it drives adoption more than any feature:

If the system cannot explain itself, it will never be trusted.

Show the why behind a restriction. Show the cost driver behind a price. When people can see the logic, they improve it. When they can’t, they route around it.

What to change this quarter

You don’t fix CTO vs ETO with a slogan. You fix it with ownership decisions and boring consistency. Three moves I’ve seen work quickly:

1) Run a reality check on your last 50 orders. Build a simple CTO-ETO scorecard: engineering touch count, time to first quote, change orders, margin variance. You’ll see patterns fast. The repeatable exceptions are your productization backlog.

2) Publish a “no engineering needed” catalog. Define the 70 percent you will always deliver through CTO. Include guardrails and parametric limits. Protect engineering capacity for true ETO. This instantly shortens lead times and raises pricing confidence.

3) Create a weekly workaround clinic. Ask sales to bring one workaround a week. Triage them into three buckets: codify in CPQ, clarify with a rule explanation, or elevate to ETO with explicit cost and lead time. This is gardening, not a one-off project - prune, shape, and keep the path clear.

If you use Tacton CPQ or similar, put these changes on rails with a small test suite and versioned rule sets. When a rule breaks a scenario, you want to know in minutes, not after a lost deal.

The most mature teams I work with measure adoption, not just accuracy. They know the quiet failure mode isn’t a wrong quote. It’s a salesperson who still opens Excel because the system can’t explain itself or move at the speed of the customer.

CTO vs ETO is a choice you make daily through how you model products, price, and change. Make the choice visible. Protect engineering for the work that actually needs it. Let configuration do the rest.

Speed isn’t a feeling. It’s the compounding effect of a thousand small, explicit decisions. The fastest quoting process is the one sales trusts.