Symptom vs Cause in Discovery and POCs

The most popular advice on symptom vs cause is often the least useful: ask “why” five times and stop when you reach a tidy answer. On a live deal, that can turn a messy commercial problem into a neat story that misses the conditions your team can change before the demo.

A symptom is the signal someone can name. A cause is the mechanism producing it. The distinction matters because the same signal might be a one-off glitch or evidence that your qualification, ownership, handoffs, or evaluation process keeps creating the same outcome. No discovery, no demo. If you can't name the cause layer you need to test, you don't yet know which demo to build.

Symptom vs Cause on a Live Deal

Start with a simple test: if the proposed fix disappears, will the signal return? If the answer is yes, you're probably looking at symptom suppression. Extra slides can make a late-stage demo look prepared. They won't repair a late SE handoff. More POC weeks can delay a difficult decision. They won't create an owner or an exit metric.

Read each row as a working hypothesis, not a verdict. Late SE involvement could reflect a one-time scheduling failure, or it could point to a handoff rule that consistently brings PreSales in after the buyer's story has already been shaped. A generic demo request might mean the buyer hasn't agreed on a problem, or the AE hasn't shared enough discovery context for you to scope the demo. Those explanations call for different moves.

The same discipline applies to a falling technical win rate. Coaching the person associated with the latest miss may help that person, but repeated losses across a pod call for a look at qualification criteria, shared playbooks, and how the team reviews evidence. The North Star technical win rate guide is a useful way to keep the PreSales-owned outcome tied to technical wins rather than activity. For role clarity on where that ownership sits, see what a Sales Engineer does.

Buying signals can help you decide whether a deal merits more attention, but a signal of interest isn't proof of a verified business problem. CapyScout's buying signal examples give you a practical reference for separating buyer behavior from the cause you still need to test.

The examples in the table are hypothetical composites, not accounts or customer stories. Mark one row that fits the opportunity in front of you, then carry only its cause layer into the next conversation. Don't promise another demo or extend a POC until you know what you're testing.

Special Causes and the Four Layers

A single bad discovery call and a team that repeatedly brings SEs in late can produce similar symptoms, but they don't call for the same fix. The first may be a special cause, a specific, identifiable event that creates an unusual signal. The second may be a common cause, a fault built into how the team operates.

