There is a quiet divide forming in CPQ right now.
On one side are teams still treating CPQ as an IT asset. Changes are scheduled. Ownership is centralized. The model is “stabilized” and protected. Every adjustment competes with other projects, and sales keeps a parallel reality alive in spreadsheets and exceptions.
On the other side are teams who stopped waiting.
They don’t talk about CPQ as a system anymore. They talk about it as something that moves with the business. Product logic changes when the market changes. Sales feedback shows up in the model the same week, not the next quarter. The gap between how products are sold and how CPQ behaves is shrinking instead of growing.
Once you see this difference in action, it’s uncomfortable to unsee.
Most CPQ professionals already know the problem. They’ve lived it. A deal fails because a rule is outdated. A workaround becomes permanent. The model slowly drifts away from reality while everyone pretends it’s still under control.
This isn’t a tooling problem. It’s an ownership problem.
CPQ has been implemented as if correctness requires distance. The people closest to the deal are the last ones allowed to change the logic. Over time, the system becomes safe, but irrelevant. Sales adapts. CPQ lags. Trust erodes.
What’s different now is that this trade-off is no longer necessary.
Modern CPQ doesn’t require a long upfront design phase to stay correct. It doesn’t need frozen models to remain stable. It doesn’t need IT as a gatekeeper for every meaningful change. Structure can evolve continuously without breaking the system.
That sounds trivial until you experience it.
When product logic can be adjusted while deals are still live, CPQ stops being a bottleneck and starts becoming a competitive advantage. When updates happen in days instead of months, sales behavior changes. People stop bypassing the system. The model stays aligned because it’s allowed to.
Many vendors explain this shift with “AI”. That explanation misses the point.
What actually matters is orchestration. Structured prompts and controlled execution keep rules consistent while humans make decisions. The discipline is enforced by the system, not by process. That’s why this works in real environments, not just demos.
This is where the FOMO becomes real.
Teams that adopt this way of working move faster without losing control. Their CPQ stays relevant longer. Their sales teams trust the system instead of working around it. Over time, they learn faster because the feedback loop is short.
Teams that don’t will keep optimizing for safety while the market optimizes for speed.
And the gap won’t show up as a dramatic failure. It will show up quietly. Slower response to new requirements. More exceptions. More manual handling. More “special cases” that never quite make it into the model.
By the time it’s obvious, catching up will be expensive.
Going into 2026, the CPQ question isn’t whether your system can handle complexity.
It’s whether your organization can afford to keep treating change as a project.
The teams that figure this out early won’t talk about it much. They’ll just close deals faster, adapt quicker, and wonder why everyone else is still waiting.
That’s the shift. And it’s already underway.