A client calls and says: “We need CPQ.” Or: “Our CRM isn’t working.” Or: “We need to fix our lead management.” These are solution statements, not problem statements. And the gap between the two is where most consulting projects go wrong.

The client has already decided what they need. They want you to build it. But 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. And the stated problem is almost never the real problem.

This is the most important belief I carry into every engagement: discovery is the whole game. And the framework I use for discovery, influenced by Charles Conn and Robert McLean’s Bulletproof Problem Solving, is a structured approach to making sure you solve the right problem before you invest in a solution.

The framework has seven steps. They sound simple. Doing them well is hard.

1. Define the problem

This is the step that gets skipped the most and matters the most.

“We need CPQ” is not a problem definition. It’s a solution someone already picked. 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: our channel partners can’t generate quotes without calling us, which caps how fast we can scale.

Each of those is a different problem. Each leads to a different project scope.

A good problem definition is specific, bounded, and measurable. “Our average quote turnaround is five days. Competitors respond within 24 hours. We estimate this costs us 15–20% of competitive deals.” That’s a problem statement you can work with.

Getting to this definition requires pushing back on the initial brief. Not dismissively, but curiously. “You mentioned CPQ. What’s happening right now that made you start looking at this?” That question, asked early and asked well, changes the trajectory of the entire engagement.

One technique that helps: 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

Once the problem is defined, break it apart. Most business problems look like one big thing from the outside. Inside, they’re made up of several distinct sub-problems, each with its own cause, its own owner, and its own solution.

“Quote turnaround is five days” breaks down into:

• How long does it take to configure the right products? (Product complexity and knowledge access.)
• How long does it take to price the configuration? (Pricing logic and discount governance.)
• How long does it take to get approval? (Approval routing and threshold design.)
• How long does the customer wait between requesting a quote and the rep starting to work on it? (Workload distribution and lead assignment.)

Each of these 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 into its components.

Logic trees help here. Start with the problem at the top and branch downward into the factors that contribute to it. Building the tree together with the client team is often more valuable than the tree itself. It forces everyone to articulate what they think the problem is, and the disagreements that surface are usually the most important findings.

3. Prioritize

Not every branch of the tree matters equally. Some sub-problems contribute 80% of the impact. Others are real but marginal. You can’t fix everything at once, and trying usually means nothing gets fixed well.

Prioritization means asking two questions about each sub-problem: how large is the impact, and how feasible is the fix?

A pricing governance problem that affects every deal is high impact. A product configuration issue that affects one low-volume product line is real but low priority.

I often use a simple two-by-two: impact on the vertical axis, feasibility on the horizontal. The top-right quadrant (high impact, high feasibility) is where you start. The bottom-left (low impact, hard to do) is where you say “not now” and mean it.

4. Build a workplan

A workplan is not a project plan. It’s a plan for how you’ll investigate the prioritized sub-problems. What data do you need? Who do you need to talk to? What analysis will confirm or disprove your hypotheses?

This is what keeps the engagement from wandering. Without a workplan, discovery becomes an open-ended exploration. Interesting but slow and expensive. With a workplan, every conversation, every data pull, every workshop has a purpose tied to a specific sub-problem.

A workplan for the quote turnaround problem might look like:

Week 1: Pull data on actual quote turnaround times broken down by product line, rep, and channel. Interview five reps and two sales engineers about where time goes during quoting.

Week 2: Map the current approval process end-to-end. Identify how many quotes require approval and how long each approval step takes.

Week 3: Analyze the configuration process. How many products require sales engineering input? What percentage of quotes get reconfigured after initial submission?

Three weeks. Specific outputs. Each investigation tied to a branch of the logic tree.

5. Analyze

This is where most people want to start. Jump into the data. Build dashboards. Run reports. The reason this is step five and not step one is that analysis without structure produces noise. You find interesting things that don’t connect to the problem.

Analysis grounded in a logic tree and a workplan is targeted. You know what you’re looking for. You know what “good” looks like.

In practice, analysis for revenue operations projects combines quantitative data (CRM reports, pipeline metrics, quote history, renewal rates) with qualitative data (interviews with reps, account managers, channel partners, and operations staff).

The qualitative data matters as much as the quantitative. The numbers tell you what’s happening. The conversations tell you why. When the two disagree, the qualitative is usually closer to the truth. People know their own process better than the CRM reflects it.

6. Synthesize

Synthesis is not summary. Summarizing is listing everything you found. Synthesizing is drawing conclusions from what you found and connecting them into a coherent argument.

A summary: “We found that quote turnaround averages five days, that 70% of that time is spent waiting for sales engineering validation, and that 80% of configurations use the same 15 product combinations.”

A synthesis: “The primary driver of slow quoting is the dependency on sales engineering for product validation. Since 80% of configurations follow standard patterns, a guided selling flow could eliminate the engineering dependency for four out of five quotes, reducing average turnaround from five days to same-day for standard configurations.”

The synthesis is the bridge between the problem and the solution. It’s the moment where all the structured work comes together into a recommendation that is defensible because every element is grounded in evidence.

7. Communicate

The best analysis in the world is worthless if it doesn’t lead to action. And action in an organization requires communication that lands with the people who make decisions.

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, and here’s what it costs.” Then support the answer with evidence.

Most people present bottom-up: here’s what we did, here’s what we found, here’s what we conclude. Leadership doesn’t have the patience for that. They want the answer first, then they want to probe the supporting logic. Give them the conclusion upfront and let them pull on the threads they care about.

Why this matters beyond methodology

Seven steps is a framework. The real reason structured problem solving matters is more fundamental.

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.

Every project I’ve worked on, every implementation I’ve seen succeed, starts with the same question: what’s the actual problem? Not the stated one. The real one. Underneath the brief, underneath the assumptions, underneath the solution someone already picked before you walked in.

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.