A client calls and says: “We need CPQ.” Or: “Our CRM isn’t working.” These are solution statements, not problem statements. If you build what they asked for without questioning whether it’s the right thing to build, you’re solving the stated problem, not the real one.

The framework I use for discovery, influenced by Charles Conn and Robert McLean’s Bulletproof Problem Solving, keeps the engagement from solving the wrong problem. Seven steps, straightforward in description, hard in practice.

flowchart LR
    D["1. Define<br/>the problem"] --> B["2. Break it<br/>apart"]
    B --> P["3. Prioritize"]
    P --> W["4. Build<br/>the workplan"]
    W --> A["5. Analyze"]
    A --> S["6. Synthesize"]
    S --> C["7. Communicate"]
    C --> O["Solution tied<br/>to the real problem"]

1. Define the problem

“We need CPQ” is not a problem definition. The problem might be: quote turnaround is five days and we’re losing competitive deals. Or: reps are discounting without governance and margins are eroding. Or: channel partners can’t generate quotes without calling us, which caps how fast we can scale. Each is a different problem. Each leads to a different project scope.

Getting to this definition requires pushing back on the initial brief. “You mentioned CPQ. What’s happening right now that made you start looking at this?” That question, asked early, changes the trajectory of the entire engagement. Frame the problem as a question: “How can we reduce quote turnaround from five days to same-day without sacrificing configuration accuracy?” A question forces precision.

2. Disaggregate the problem

Most business problems look like one big thing from the outside. Inside, they’re several distinct sub-problems with different causes, owners, and solutions.

“Quote turnaround is five days” breaks into: how long to configure the right products, how long to price it, how long to get approval, how long the customer waits before the rep starts. Each is a separate problem. One might take three days of the five. Another might take two hours. You can’t know where to focus without breaking the problem apart.

3. Prioritize

Some sub-problems contribute 80% of the impact. Others are real but marginal. A pricing governance problem affecting every deal is high impact. A configuration issue affecting one low-volume product line is not. Start with high impact, high feasibility. Say “not now” and mean it for everything else.

4. Build a workplan

A workplan is a plan for how you’ll investigate the prioritized sub-problems. Without one, discovery becomes open-ended. Every conversation and data pull should have a purpose tied to a specific branch of the problem. Three weeks. Specific outputs. That’s the structure.

5. Analyze

Analysis without structure produces noise — interesting things that don’t connect to the problem. Analysis grounded in a logic tree and a workplan is targeted. In revenue operations work, this means combining CRM reports and pipeline metrics with interviews with reps, account managers, and operations staff. The numbers tell you what’s happening. The conversations tell you why. When they disagree, the qualitative is usually closer to the truth.

6. Synthesize

Synthesis is not summary. A summary lists what you found. A synthesis draws a conclusion: “The primary driver of slow quoting is the dependency on sales engineering. Since 80% of configurations follow standard patterns, a guided selling flow could eliminate the engineering dependency for four out of five quotes, reducing turnaround from five days to same-day for standard configurations.”

That’s the bridge between the problem and the solution. Every element is grounded in evidence.

7. Communicate

Lead with the answer, not the analysis. “We can reduce quote turnaround from five days to same-day for 80% of quotes by implementing guided selling. Here’s why, here’s how, here’s what it costs.” Leadership wants the conclusion first, then they pull on the threads they care about.

Most projects fail not because the solution was wrong but because it solved the wrong problem. A perfectly implemented CPQ system doesn’t help if the real issue was approval bottlenecks. A new CRM doesn’t help if the real issue was an undefined sales process.

The discipline to follow this process — especially when the client is pushing to skip to implementation — is the difference between projects that deliver lasting change and projects that deliver software nobody uses.