W. Edwards Deming drew this distinction in a 1971 discussion of statistical management. His framework separates unusual, identifiable events from faults embedded in the broader system, because responding to every signal as an individual failure can create blame and instability while leaving recurring process problems untouched. A broken sandbox on one deal calls for targeted troubleshooting. Generic demos across unrelated opportunities point toward a team practice that needs redesign, not a reprimand for the last person who ran one. (Deming's discussion of statistical management)

Separate the signal from the operating rule

For a live deal, sort the evidence through four layers:

1. Symptom. What can the buyer, AE, or dashboard name? For example, “the evaluation keeps slipping.”
2. Immediate cause. What mechanism is producing the slip on this opportunity? Perhaps the integration test hasn't been scheduled.
3. Contributing conditions. What makes that mechanism more likely? The buyer's technical owner may be unavailable, and no one has defined a test environment.
4. Systemic cause. What operating rule keeps creating those conditions across the pod? Perhaps POCs begin without a named technical owner or a confirmed evaluation plan.

A signal at one layer can be a cause at the next. “Thin discovery answers” is an observable symptom; unclear ownership, an overloaded calendar, or the lack of a shared question set might explain it. Don't collapse those layers into one label. Each points to a different intervention.

For your marked row, ask the deciding question: Is this an unusual event, or is the operating system printing the same result again? A one-off may need a specific correction. A repeated pattern needs a change to the process that keeps generating it.

Which Diagnostic Method Fits the Deal

Don't run Five Whys on every complaint. Pick the diagnostic method that matches the shape of the problem before you start the working session.

Use a stop rule, not a question count

Five Whys is a method for following a chain, not an instruction to ask exactly five questions. The U.S. Centers for Medicare & Medicaid Services says teams often need three to five iterations, but may need more. Keep asking until the group agrees the cause is identified, then test the latest answer: if correcting it still allows the problem to recur, it's a contributing factor, not a sufficient diagnosis. (CMS guidance on Five Whys)

Before asking why, write down the specific problem in neutral terms. The Agency for Healthcare Research and Quality recommends formalizing the problem first so the group stays focused on the same issue. (AHRQ guidance on defining a problem before asking why)

Causal mapping is a better fit when several conditions interact. It's finished when you've ranked the plausible causes by how much your team can control them, whether they recur, and how strong the evidence is. A detailed map that leads to no test or change is only a polished diagnosis.

Use a fault tree when you can reproduce a technical failure and test branches against it. Don't build one to investigate a missing economic buyer. That's a commercial qualification gap, not a product fault; use a framework such as MEDDPICC for Solution Engineers to expose what's unqualified. If you need a reference for how lead qualification is commonly structured, hireSDR's guide to qualifying leads offers a starting point. For a true one-off glitch, troubleshoot it, confirm the abnormality is gone, then move on.

One incident with a short chain calls for Five Whys. Several interacting conditions call for a map. A reproducible product failure calls for a fault tree. A true one-off calls for troubleshooting.

How to Run the Chain on a Call

You don't need a workshop to do disciplined diagnosis. Keep the customer conversation anchored on one observed problem, separate the signal from your explanation, and don't let a demo request turn a guess into a requirement.

1. Write the problem in the customer's words. Before proposing a cause, capture what the buyer says is happening. AHRQ recommends writing the specific problem down first because it formalizes the issue and helps the group stay focused on one description. (AHRQ's problem-definition guidance)

2. Separate detection from verification. Establish how severe the signal is, the measurement window, and the baseline. Then identify independent evidence that could confirm a mechanism, such as usage records, logs, a failed workflow, or input from the stakeholder who owns the outcome.

3. Ask why, then test recurrence. Follow the chain one link at a time. After each answer, ask whether correcting that factor would stop the problem from returning; if not, keep it as a contributing condition and continue.

4. Keep other causes visible. Write the leading candidate beside the conditions that may contribute to it. You don't need to force a single root cause if the deal's failure depends on several interacting factors.

5. Trace each demo scene or POC test to a requirement. A proposed scene should test a problem both sides have agreed is real. A feature the buyer likes but can't connect to a requirement doesn't belong in the evaluation plan.

6. Name the change that prevents recurrence. Choose an action that alters the condition you identified, not one that only makes the meeting feel productive. If the cause is missing ownership, another reminder to attend won't assign an owner.

The Academy's Discovery module teaches the Pain Chain Framework to help Solution Engineers identify systemic problems instead of surface-level requirements. It gives steps three and four a repeatable structure and phrasing to use on a live deal. The PreSales guide puts that work in the context of the role: PreSales helps connect a buyer's problem to a credible technical evaluation. For a reusable prompt set, use these sales discovery questions.

You can say: “You're seeing low adoption, so before we show anything, let's test whether the workflow has an owner and which metric that owner controls.”

Filled decision line: Observed symptom, users aren't completing the approval workflow; measurement window, the period the buyer reviewed during discovery; candidate causes, no named workflow owner, missing integration, or a success metric the champion doesn't control; evidence, workflow logs show where users stop, integration testing confirms whether required data arrives, and the champion identifies who owns the metric; action, test the workflow with its owner and agreed success measure before adding demo scope.

Discovery Calls and POC Patterns

Two hypothetical composites show how the symptom can steer a deal toward either a useful test or a time-consuming distraction.

In the first, a champion says users won't adopt the platform. The weak path treats low adoption as the cause and promises end-user training in the demo. The stronger path records the observed signal, then tests three candidates: an unowned workflow, a missing integration, or a success metric the champion doesn't control. The demo shows only the path tied to the problem both sides agreed is real. A tour of every module spends the meeting without testing any of those candidates.

