Build a CPQ Model in 50 Hours: The Approver Shift

From impossible target to practical path

Every time I say you can build a working CPQ model in under 50 hours, someone smiles politely. Then they tell me about their last 500–1,000 hour project. I know that story. I’ve led those programs. I’ve also watched teams ship a usable, trustworthy configurator in a week when they change one thing: the product owner stops trying to build the model and starts approving it.

This is not a tool trick. It is a role shift. When the system drafts the structure and the humans curate, correctness arrives faster than it ever did with hand-built rule webs. And no, this does not mean throwing out constraints. It means putting them where they belong.

The fastest path to a live CPQ is not better keystrokes. It is changing the job from modeling to approving.

The bottleneck you keep paying for

Most teams think the work is writing rules. It isn’t. The work is deciding what the product is in sales terms, and making those decisions visible enough to trust, test, and change. That is where projects stall. We try to model everything up front, and the last 10 percent takes as long as the first 90.

The result is familiar. A partial model goes live. Adoption is uneven. The rest of the portfolio retreats to Excel and PDFs. Sales learns two systems again. No one is happy, and change still requires a project plan.

Here is the reframe I offer customers: you do not have a tooling problem. You have a role and ownership problem. If your product owner can read a spec and talk to a salesperson, they can approve a model the system proposes. They should not have to code it from scratch.

Why this moment is different

Two shifts have converged. First, large language models can turn unstructured documentation into a coherent first draft of a product’s modules and variants with descriptive trade-offs. They are very good at proposing structure when you feed them your real product texts, price lists, and sales guides. Second, constraint engines still do what they have always done best: guarantee valid combinations, produce a clean BOM, and price without surprises.

The winning pattern is not AI instead of rules. It is AI on top of explicit, testable logic. AI handles conversational reasoning and draft structure. The CPQ core enforces reality.

One more reason to move now: buyers expect to make progress without waiting. Gartner has repeatedly noted that B2B buyers increasingly prefer self-directed digital interactions even for complex purchases, and McKinsey has tracked the rise of omnichannel as the dominant buying motion in enterprise. A conversational configurator that can both explain and verify is no longer a nice demo. It is table stakes.

Design principles for a 50-hour build

This approach only works if you protect a few simple rules.

• Owner as approver, not builder. The product owner curates and approves. They do not write logic by hand. If a dependency is obvious, they can add it in plain language.
• Structure before constraints. Start with modules and variants. Give each variant a one-paragraph description with pros, cons, and when to use it. This is fuel for both humans and the AI.
• Minimal hard rules first. Add only the dependencies that prevent real errors. Avoid long chains. You can strengthen guardrails as the model earns usage.
• Iterate in production lighting. Ship internally, observe where the dialog wobbles, tighten the model, repeat. Progress beats perfection.
• Explainability as a requirement. Every recommendation must be explainable in one or two sentences the salesperson can repeat to a customer. If it cannot explain itself, it will never be trusted.

The lightweight architecture

Think in three layers that reinforce each other.

• Product knowledge (descriptive layer). Upload your PDFs, catalog extracts, sales sheets. Extract and normalize into a flat set of modules and variants with short descriptions, trade-offs, and basic prices. Keep it human-readable.
• Reasoning and guidance (dialog layer). Use AI to propose the module-variant scaffold, surface trade-offs, and ask clarifying questions. Let it draft the guided flow automatically from the described product. Behind the scenes, it maps answers to variants.
• Control and correctness (CPQ layer). Enforce valid choices, generate BOM, and compute price. Keep hard constraints lean at first. Add the non-negotiables, then expand only where behavior shows you need it.

That is the whole point. The system drafts and explains. The owner approves and tightens. The solver guarantees you never sell the impossible.

A practical, step-by-step path to live in under 50 hours

1) Prepare a single source packet (2–4 hours)

Collect one current PDF brochure, one price list, and any internal cheat sheet sales actually uses. Do not overthink it. You want enough signal to describe the product like a person would.

2) Seed the model (2–3 hours)

Feed the packet to the system. Let the AI propose modules (building blocks) and variants (choices). Ask it to draft one-paragraph descriptions for each variant that say when to use it, why, and what you give up if you do.

3) Curate the scaffold (4–6 hours)

As product owner, review line by line. Merge duplicates. Rename to your language. Delete the obscure. Add the two or three variants you always discuss in meetings but never write down. You do not need to code. You do need to know your product.

4) Add only the hard dependencies (2–4 hours)

Write dependencies in natural language and let the system encode them. “Hybrid requires automatic transmission.” “Variant X is not available with Y in market Z.” Keep chains short. If you feel the need to diagram it, you are adding too much too soon.

5) Set a baseline price posture (1–2 hours)

Load list prices or sensible defaults. You are not building pocket price waterfalls here. You are giving sales a trustworthy ballpark and finance a place to plug their truth next quarter.

6) Generate the guided dialog automatically (2–3 hours)

Instead of authoring a questionnaire, let the AI propose a guided flow from the variant descriptions. Bias it toward how your best salesperson runs a call: start with mission, environment, usage patterns, then narrow. Avoid free chat as the primary path. People should never wonder what to ask.

7) Wire the guardrails (3–4 hours)

Connect the dialog to the CPQ constraints. When a choice invalidates a path, show it visibly and explain why. The point is not just to block the wrong path. It is to teach the right one.

8) Ship an internal pilot with proposals (6–8 hours)

Publish the configurator to a small field group. Have it generate clean proposals as microsites or PDFs with the chosen variants, rationale, and price. Track opens and time-on-page. You want to see what people read and where they hesitate.

9) Tighten based on real behavior (6–10 hours)

Listen to three things: where the dialog confused buyers, where sales asked engineering for help, where ops found a pricing or BOM surprise. Strengthen descriptions and add rules only where these signals point. Remove questions that add time but no value.

10) Formalize change flow (2–4 hours)

Lock an approver path: AI proposes a change, product owner approves, system logs the reason and runs impact checks. You go from writing logic to governing logic. That is the leverage.

Adoption is the only metric that matters.

Time one full quoting path. If the new path is slower than Excel, you still have work to do.

Who pulls ahead, and who quietly falls behind

The teams that win treat CPQ as a living capability, not a one-time project. The product owner updates descriptions weekly. Rules are added because behavior proved the need, not because a committee imagined an edge case. Sales sees the system help them think, not just click.

The teams that drift keep the old trade-off alive. They spend six months perfecting a model for one family, run out of time for the rest of the portfolio, and watch spreadsheets reclaim the gaps. No collapse. Just a steady slide into irrelevance as the market moves to guided, self-serve experiences that can explain themselves.

I have worked on both sides. At Tacton and later as an advisor, I have seen rule-heavy programs creak under their own ambition. I have also watched a small team ship a credible, guided configurator for a complex product in a week by approving a draft, adding five hard rules, and improving from real use. The latter compounds. The former decays.

Why this works in the real world

Because it aligns with how knowledge actually lives. Your expertise is in narratives, examples, and trade-offs, not in handcrafted constraint meshes. When the system can ingest that narrative, propose a structure, and let you approve, the right decisions surface fast. When constraints sit behind that process and catch the hard edges, you get correctness without bottlenecks.

And because it fits how buyers want to work. They want to understand, compare, and progress without waiting. A dialog that explains choices in plain language and a solver that guarantees reality is a credible answer to both needs.

If your product owner could approve a working CPQ model by Friday, what exactly is stopping you from trying?