“We can’t change that rule today - only Johan knows how it works.” I’ve heard versions of that line in too many steering meetings. One expert becomes the gatekeeper, the backlog grows, and sales teams quietly route around the system.

When CPQ depends on a handful of technical modelers, everything slows down. Not because people are slow, but because the work is gated by skills that most product owners don’t have and shouldn’t need. The people who know the product best can’t express that knowledge directly in the system.

If your CPQ depends on heroes, you don’t have a system - you have a bottleneck.

The Hidden Bottleneck You’re Probably Tolerating

Most teams blame slow quoting on data, UI, or training. That’s noise. The real constraint is that modeling still feels like coding. You want a simple dependency captured, and it turns into a ticket, then a handoff, then a mini-project. Meanwhile, sales reopens old spreadsheets because at least those move.

CPQ was always meant to provide accurate pricing across options and constraints. Even Salesforce describes CPQ as a cloud tool to “provide accurate pricing with any given product configuration scenario.” That intent is right. The problem is how we capture the rules that make accuracy possible.

Rules aren’t the enemy - brittle rules are.

Why This Moment Is Different

We now have a practical way to separate product knowledge from code. A product manager can write, “The Sleeper Cab only works with the High HP Motor.” The system turns that into the underlying constraint and validates it instantly. No syntax. No solver voodoo. No waiting.

Think about what that changes. Modeling becomes a conversation in plain language. Product experts can add and test constraints themselves, then push those changes through the same review and release governance you already use. It’s faster, but it’s also safer - because the validation is deterministic and testable.

There’s a broader context here. Enterprises are only realizing 35% of the potential value of their cloud deployments, according to Bain. The tools exist, but teams aren’t unlocking them. In CPQ, value is trapped when knowledge lives in specialists’ heads instead of in a living, explainable rule set that the business can maintain.

Plain Language In, Deterministic Logic Out

Here’s how it works in practice:

  • A product owner writes a rule in natural language: “The Sleeper Cab only works with the High HP Motor.”
  • The system interprets that sentence, creates the dependency in the configuration graph, and runs an instant validation against the current product structure.
  • If the rule conflicts with something else, it calls that out immediately, not three sprints later.

The point isn’t to replace explicit logic. It’s to let the business express that logic in their words, then translate it into clean, testable constraints. You still keep guardrails: versioning, approvals, and a compact test suite that proves core combinations still work after every change.

This is not about automating judgment. It’s about shortening the path from product intent to enforceable rules. The solver remains the final arbiter - it’s the safety net that ensures what goes out the door is buildable, priceable, and deliverable.

Explainability is trust. If the system can’t tell you why, sales won’t believe the answer.

Five Rules That Make This Approach Work

1) Write rules in one sentence. Keep each rule atomic and readable. “If Customer Segment = Municipal, default Stainless Steel.” If a sentence starts growing, split it into two rules. Small rules compose better and are easier to test.

2) Treat context as a first-class input. Don’t just list features - describe when and why a variant is the right choice. A short rationale like, “Sleeper Cab is recommended for long-haul routes with night stops,” helps both reasoning and explainability. It also makes onboarding new reps much easier.

3) Validate on write, not in UAT. The instant someone adds a rule, run deterministic checks against a core test set: top 20 configurations, top 10 price ladders, and a few known edge cases. Catch issues at the keyboard, not weeks later in a test cycle.

4) Keep a living test suite beside the rules. Every defect found becomes a new test. Every critical sellable combination becomes a test. Over time, the suite becomes your guardrail and your release confidence.

5) Kill the Hero Modeler anti-pattern. Shift ownership to product and sales ops. Technical experts remain enablers and reviewers, not blockers. If a rule needs knowledge of the product rather than knowledge of code, the product team should write it.

From Lean Talk to Lean Behavior

Lean isn’t a poster - it’s the removal of waste. Robert J. Pryor’s “Lean Selling” frames the goal clearly: give buyers what they want faster. In CPQ, waste looks like handoffs, queues, and rework. Letting product owners express rules directly removes two of the worst offenders - the ticket queue and the translation layer between business and code.

Cloud helps here too. Bain found that moving development to IaaS/PaaS reduced downtime by 72% and improved app availability by 3.9 hours per user per year. That reliability matters when your sales tools are used all day, every day. But reliability without speed doesn’t raise win rates. We want both: dependable rails and faster change.

Concrete Examples You Can Steal

Preference rule with rationale: “For long-haul, prefer Sleeper Cab; explain: ‘overnight rest, noise isolation, driver well-being.’” The system both applies the preference and makes the explanation visible in the UI and quote notes.

Compatibility constraint: “Sleeper Cab only works with High HP Motor.” The dependency is enforced. If a rep tries Low HP, they get a clear, human message, not a cryptic error.

Commercial guardrail: “If Discount > 15% on Premium Service, require Manager Approval.” Business writes the policy; the system enforces and routes approvals automatically.

Block mistakes early - don’t clean them up later.

What Changes When Product Owners Can Model

Fewer workarounds. If changes ship weekly instead of quarterly, reps stop hoarding spreadsheets. The system becomes the fastest way to a correct quote.

Cleaner governance. You still run change control, but the cycle is days, not months. Review the plain-language rule, see the impacted tests, approve. Done.

Better onboarding. New sellers learn choices with embedded “why” explanations. It’s like having your best product expert in every call - without scheduling them.

Higher trust. When the system can explain its choices, adoption follows. Adoption is the only metric that matters.

What To Do This Quarter

1) Run a two-week pilot on one product line. Choose a product with 15-30 modules. Ask product owners to write 50 plain-language rules, each one sentence. Stand up a minimal test suite and measure two things: time-to-change and sales usage.

2) Establish rule hygiene. Create a short house style: one-sentence rules, active voice, “why” notes under 20 words, mandatory immediate validation. Every defect becomes a test within 24 hours.

3) Reset ownership. Make product the author, sales ops the publisher, and technical experts the reviewers. If a change sits with one person for more than two days, it’s a process smell to fix, not a priority to escalate.

This is not a big-bang project. It’s a behavior change. The technology just removes friction so the right behavior can win.

One last point: natural language is the on-ramp, not the destination. The solver and tests are still the rails. That’s the blend that works - speed to express intent, and certainty that the output is correct.

If your product experts can state the rule, they should own the rule. Your system should do the translation, the validation, and the explaining - every time.

The teams that move first will feel it in cycle time and in confidence. The teams that wait will keep shipping tickets to a shrinking pool of specialists and wonder why their CPQ looks fine on slides but never quite shows up in the field.

If modeling still needs a specialist, your sales velocity is capped.