In the second hypothetical, a buyer wants a POC to prove an attractive feature. The weak path adds the feature to scope because the room liked the screen. The better path traces the business problem forward to the requirement, design element, test, and evidence. Then it traces every proposed test and acceptance criterion backward to the requirement that justifies it.

NASA's software-engineering handbook requires bidirectional traceability across the software life cycle. Applied to PreSales, that means a demo claim, POC test, or acceptance criterion needs a parent requirement, and every important requirement needs evaluation evidence. A test without a requirement is a feature tour. A requirement without evidence can't support a technical win. (NASA software requirements handbook on bidirectional traceability)

Refuse scope that has no traceable requirement. A popular screen is not a business problem.

For a broader framing of the first conversation, the solutions-selling methodology can help keep the discussion oriented around the buyer's problem rather than a feature list. If your live opportunity has a discovery gap, prepare with the discovery call guide. If discovery is solid but the POC has untraced tests, repair the requirement-to-evidence chain before committing more evaluation effort.

Proof You Changed the Cause

A plausible explanation isn't proof. “The champion needed more training” may sound reasonable, but it doesn't establish that training caused the adoption problem or that adding training changed it. Judge the intervention by whether the signal recurs, not by how tidy the diagnosis sounds.

Before you call a finding causal, record four things:

• Baseline: the metric and the measurement window before the change.
• Hypothesis: the mechanism you believe is producing the symptom.
• Intervention: a change that directly alters that mechanism.
• Post-change check: a measurement period in which you look for the same signal.

Then test the explanation. Reproduce the symptom where you can. Compare affected and unaffected opportunities. Check an alternative cause. Monitor whether the signal returns after the intervention. Safety research warns that corrective actions can be weak or incomplete when teams label a cause but don't evaluate sustained risk reduction; its recommendations also emphasize baseline measures, explicit hypotheses, linked interventions, and follow-up measurement. (AHRQ PSNet perspective on rethinking root-cause analysis)

Watch for the easy fix that leaves the constraint in place

Training, reminders, and new rules can help when the gap is knowledge or consistency. They're weak controls when the actual constraint is an unowned workflow, flawed integration, insufficient capacity, or product design. If the team can only keep the POC moving by manually chasing every participant, the underlying ownership problem is still there.

Short-term improvement can mislead. A metric may move after a change because the period was unusual, because the team logged events differently, or because the next set of opportunities was not comparable. Check whether the same result holds without extraordinary manual effort. For a POC, write the test and evidence into the success criteria template before the evaluation starts.

The outcome is repeatable technical wins, not a prettier dashboard or one unusually smooth deal. Use the North Star technical win rate guide to define that outcome and keep the team focused on whether its approach works across opportunities, not just whether one symptom briefly disappeared.

Apply This on the Next Opportunity

Before your next customer conversation, choose one active opportunity and write the problem in the buyer's words before you set the agenda. Run it through the chain, then mark the one candidate cause you can test on this call.

If the same pattern appears across the pod, don't reprimand the last person associated with a miss. Change the operating conditions: qualification criteria, shared playbooks, or the coaching rhythm. A recurring generic demo request needs a stronger discovery gate; repeated open-ended POCs need an owner and an exit metric.

Practice the conversation on a live deal, not in the abstract. The Trusted Advisor Academy combines structured content, live practice, and immediate application, while its Discovery module teaches the Pain Chain Framework for finding systemic problems. When you're ready to work through a customer conversation, use the discovery call page.

Take one active deal through the chain this week, and carry one candidate cause into your next conversation.

PreSales Unleashed GmbH offers the Trusted Advisor Academy for structured PreSales development, with discovery content, practice, and application to active opportunities. If you want to improve how you separate buyer symptoms from testable causes before the demo, visit PreSales Unleashed GmbH.