Discovery Call Framework for SEs

SE discovery is not the same as sales discovery. AEs qualify the opportunity (budget, timeline, authority, need). SEs qualify the technical fit (current stack, integration requirements, evaluation criteria, technical decision makers). Both are required. Neither substitutes for the other.

This framework covers the SE-specific discovery approach that uncovers the information needed to deliver winning demos, scope successful POCs, and build technical champions who advocate for your product internally.

Why SE Discovery Matters

The data is unambiguous on this point. Deals where SEs run thorough technical discovery before demoing close at 35-45% win rates. Deals where SEs skip discovery and lead with demos close at 20-30%. That 15-percentage-point gap is worth millions of dollars in pipeline over a year. Discovery is the highest-ROI activity an SE can perform, and it's the one most frequently shortchanged.

Why do SEs skip discovery? Two reasons. First, AEs pressure them: "The customer wants to see the product. Just show them." Second, SEs themselves want to show the product because demoing feels productive while asking questions feels slow. Both instincts are wrong. The 30 minutes you invest in discovery saves hours of wasted demo time and dramatically improves your win rate.

The Two Tracks of SE Discovery

SE discovery operates on two parallel tracks. Technical discovery maps the customer's environment. Business discovery maps the customer's motivation. You need both to build a compelling case.

Track 1: Technical Discovery

Current Stack

Understanding what the prospect uses today is the foundation of everything that follows. The questions:

• "Walk me through the tools and systems your team uses for [relevant workflow] today."
• "Which systems would our product need to integrate with on day one?"
• "Are there any tools you've evaluated or tried before for this use case? What happened?"
• "What does your team's tech stack look like beyond this specific workflow?" (This reveals integration complexity and organizational tech maturity.)

Listen for red flags: legacy systems with limited API support, custom-built tools they're emotionally attached to, recent large investments in competing solutions. These don't kill deals, but they shape your strategy. A prospect who just spent $200K implementing a competitor 18 months ago is a very different conversation than a prospect who's starting from scratch.

Also listen for positive signals: frustration with current tools, recent leadership changes that create openness to new approaches, and explicit mentions of evaluation criteria ("we need something that integrates with Salesforce and handles our HIPAA requirements"). These signals tell you where to focus your demo.

Integration Requirements

Integrations break more deals than features do. Dig deep here:

• "Which integrations are must-haves versus nice-to-haves for your evaluation?"
• "What does data flow look like between your current systems? Who manages it?"
• "Are there any compliance or data residency requirements that affect where data can flow?"
• "What's your team's capacity for implementation work? Do you have dedicated ops or engineering resources?"
• "Are you using any middleware or integration platforms (MuleSoft, Workato, Zapier) today?"

The implementation capacity question is critical. A prospect with a 3-person IT team has very different integration needs than one with 50 engineers. Your demo should reflect this reality. For the small IT team, emphasize out-of-the-box integrations and simple configuration. For the large engineering team, show API flexibility and custom integration capabilities.

Security and Compliance

For enterprise deals, security review is often the longest phase. Uncover requirements early:

• "What's your security review process for new vendors? Who leads it?"
• "Are there specific compliance frameworks you need us to support? (SOC 2, HIPAA, GDPR, etc.)"
• "What are your requirements for SSO, data encryption, and access controls?"
• "Have previous vendor evaluations stalled or failed during security review? What caused that?"
• "Is there a security questionnaire you'd like us to complete? When would you need it back?"

Getting the security questionnaire early is a power move. Most SEs wait until the prospect sends it. Proactive SEs ask for it during discovery and submit it before the prospect expects it. This accelerates the security timeline and signals that you're organized and experienced with enterprise evaluations.

Technical Decision Makers

Identifying who makes the technical decision is as important as the technical requirements themselves:

• "Who on your team will be evaluating the technical aspects of our product?"
• "Is there a separate security or architecture team that needs to sign off?"
• "Who makes the final technical recommendation? Is it the same person who makes the business decision?"
• "Are there other stakeholders we should include in the demo or POC process?"

Track 2: Business Discovery

Timeline and Urgency

• "When are you looking to have a solution in place? Is there a specific event or deadline driving this?"
• "Where does this initiative sit in your team's priority stack?"
• "Have you allocated budget for this, or does it still need budget approval?"
• "What happens if this initiative gets delayed by 6 months?" (This reveals urgency level.)

Evaluation Process

