The most popular advice about sales discovery questions is to ask open-ended questions and let the buyer talk. That's necessary, but it isn't enough. You can have a friendly conversation, collect detailed requirements, and still leave without knowing whether the problem deserves an evaluation.
The demo is not where the deal gets decided. Most SE teams invest in demo polish and treat discovery as a warm-up. Buyers usually shape the decision earlier, through the consequences they recognize, the constraints they accept, and the proof they agree to require.
Your job as a Solution Engineer (SE) is to test those assumptions before anyone opens a product. An informed buyer doesn't need you to restart their requirements exercise. They need you to identify what's missing, challenge an impractical integration assumption, or expose an approval condition their team hasn't resolved.
Use sales discovery questions to establish evidence, not complete a script:
- Impact: Is the problem worth solving?
- Architecture: Can the proposed approach work in the buyer's environment?
- Risk: Who or what could stop adoption or approval?
- Success: What proof would justify a decision?
No discovery, no demo. That doesn't mean withholding every product screen until you've completed qualification. It means discovery quality, not demo polish, decides whether you're demonstrating something the buyer has a reason to choose.
1. Cost of Inaction Without Another Year of Delay
Ask this after the buyer has described the problem: What happens if this stays unsolved for another year?
You're testing business consequence, not trying to manufacture urgency. A frustrating workflow might be tolerable. A workflow that prevents a launch, delays revenue recognition, or consumes engineering capacity deserves a different evaluation.
Follow-up: How are you tracking that today? Ask who absorbs the consequence and which business commitment becomes harder to meet. Don't convert every inconvenience into a financial estimate yourself.
Distinguish Friction From Consequence
- Weak hypothetical answer: We'll keep spending too much time onboarding services. You have a complaint, but no established consequence.
- Strong hypothetical answer: Onboarding delays are pushing work off the launch plan. Engineering leadership tracks those dependencies in Jira, and the product owner can confirm which commitments are exposed.
Hypothetical scenario: A platform engineering lead describes slow service onboarding. Instead of demonstrating provisioning features immediately, you trace the delay to release dependencies and arrange confirmation with the product owner.
Record the buyer's actual wording for demo framing and the mutual action plan. Use a discovery call framework to keep the consequence connected to its evidence.
Discovery isn't complete when: The buyer can name frustration but can't explain what suffers, who cares, or how to verify it.
2. Current-State Walkthrough Before You Propose a Replacement
A system inventory won't tell you how work really gets done. Ask: Walk me through how this works today, step by step.
Have the person who performs the workflow narrate it. Build a shared diagram in Miro, Lucidchart, or the buyer's preferred whiteboard, and let them correct your interpretation.
Follow-up: What happens next? At exceptions, ask who takes over and where the work waits. Stay with the sequence before suggesting a better one.
Don't replace the buyer's workflow with your product architecture while they're still explaining it.
Hypothetical scenario: A finance operations manager describes invoice approval. Approvers respond through Outlook, finance copies the status into Excel, and an overnight job updates NetSuite.
- Weak hypothetical answer: We use NetSuite for invoices. That identifies an application, not the process.
- Strong hypothetical answer: The request starts in email, finance checks the spreadsheet, and the overnight import updates the ledger. Rejected invoices go back to the requester outside that flow.
Mark manual handoffs, duplicate entry, exception paths, and recovery steps. Those are candidate demo scenarios, but only after you understand why they exist.
Role-play this question with another SE. The difficult skill is staying quiet without losing the thread.
Discovery isn't complete when: You can name the tools but can't replay the workflow, including exceptions, and get the buyer's agreement.
3. Measurement Baseline With an Accountable Owner
Ask: How do you measure that today, and who owns the number?
A metric name isn't a baseline. You need its definition, current value, reporting period, system of record, and accountable owner before you build a value claim around it.
Hypothetical scenario: Customer Success uses a Salesforce dashboard to track renewals, while Support reports cancellations from Zendesk. Both teams describe their measure as churn, but they include different customer populations.
Follow-up: Which definition will the people approving this investment accept? Don't choose the more favorable calculation just because it makes your business case look better.
Separate the Metric From the Evidence
- Weak hypothetical answer: We want better retention. Someone in RevOps has the report.
- Strong hypothetical answer: RevOps owns the renewal dashboard, excludes pending contracts, and can provide the baseline the finance partner uses.
If no trusted baseline exists, make establishing one an explicit evaluation task with a named owner. Don't substitute your assumptions for customer evidence without saying so.
The same discipline applies to Sales Engineer KPIs. For your own team, distinguish customer outcome measures from the technical win rate that PreSales owns.
Discovery isn't complete when: The buyer has a metric but no accepted definition, retrievable baseline, or person willing to defend it.
4. Technical Integration Map With Explicit Data Direction
Ask: Which systems does this need to read from and write to?
Read access and write access create different obligations. A reporting integration may tolerate stale data; a workflow that changes customer records may need conflict handling, auditability, and a clear source of truth.
Follow-up: Which data must move, in which direction, with what acceptable delay, and who owns that interface? Work through those dimensions separately rather than expecting a complete answer immediately.
Ask for the architecture diagram and invite its maintainer into validation. For CRM-specific preparation, Fetchin's guide to enriching CRM records is a useful companion topic, but enrichment doesn't establish writeback requirements.
- Weak hypothetical answer: It needs to integrate with Salesforce.
- Strong hypothetical answer: Read account ownership from Salesforce, write enrichment into approved fields, and preserve manual overrides. Our integration owner must validate API capacity.
Hypothetical scenario: A buyer requests real-time CRM synchronization, but API limits conflict with the expected workload. You document the constraint and test whether scheduled updates satisfy the actual business need.
Don't promise an integration because an endpoint exists. Confirm authentication, permissions, rate limits, failure recovery, and the environment available for testing.
Discovery isn't complete when: A required data flow has no owner, an untested dependency, or an unresolved latency expectation.
5. Security and Compliance Gates Before Signature
Security discovery should change your technical plan when necessary. Ask: Which reviews will this have to clear before anyone signs?
A questionnaire isn't the whole review. Data classification, residency, identity controls, retention, subprocessors, and audit evidence can determine whether the proposed architecture is acceptable.
Follow-up: Who runs the review, what do they need from us during the opening month, and does approval come before or after the proof of concept? Establish the sequence without assuming that evaluation access authorizes production data.
Identify Requirements That Can Block the Architecture
Hypothetical scenario: A healthcare buyer requires a defined category of patient-adjacent data to remain in an approved region. You confirm the hosting option with the product team before proposing the evaluation environment.
- Weak hypothetical answer: Security usually sends a form near the end.
- Strong hypothetical answer: The security architect approves hosting and identity controls before testing. Procurement needs the completed review before contracting can proceed.
Keep a current security pack ready, including architecture documentation and available assurance material. Match it to the reviewer's requirements rather than sending an undifferentiated document bundle.
Practical rule: Record a security requirement that could block signature as a deal risk, not a follow-up note.
Discovery isn't complete when: Nobody can identify the reviewer, required evidence, review order, or potentially disqualifying requirement. Review those gaps with the AE before committing evaluation resources.
6. Decision Process Mapping Beyond the Org Chart
Ask: Walk me through how a decision like this gets made here.
You need the formal approval path and the informal veto path. An enthusiastic technical contact may understand the product while having little influence over procurement, executive priorities, or security approval.
In Gartner's survey of B2B buyers conducted in August and September 2024, buying groups that reached consensus were 2.5 times more likely to report a high-quality deal.
Follow-up: Who else would have a say, and what would each person need to see to support the decision? Ask where stakeholders disagree, not just whether they've been informed.
- Weak hypothetical answer: The VP of Engineering decides.
- Strong hypothetical answer: The VP sponsors it, Security can reject the architecture, Finance approves the business case, and Procurement controls the contracting sequence.
Hypothetical scenario: Your contact identifies the engineering VP as the decision maker. Further discussion reveals that the security architect can reject any vendor, so you schedule architecture validation before agreeing to the POC scope.
Use MEDDPICC for Solution Engineers to distinguish decision criteria, approval authority, and contracting steps. Revisit the map as new participants join.
Discovery isn't complete when: You know names and titles but can't explain whose agreement is required, what they require, or how disagreement gets resolved.
7. Evaluation Success Criteria and Solution-Fit Confirmation
A pilot isn't ready because the buyer wants access. Ask: What would have to be true at the end of a pilot for you to say yes?
Define observable outcomes, acceptance thresholds, judges, scenarios, required data, and a decision date. Then ask: If we solved this exactly as you described, what would change for your team?
Confirm the Test and the Future State
- Weak hypothetical answer: We'll know once we've used it.
- Strong hypothetical answer: Finance will judge reconciliation effort against the agreed baseline, Operations will validate exception handling, and the sponsor will review the evidence on the decision date.
Hypothetical scenario: A buyer wants less manual reconciliation but has no target. You establish baseline measurement as the opening evaluation task, then agree on the acceptance threshold before performance testing.
Summarize the problem, impact, constraints, and decision process before requesting confirmation. Use a POC success criteria template, limit scope to decision-driving scenarios, and request written confirmation from the economic buyer.
The broader PreSales role includes connecting technical evidence to outcomes. Related lead qualification insights from Yalc address qualification, but your evaluation still needs buyer-approved proof.
Discovery isn't complete when: The buyer can't define acceptance or describe the operational change. Don't fill that gap with a broader demo.
8. Trigger Event That Explains Why Now
Hypothetical scenario: A new CFO asks department leaders to justify overlapping tools before the budget review. The problem hasn't changed, but someone with authority now expects a decision.
Ask: What changed that made this a priority now?
This tests whether the timeline reflects an actual business event or a date someone entered into the opportunity record. Ask after you understand the problem so it doesn't sound like pressure to accelerate.
Follow-up: What happens if the decision slips into the next planning period? If the deadline is a renewal or launch, establish the work that must happen before it.
- Weak hypothetical answer: Leadership wants something soon.
- Strong hypothetical answer: The CFO's review requires a recommendation before budget allocation. If we miss it, we need an exception or wait for the next planning cycle.
A trigger doesn't automatically establish urgency. A new executive might authorize investigation without approving implementation.
A deadline matters when the buyer can explain what happens if they miss it.
Record the event, its owner, and the consequence of delay. Work backward through security review, evaluation, contracting, and implementation instead of treating the desired go-live date as the signature date.
Discovery isn't complete when: The contact names a date but can't identify who set it, why it matters, or what changes if it slips.
9. Funding Path Without Turning Discovery Into Pricing
Ask: Is this already budgeted, or does it need a new line item?
You're establishing whether the proposed scope has a plausible funding path. Keep commercial negotiation with the AE, but don't design an enterprise evaluation around funding that only supports an exploratory project.
Follow-up: Who owns the budget, what approval threshold applies, and does the allocation cover evaluation, deployment, and ongoing operation? Don't assume those costs belong to the same team.
Match Technical Scope to Fundable Adoption
- Weak hypothetical answer: There should be money if the demo goes well.
- Strong hypothetical answer: Operations has approved evaluation funding. Deployment requires Finance approval through the planning process, supported by the pilot's business case.
Hypothetical scenario: A prospect can fund a departmental pilot but hasn't secured broader deployment funding. You and the AE constrain testing to that department and document the evidence required for expansion.
That can be a valid opportunity. It becomes an open-ended experiment when nobody owns the next funding decision.
Ask whether the initiative belongs to the current operating plan or a future allocation. The discovery call guide can help connect value evidence to the broader qualification conversation.
Discovery isn't complete when: Evaluation funding is mistaken for deployment approval, the budget owner is unidentified, or the buyer can't describe how successful testing leads to a funded decision.
10. Prior Attempts and Stakeholder Scars
Ask: What have you tried before, and what happened?
The buyer's history can reveal requirements they haven't written down. A stalled internal build, abandoned pilot, or difficult rollout may explain skepticism that otherwise looks like resistance to your product.
The Harvard Business Review guidance on customer interviews recommends asking how customers made a purchase decision rather than how satisfied they were. Apply that distinction here: uncover the reasoning and sequence, not just the verdict.
Follow-up: What worked, what failed, and who would need evidence that this attempt would be different?
Hypothetical scenario: A previous automation initiative failed because the business team couldn't maintain workflows after implementation. You add administrator ownership, maintainability, and enablement to the acceptance criteria.
- Weak hypothetical answer: The previous vendor wasn't good.
- Strong hypothetical answer: The workflow worked during the pilot, but nobody owned changes after rollout. The operations manager needs to validate maintenance tasks before approving another system.
Ask who supported the previous attempt, who absorbed the failure, and whether those people remain involved. Don't turn their frustration into competitor criticism.
Record the failure mode as a candidate success criterion, then confirm it with the stakeholder who carries the concern.
Discovery isn't complete when: You know which solution failed but can't explain why, who was affected, or what evidence would prevent a repeat.
How the ten discovery questions differ in signal, timing, and risk
| Item | Primary Signal | Best Used When | Main Caution |
|---|---|---|---|
| Cost of Inaction | Consequences and business impact if the problem continues | You need to distinguish urgent priorities from nice-to-haves | Ask after the problem is clear; prospects may only estimate the impact |
| Current-State Walkthrough | Workflow steps, tools, handoffs, and workarounds | You need to understand the real process before proposing a solution | Can run long or reflect an idealized process |
| Measurement Baseline | Trusted metric, current baseline, system of record, and owner | You need a defensible business case or measurable success criteria | Metrics may be missing, restricted, or defined differently across teams |
| Technical Integration Map | Systems, data flows, constraints, and integration risks | You need to assess technical feasibility and scope early | Avoid premature design or commitments before validating details |
| Security and Compliance Gates | Required reviews, standards, timelines, and responsible teams | Security or compliance could affect technical fit or deal timing | Requirements may emerge late or need specialist ownership |
| Decision Process Mapping | Evaluators, recommenders, approvers, blockers, and decision stages | You need to align technical proof with the buyer's approval path | Buyers may describe formal policy rather than actual practice |
| Evaluation Success Criteria and Solution-Fit Confirmation | Observable outcomes, pass/fail thresholds, judges, and desired future state | Before setting a demo or pilot plan | Criteria may shift or be too rigid; confirm feasibility and agreement |
| Trigger Event | Event that created urgency and the buyer's timeline | You need to test whether an opportunity has real momentum | Sensitive organizational changes may be difficult to discuss |
| Funding Path | Budget status, owner, approval path, and pilot versus production funding | You need to scope an evaluation that can lead to a purchase | Budget may be confidential or not yet confirmed |
| Prior Attempts and Stakeholder Scars | Past solutions, failure modes, and sources of skepticism | You need to uncover hidden requirements and avoid repeating past failures | Keep the conversation constructive and avoid turning it into a complaint session |
Pick One Question for Your Next Discovery Call
Don't try to run all ten questions on one call. Choose the two that expose the biggest gap in your current deal, usually impact and decision path, and write the exact phrasing into your call prep.
Pick one as your primary question. Use the other when the conversation exposes a dependency you can't ignore. You're trying to resolve uncertainty, not demonstrate that you prepared a long list.
Before the meeting, distinguish what you know from what your team has inferred. An AE's note that the buyer has budget isn't the same as an identified budget owner and approval path. A request for an integration isn't confirmation that the buyer can provide API access.
Turn Answers Into Evidence
After the call, write a short account of what you can now defend:
- Problem and impact: What happens today, who experiences the consequence, and which evidence supports it?
- Constraints: Which architectural, security, operational, and funding conditions must the approach satisfy?
- Decision process: Who must agree, what proof do they require, and what remains unresolved?
- Next action: Who will close the most important evidence gap, and when will you review it together?
Then summarize the problem, impact, constraints, and decision process before opening a demo. Ask the buyer to correct your interpretation. A correction is useful discovery, especially when it changes what you planned to demonstrate.
Don't treat every unknown as a reason to stop the opportunity. Some gaps justify a focused technical session; others require the AE to engage an absent stakeholder. The mistake is committing to a broad demo or POC without acknowledging what remains unproven.
For PreSales leaders, coach the follow-up rather than the question count. Review whether the SE noticed a vague answer, pursued the consequence, and assigned ownership to the missing evidence. A polished opening question doesn't compensate for accepting an unsupported answer.
If you want structured practice with feedback on your own calls, start with a free discovery call, or explore the Trusted Advisor Academy. Members apply frameworks to current opportunities and receive feedback on their discovery calls, demos, and POCs.
Your next demo should reflect something you proved during discovery. If you can't name what changed because of the conversation, keep asking before you keep building.
PreSales Unleashed GmbH offers structured PreSales development through the Trusted Advisor Academy, including discovery practice and feedback on active deals. Bring the questions you struggle to follow up on, and visit PreSales Unleashed GmbH to explore training that connects discovery, technical proof, and the technical win.