When a buyer comes out of a competitor’s technical deep dive repeating what its sales engineer said, your rep has to answer without knowing what was shown. A sales engineer is the technical specialist on a sales team, and the deep dive is the session where they take a buyer’s technical people through the product. That conversation appears nowhere on the competitor’s website, in its documentation or in its product tour.
So how do you find out what a competitor covers in that call? You go through its sales process as a buyer, and Mystery Demo does that for you. Its team takes a competitor’s sales calls as a credible buyer and carries the evaluation through to the deep dive, then hands you the recording and a shared board that marks each technical claim one of three ways:
For sales enablement and product marketing teams, here is why the call stays out of sight, how a buyer gets there, what usually happens in it, and which questions test what the competitor claims.
Why You Cannot See a Competitor’s Deep Dive From Outside
Everything public about a competitor’s product was written for buyers to read, and none of it can tell you what happened when a buyer asked to see the integration run. Each source gets you part of the way:
The answer you want only exists on the call, and the call has a gate in front of it. Guideflow, which sells demo software, calls sales engineers a scarce resource and advises presales teams to “require a completed discovery summary and confirmed technical decision-maker before scheduling a technical deep-dive.” A team that follows that advice will not give a stranger a deep dive.
Your own team runs into that gate first. An early-stage startup asked on Reddit in 2017 how to demo competitors’ products when each one wanted to know who was asking: “I tried saying we are stealth but that was not accepted.” The top reply warned that a live demo means “a lot of discovery questions before showing the demo.”
If your team does get past those questions, it still gets recognized, or gets the generic tour. So the way in is to be a buyer the competitor believes, one with a real reason to ask technical questions.
How a Mystery Demo Reaches the Deep Dive
We build that buyer for each competitor you name, and the deep dive is one stage of what follows:
All of it lands on a board, a shared Notion workspace with a page for each competitor. Below is the Research Objectives page of our public example board. The client and every competitor on it are invented, and a real project’s board is built from that client’s own calls.
Read the third objective, which asks what each vendor can show live against what it describes in slides. The fourth asks which security certifications are in place and which are only on a roadmap. Those questions are written down at the start of a project, so the deep dive has a job to do before anyone books it.
The call itself is where they get tested, and sales engineers are open about how it usually goes.
What Usually Happens in a Technical Deep Dive
Sales engineers talk about these sessions in their own forums and guides, and the table follows what they and their buyers say. These are individual accounts, mostly from the seller’s side, and not a measure of how often each thing happens. Your competitor’s version may differ, which is the reason to go and see it.
| Part of the call | What people on these calls describe | What it means for your team |
|---|---|---|
| Who joins | The sales engineer leads. One planning an onsite session expected the salesperson to “stay hands-off during the deep dive” and the buyer to bring “security and architecture leads.” | Who the competitor brings and asks for suggests the topics it plans to go deep on. That is a reading, never proof of how it rates the deal. |
| What is shown live | Often the product itself. That same plan went “straight through the console with no slides,” while a founder planned “a targeted show with simulated data.” | Shown working does not mean working on your buyer’s data, or available today. |
| What stays on slides | In demos generally, whatever there is no time to run. One seller keeps “table stakes/assumed capability” on slides because they “won’t have time to demo” it. | A capability on a slide was described, not shown. Nobody can say they saw it run. |
| Where the roadmap appears | When a question reaches something unfinished. That plan included checking “a couple of beta questions” with the company’s own engineers, and one interview guide coaches answering a gap with “the roadmap with realistic timelines.” | Anything said here is a promise. Keep it as one, with its date. |
| Questions that go off script | Questions about the buyer’s own systems, and requests to choose the test. One founder was told to “let them pick the inputs on their use case.” Hard ones may go on “a parking lot of questions.” | A question set aside is not a weak answer. The emails show whether the answer came. |
A live product is common in any demo. In Reprise’s 2026 survey of over 500 solutions engineers and presales leaders, 93% of respondents said they still demo on a live production environment. Reprise sells demo software, and it was asking about demos in general.
So “it was live” settles little. You want to know what data it ran on, and whether a buyer can have that feature today. Neither answer is in what sellers say about these calls, so someone has to ask, inside the call.
Questions That Test a Competitor’s Technical Claims
We take these questions into a competitor’s deep dive, each one aimed at a row of that table. They are ordinary things for a buyer to ask.
| Question | What the answer reveals |
|---|---|
| “Can you show that integration working, now?” | Whether it was demonstrated in this session, for this buyer. A no means not demonstrated, and nothing more. |
| “Is this generally available today, or in beta?” | Where the shipped product ends and the roadmap begins, even for something just shown. |
| “Is this running on real data or sample data?” | How far the demo carries over to a real setup. |
| “How would this run with our data volume and setup?” | Whether the answer is specific or generic, and whether the sales engineer has to go and check. |
| “What do you collect from our environment, where is it stored, and who can access it?” | What the competitor will say about security on the call, and what it offers to send in writing. |
| “What would implementation take, and who does the work?” | The effort behind the promise, and how much of it lands on the buyer. |
| “Which of my questions will you come back to, and when?” | What the sales engineer commits to. The emails and calls that follow show whether the answer came. |
Expect the security question early. One Reddit reply, advising a founder on a walkthrough for a room of security people, said of it: “That question usually comes before any feature question.”
Your reps can use the same questions. When a buyer brings up a competitor’s technical claim, a rep can suggest the buyer ask to see it running. That helps one deal, and you only hear the answer if the buyer passes it on.
Documentation says what a competitor wants technical buyers to believe. You only find out on the call if it will run the thing when asked.
.png)
Asking is half of it. The answers also have to be kept somewhere your team can use them without replaying every recording.
What Comes Back for Each Competitor
Each competitor’s calls go onto the Database page of the board, with the documents it sent. Here is that page on the same invented board.
The Notes column says who was on each meeting and in what role, so you can see when a sales engineer joined. Technical documents the competitor shared, such as an architecture deck or an integration guide, are listed in the same table as the recordings. A deep dive’s answers then move into Findings & Analysis, the page that compares the competitors one dimension at a time.
Every number here is invented, and the columns are the real part. Each row sets a vendor’s headline claim beside what was verified, and the Demo Method column says how it was shown: a live run, a trial or a number only cited. The same evidence feeds the feature matrix, the center of our competitor product comparison, which maps each competitor’s capabilities against your own product and gives each one a status:
A matrix cell is a summary, though. Behind it is the record of what happened to each claim.
How Each Technical Claim Gets Marked
The example below is invented too. It follows one made-up competitor, Rival A, in water utility billing software, through two technical claims. Like our competitor demo report example, it keeps what the sales engineer said, what the screen showed, what a public page says and our reading apart from one another.
The Shown line says how a claim came across on the call, and the Status line says what that earned on the feature matrix. Here is how the two claims end, and what each one means for your rep:
Your own team could try to reach a competitor’s deep dive. A record like that one depends on who collects it:
Even so, one deep dive is one sales engineer showing one buyer scenario on one day. It becomes a claim about the company only when it recurs across comparable calls. A call also shows only what a competitor tells buyers, so a promised feature stays a promise, the real roadmap stays out of reach, and so does anything shared only under an NDA, because we never sign one.
The price is a flat €499 per competitor, with every meeting, recording and analysis included, and one competitor takes one to two weeks. Start from the technical claim your reps find hardest to answer, and we will build the buyer around it, so the question gets asked on the competitor’s own screen. Walk us through that claim on a short call.
Start With the Claims Your Buyers Repeat
The technical claims your buyers repeat were shown to them, described to them or promised to them. For one recorded scenario, you can know which of the three each claim was. That is one sales engineer’s call, never the competitor’s roadmap, and it is enough to tell a rep what to ask next.
You can start on your side this week:
That list is enough to begin, gaps and all. Go through it with us on a call, and we will take the competitor’s process as far as it goes. Each claim comes back marked shown, described, promised or unresolved, with the recording or email behind it.
.png)
