Discovery call vs demo: what the demo needs from discovery
A discovery call finds the customer’s problem and what solving it is worth; a demo shows how your product answers it, so discovery usually comes first.
A demo built from discovery opens with the customer’s problem and shows only the parts of the product that answer it. To do that, the Sales Engineer needs four things before the demo: the problem in the customer’s words, the outcomes they named, who will be in the room and who decides, and the next step the demo should lead to. Write them down with the account executive before the call, and mark which ones are still assumptions.
What is the difference between a discovery call and a demo?
A discovery call is where you learn the customer’s problem and what solving it would be worth; a demo is where you show the parts of your product that answer it.
Discovery should leave you with the business problem in the customer’s words and a possible champion. Without that, a demo tends to follow the product’s menu, and nothing the customer said appears in it.
Discovery continues after the demo starts. A good demo raises new questions, and the technical work after it raises more. PostHog’s sales handbook describes discovery as “give and take”: “You learn something, you show something, you ask questions, repeat.”
What the demo needs from discovery
Use discovery to choose the customer outcome to demonstrate and the next step to propose.
Open the demo with what the customer said in discovery, show the capabilities behind the outcomes the customer named, and agree the next step with the account executive. The opening needs the customer’s own words and the name of the person who said them. The capabilities you show follow from the outcomes they named, and the rest of the product can wait. The people in the room decide which part matters most: a business owner and a technical architect may need different parts of the same demo. The Sales Engineer’s technical discovery adds what the customer uses today and what the product has to fit.
Peter Cohan’s Great Demo! method starts a demo with a Situation Slide that sums up the customer’s situation: “Their overarching goals, their current situation, pain and problems, the specific capabilities the prospect is looking for, the value desired, and the required timeline.” Cohan’s point is that a slide like that takes discovery, and qualification alone does not fill it.
Who brings each part
The account executive brings the business context, the Sales Engineer brings the technical picture, and both agree who asks each question.
Every deal has a technical puzzle, a business value puzzle and a qualification puzzle. The Sales Engineer leads the technical puzzle and shares the other two with the account executive. Both need to understand the problem in the customer’s words. The Sales Engineer investigates the systems the product must fit and brings the unanswered technical questions.
In a 2025 survey by Reprise, which sells demo software, 39% of 100 Solutions Engineers at enterprise software companies named “Not sharing information from discovery soon enough” as a frustration with sales reps, compared with 34% for “Bringing me into a demo with unqualified prospects”. Asked which changes would improve collaboration, 40% of the same 100 Solutions Engineers chose “Collaborate on discovery questions before the first call”.
Write the split into your engagement model: which deals get a Sales Engineer, from which stage, and what the account executive brings to the first meeting.
How four software companies order discovery and the demo
Published sales processes differ: some make discovery a stage before the technical seller joins, some run discovery as a joint meeting, and some put the demo inside the first call.
GitLab’s published rules say “SAs should not be engaged prior to Stage 2-Scoping” and route exceptions through the Solutions Architect manager. Separately, its handbook page on demonstrations says its Solutions Architects “are occasionally called on at a moments notice to give a demo”.
Flexpa’s published process lets the hand-over happen before the need is settled: “it’s ok if the BDR passes off the lead to the Sales Engineer and still needs the Sales Engineer to fully establish N”, the N being need. Its Sales Engineer joins the rep’s call when the use case is “promising but unclear” or the audience is “Large / Very technical”.
In FlowFuse’s handbook, discovery turns the customer’s problem into a use case, and the use case shown in the demo is “a hook, not the point”, ideally close to the customer’s own problem from discovery. PostHog’s handbook describes a broad suite of products and one call in which discovery questions help choose which of them to show.
| Company | How discovery and the demo are ordered | When the technical seller or the demo comes in | What must be known first |
|---|---|---|---|
| GitLab | How discovery and the demo are ordered The sales team handles early discovery and qualification | When the technical seller or the demo comes in A Solutions Architect from Stage 2, Scoping; exceptions approved by the Solutions Architect manager | What must be known first MEDDPPICC qualification, with pain “clearly articulated based on discovery” |
| Flexpa | How discovery and the demo are ordered A business development rep qualifies, then hands over to a Sales Engineer, whose work includes demoing | When the technical seller or the demo comes in The Sales Engineer after qualification, or on the rep’s call when the use case is promising but unclear or the audience technical | What must be known first Budget, authority and timing; the need may still be open |
| FlowFuse | How discovery and the demo are ordered A discovery call, “generally followed by a Demo” | When the technical seller or the demo comes in The SE joins at discovery, which they run with the account executive | What must be known first Before the demo: a use case tied to the customer’s business impact |
| PostHog | How discovery and the demo are ordered One call: the customer’s situation, a demo of 15 to 20 minutes, next steps | When the technical seller or the demo comes in The demo in the same call, after 5 to 7 minutes on the customer’s situation | What must be known first Research before the call; the customer’s goals shape the demo |
Which order fits your deals?
Choose the order by what the demo has to show. If the right demo depends on the customer’s environment or on several people agreeing on the problem, run discovery as its own meeting, with the Sales Engineer there or briefed. If the customer can see the value in a short look at one part of the product, one call with questions before and during the demo can do both.
When the demo is booked before discovery is done
Use the first minutes for discovery: confirm what you know, ask what you do not, and then decide whether to show one relevant outcome or to keep asking and book a focused demo.
A recommended recovery, in four steps:
1. Before the call, the account executive and Sales Engineer compare what each of them knows about the customer and write down what is still an assumption.
2. Open with what you believe the customer needs, and ask them to correct it before you show anything.
3. If they confirm a problem and an outcome the product can answer, show that part and stop there.
4. If they cannot, use the meeting for discovery and agree a focused demo, with the people who need to see it.
A shared pre-call plan sets out who asks which question and what you would show, and when.
A pre-demo brief for the account executive and Sales Engineer
A pre-demo brief is a short page the account executive and Sales Engineer fill in before each demo, with every line marked known or assumed.
The problem, in the customer’s words, and who said it.
The outcomes they named, and what each is worth to them.
Who will attend, and their part in the decision.
What they use today, and what the product must fit.
What you will show, and which outcome each part answers.
The next step you will ask for at the end.
Any line still marked assumed becomes a question for the first minutes of the demo.
Sources
- Solutions Architecture Rules of Engagement. GitLab Handbook, November 2025.
- Demonstrations. GitLab Handbook, September 2026.
- Go to market. Flexpa OS, undated.
- Sales Meetings. FlowFuse Handbook, undated.
- Discovery. FlowFuse Handbook, undated.
- Demo. FlowFuse Handbook, undated.
- How to do discovery. PostHog Handbook, undated.
- Seven Validated Habits for Stunningly Successful Demos. Peter Cohan, CustomerThink, April 2023.
- The 2025 Demo Landscape for Solutions Engineers. Reprise, February 2025.
Facts last checked on 28 October 2026.