A pragmatic execution framework for CPQ program managers and product leaders. Treat each product tier as a distinct quoting motion — and you'll have real, working CPQ in a month without overpromising.
One Framework, Three Distinct CPQ Motions
The most common CPQ failure is treating all products the same. Instead, recognize that Standard, Configurable, and Made-to-Order are fundamentally different quoting motions — each with its own logic, approvals, and downstream path.
Standard
Fixed SKU or bundle. Price is known upfront. No engineering input required. Goes straight to direct order.
Configurable
Finite options with known valid combinations. Price and BOM can be derived from rules. Supports guided selling and direct or config-generated orders.
Made-to-Order
Open-ended requirements. Engineering, costing, lead time, or sourcing is order-specific. Requires intake, assumptions, approvals, and engineering handoff.
Lock the Product-Tier Model First
Before a single rule is built in CPQ, the tier classification must be official. This is the foundation every other decision rests on. Make it formal, documented, and signed off in Week 1 — not a working assumption.
The Tier Classification Decision Table
Use this table as the official decision logic for every product in scope. Assign a tier, a CPQ pattern, and a downstream path before build begins.
Enforce the Exception Gate — Not a Fourth Tier
The temptation to create edge-case tiers is real. Resist it. The exception gate keeps your model clean and your build scope honest.
Standard Stays Standard
No drift. If the SKU is fixed and the price is known, it does not get reclassified — ever.
Configurable Routes to MTO
Only when it falls outside approved rules. One clean escalation path, not a gray zone.
MTO Is Not Automated Yet
Do not try to fully automate MTO unless design rules already exist. Control it through intake and handoff.
The Highest-Leverage Moves to Make Now
Five concrete actions — not to do eventually, but to complete this week. These are the decisions and structures that prevent scope drift, ownership gaps, and build rework.
A. Name One Owner Per Decision Area
Without clear ownership, the project becomes debate, not delivery. Every critical decision area needs one person who is accountable — not a committee, not a shared responsibility.
Product Tier Classification
Who decides which tier each product belongs to — and resolves classification disputes.
Pricing Logic
Who owns price book structure, discount rules, and pricing method per tier.
Engineering / MTO Rules
Who defines the assumptions, approval workflow, and handoff criteria for made-to-order.
CPQ Build
Who is responsible for configuration, rules, and delivery inside the CPQ platform.
ERP / Order Handoff
Who ensures the downstream integration — items, BOMs, and order records — is correct.
UAT Sign-Off
Who has the authority to declare a product "done" and approve it for production use.
B. Freeze a 30-Day Pilot Scope
Do not aim for all products in month one. Pick a narrow, high-signal slice of the catalog — enough to prove the motion, not enough to collapse under its own weight. The long tail comes later.
What to Pick
- 1–2 standard product families
- 1–2 configurable product families
- 1 narrow, well-understood MTO flow
How to Choose Them
Use three signals to select the right families:
- Revenue — high-value products prove ROI fast
- Quote volume — frequent quotes surface bugs faster
- Business pain — fix the processes that hurt most today
This is your first release scope. Treat it like a product launch, not a test.
C. Build One Master Product Tracker
Every team needs one working document that serves as the control file for the month. Not a deck, not a status email — a live sheet that every owner updates and every stakeholder reads.
Your tracker must include these columns:
Product Family
Tier · Sellable unit
Configuration
Options/attributes · Pricing method
Approval Path
Approval routing · ERP item/BOM strategy
Output
Quote document needed · Downstream handoff
Ownership
Owner · Status
Gaps & Blockers
Open issues · Dependencies
D. Define "Done" Before Build Starts
A product is not "in CPQ" because it appears on a screen. Shipping a product that can be found but not fully ordered is worse than not shipping it at all — it creates false confidence and downstream failures.
End-to-End Orderable
The product can be ordered from start to finish without manual intervention or workarounds.
Correct Approval Path
The quote follows the right approval routing — by tier, by value threshold, or by MTO trigger.
Accurate Pricing
The output price matches the agreed pricing method: list, derived, estimated, or approved.
Correct Order Output
The generated order document is complete, correctly formatted, and contains the right data.
Clean Downstream Handoff
The order, BOM, or engineering record is created correctly in the downstream system — ERP, PLM, or project tool.
E. Stand Up a Prod-Like Test Environment Now
A sandbox with sample data is not enough. Your test environment must mirror production closely enough that defects caught there stay caught. If it doesn't behave like PROD, it's not protecting you.
What "Simulated PROD" Actually Requires
Every element below must be present before the first product goes into UAT. Missing any one of these creates a gap between test results and real-world behavior.
Realistic Data
Masked but realistic customer and product data — not generic sample records. Real price books, discount logic, and product configurations.
Real Roles & Approvers
Actual user roles, permission sets, and approvers in the system. Approval workflows must route exactly as they will in production.
Quote Outputs & Notifications
Quote documents must render. Notification rules must fire. Email templates and PDF outputs must be verified end-to-end.
Integration Endpoints or Realistic Mocks
Lower-environment integration endpoints to ERP, PLM, or adjacent systems — or high-fidelity mocks that replicate real response behavior.
Logging, Defect Tracking & Rollback
Full logging enabled. A defined defect tracking process. Documented rollback controls so broken changes don't strand the test cycle.
What You've Committed to in 30 Days
Done right, this month delivers something real: CPQ that works for a meaningful slice of your catalog, proven in a test environment that mirrors production, with clear ownership and a clean tier model as the foundation.
✓ Tier Model Locked
Official classification for every product in scope. No ambiguity, no fourth tier.
✓ Pilot Scope Frozen
2–5 product families selected by revenue, volume, and pain. First release defined.
✓ Owners Named
One accountable person per decision area. No shared ownership, no gaps.
✓ "Done" Defined
Exit criteria agreed before build starts. UAT knows exactly what to validate.
✓ Test Env Ready
Prod-like environment standing by with real data, real roles, and real integrations.
CPQ in 30 Days: Three Tiers, Three Motions