Why 90% of Your CPQ Project Is a Waste of Time

The Hidden Tax Of Perfect CPQ Models

Be honest: what is really slowing your CPQ down is not the tool, the data, or even integration. It is the last 10% of the model that seems harmless on a slide and eats quarters in reality. I have watched smart teams spend months polishing edge cases while the bulk of the portfolio quietly stays in Excel and tribal memory. The result is predictable: low adoption, shadow quoting, and a system nobody trusts enough to use under pressure.

The pattern repeats across industries. Leaders push for a complete model. Practitioners warn that completeness is expensive. Deadlines slip. The go-live becomes a moving target. Meanwhile, the field continues to sell the old way because they cannot wait for perfection.

Completeness is optional. Correctness is not.

If CPQ is ever going to matter beyond a demo, we have to stop designing for the exception and start designing for the revenue.

Why 90 Percent Is The Right Starting Line

In one turbine program at Siemens, the team did something most CPQ programs talk about but rarely commit to: they identified the components that drove roughly 90% of the cost and configured only those to go live. The rest was approximated with clear assumptions. It worked, not because they “cut corners,” but because they made the right corner the corner.

That decision reframed success. Instead of chasing full coverage, they guaranteed two things that actually move the business:

• For 9 out of 10 deals, the configuration and cost basis were right on day one.
• For the tail, the system surfaced the gap and documented the assumption so experts could resolve it fast.

That is the good enough principle applied to CPQ. It is not sloppy. It is disciplined. It separates correctness from completeness and puts delivery ahead of theory.

Stop proving you can model everything. Prove you can model what pays the bills.

CPQ’s Real Job: Control, Not Convenience

Most organizations still treat CPQ like a sales convenience tool. When adoption lags, they add features, tabs, and screens. It rarely helps. The core job of CPQ is not convenience. It is control. A working CPQ keeps the business inside the guardrails while sales moves at full speed.

Control means the system can do four things on demand:

• Ensure what is sold can be built and delivered every time.
• Expose how prices move and where margin is lost.
• Generate a clean, auditable structure that other systems can trust.
• Explain choices well enough that people believe them.

When you view CPQ as a control system, the design changes. You prioritize clean product structures, explicit constraints, and explainable pricing over UI flourishes. You accept that some scenarios will take a documented manual path at first. You measure success by field behavior, not feature depth.

What Launches In Weeks, And What Can Wait

If you want to go live in weeks, not years, you do not need heroics. You need a tighter definition of “done.” Here is the version I use in hands-on work with teams selling complex products:

• Start with the value drivers. Model the modules and options that determine 80 to 90% of cost, lead time, risk, or regulatory exposure. If a choice does not move those needles, it can wait.
• Make uncertainty explicit. For what you do not yet model, add a placeholder with a default assumption and a short rationale. That is not a hack. It is governance made visible.
• Build guardrails before guidance. Get the hard constraints in place so invalid combinations cannot pass. Then add guidance that helps the field make good choices faster.
• Explain as you go. Every recommended choice should carry a one-line why. People do not adopt systems they cannot explain to a customer.
• Price to learn. Use a simple, testable price structure on day one. Instrument it. Watch how pocket price behaves. Improve weekly.

That is enough to ship. It is also enough to earn trust, because it does the boring, essential work the business depends on.

Why This Moment Is Different

A common pushback is that 90% is too blunt for complex products. It used to be. Today, it is a starting point you can refine quickly because modern tools change the effort curve.

Language models can draft variant descriptions, articulate trade-offs, and propose missing dependencies from your product collateral. They can accelerate documentation and help expose logic, but they do not replace explicit rules. Keep the system as the enabler, not the hero.

The winning architecture is simple:

• Product structure defines what exists and how it fits.
• Constraints ensure invalid combinations never ship.
• Descriptive knowledge explains when and why to choose an option.
• Assisted interaction compresses the time to a confident quote.

Put assistance on top of explicit, testable logic, not in place of it. That is how you get speed without gambling on correctness.

The Quiet Consequences Of Waiting For Perfect

When teams insist on perfect models before launch, they rarely get catastrophe. They get something worse: quiet failure.

Quiet failure looks like this:

• Coverage stalls at 20%. The rest lives in Excel and inboxes.
• Shadow quoting grows. Approvals become personal favors, not policy.
• Margin erodes in small, untraceable decisions.
• Product managers become ticket queues. Change requires a project plan.

By contrast, teams that ship the 90% core earn a compounding advantage. They capture real quotes. They see where prices drift. They can move product families out of spreadsheets, one quarter at a time. They improve the rule set from live use, not from assumptions in a room.

The only adoption that matters is daily behavior in the field.

When the official path is faster and safer than Excel, the field will use it. When it is not, they will not. It is that simple.

What To Change This Quarter

If you are in the middle of a heavy CPQ build, you do not need a reset. You need a reframe. Take one product line and do this:

• Map the top five cost or risk drivers. Model those cleanly.
• List the top ten invalid combinations. Enforce them with constraints.
• Add short, plain-English descriptions to the most chosen variants.
• Define explicit placeholders for what you are not yet modeling.
• Ship to a pilot group. Time the top paths. Watch where price moves.

In my experience, this is a 4 to 6 week effort with a small core team. It is the fastest way to convert opinion into evidence and perfectionism into progress.

What would happen to your timeline if you stopped proving you can model everything and started proving you can model what matters?