• "How are you evaluating solutions? What does your decision process look like?"
• "Are you evaluating other vendors? (If yes) Who else are you considering?"
• "What criteria will you use to compare solutions? Is there a formal scorecard?"
• "Who needs to be involved in the final decision?"
• "What does a typical vendor evaluation look like at your company? Demo only, or do you run POCs?"

Success Criteria

• "If you implement a solution and it's successful, what does that look like? What metrics would change?"
• "What does failure look like? What would make you regret this purchase in 12 months?"
• "How does your team measure success with your current tools?"

The "failure" question is underused and powerful. It uncovers the prospect's biggest fears, which are often the real evaluation criteria (not the formal scorecard). If they say "failure is a 6-month implementation that disrupts our team," your demo should emphasize rapid time-to-value. If they say "failure is choosing a vendor that doesn't scale with us," your demo should show enterprise scalability.

Building a Technical Champion

A technical champion is someone inside the prospect's organization who believes your product is the right choice and actively advocates for it. Building this champion is one of the SE's most important jobs. Champions don't appear by accident. They're developed through the discovery process.

How to Identify Potential Champions

• They ask specific, detailed questions (not generic ones)
• They share internal context voluntarily ("My boss cares about X" or "We tried Y last year and it failed because...")
• They push back constructively (they're invested enough to challenge you)
• They suggest additional meetings or stakeholders to involve
• They follow up between calls with questions or requests

How to Develop Champions

• Give them ammunition - After discovery, send them a summary they can forward internally. Make it easy for them to explain why your product fits. Include specific data points: "Based on your team's volume of 10,000 records per day, our platform would process in under 30 minutes compared to the 6 hours your current manual process takes."
• Solve their personal problem - The champion isn't just buying for the company. They have personal stakes: career growth, team efficiency, looking smart to leadership. Connect your product to their personal win. "If this implementation goes well, you're the person who brought in the tool that saved the team 20 hours per week."
• Be responsive - Champions go to bat for you internally. When they message you with a question from their CTO at 4pm, respond fast. Their credibility is on the line. A 24-hour response time from you undermines their advocacy.
• Coach them - Tell them what to expect from the security review, what the next steps look like, and what objections might arise from other stakeholders. An informed champion is an effective champion. They can preempt objections before they become deal-blockers.

Discovery Anti-Patterns

• The interrogation - Rapid-fire questions without context or acknowledgment. Discovery should feel like a conversation, not a deposition. Acknowledge answers, share relevant context, and make the prospect feel like they're getting value from the conversation, not just being data-mined.
• Asking questions you should know - If the company's tech stack is on their engineering blog, don't ask about it. Research beforehand and ask informed follow-ups instead. "I noticed you're using Kubernetes in production. How does your team handle auto-scaling for the data processing workloads?"
• Skipping discovery for "quick demos" - When AEs or prospects say "just show us the product," push back gently. "I want to make sure I show you the parts that matter most. Can I ask 3 quick questions first?" This takes 5 minutes and transforms your demo from generic to relevant.
• Not documenting answers - Write everything down. Discovery notes drive demo customization, POC scoping, and deal strategy. If you forget what they said, you'll deliver a generic demo. Take notes in real time during the call (a second screen helps) and clean them up within 30 minutes of the call ending while context is fresh.
• Discovery once, then done - Discovery is not a one-time event. Technical requirements evolve as stakeholders get involved. Run mini-discovery at the start of every subsequent call: "Has anything changed since we last spoke? Any new requirements from the security team?"

For how discovery skills are evaluated in interviews, see our interview questions guide. For the next step after discovery, see our POC management playbook.

Related Career Guides

Get the Weekly Pulse

Salary shifts, tool intel, and job market data for Solutions Engineers.

Join 500+ solutions engineers getting weekly data

Get the Weekly Pulse

Frequently Asked Questions

What is SE-specific discovery?

SE discovery focuses on technical fit: current tech stack, integration requirements, security and compliance needs, evaluation criteria, and technical decision makers. It is separate from AE discovery which covers budget, timeline, and business authority. Both are required to advance enterprise deals.

How long should SE discovery take?

A thorough SE discovery call runs 30 to 45 minutes. For complex enterprise deals, you may need 2 to 3 discovery sessions with different stakeholders (end users, IT, security). Never shortcut discovery for the sake of speed. The time invested pays back in demo relevance and deal win rate.

How do you build a technical champion?

Identify people who ask detailed questions, share internal context voluntarily, and push back constructively. Develop them by providing ammunition they can share internally, connecting your product to their personal career goals, being highly responsive to their requests, and coaching them on what to expect in the evaluation process.