There's a popular claim floating around Solution Engineering circles: large language models don't understand what a good sales demo looks like. It's a tidy soundbite, and it's wrong — or at least, it's answering the wrong question.
The real question isn't whether the model knows. It's whether you gave it enough to work with.
The Prompt That Started the Argument
Someone asked Claude a deliberately bare question: give me a good tip to improve my demo performance. No context, no stakeholders, no deal stage. Just that.
The answer that came back was this: focus your demo on the decision-maker. Put the economic buyer's priorities at the center. End users ask a lot of questions but they don't control the budget, so don't let them dilute your demo time. Keep the conversation at the business level, address the economic buyer's motivations first, and don't get dragged into a feature debate that only matters to people who won't sign anything.
Read that cold and it's genuinely solid advice. Focus on the most important person in the room. Make it benefit-centric for that person. Stay out of the feature weeds. There's a lot of validity packed into a few sentences — and much of it isn't even about demo craft, it's about who you're demoing to.
But here's the catch. If you're walking into an end-user deep-dive tomorrow, that advice is close to useless. The model didn't fail. The prompt did. A high-level, generic question can only get a high-level, generic answer — one that's simultaneously right and wrong depending on a context the model was never given.
"It Depends" Is the Point, Not a Cop-Out
One objection to the advice was that the economic buyer often isn't even in the room. And that objection is also context-dependent.
If you're selling into large enterprise — DAX-level accounts — you will almost never have the CFO sitting in your demo. But move down-market and the picture flips. In companies with 50 to 100 employees, the managing director or the owner is frequently the person who booked the demo in the first place. They lead the buying project themselves. In those deals, concentrating on the economic buyer isn't just defensible — it's exactly right.
So the model's advice isn't universally true or universally false. It's a lever whose value depends entirely on your segment, your deal, and who's actually attending. The models have ingested essentially every book on B2B software sales. With good context, they'll give you good advice. Without it, you get a coin flip dressed up as insight.
How to Actually Use an LLM as a Demo Coach
If you want real value, stop treating the model like a fortune cookie and start feeding it your reality. A few practical moves:
- Build a reusable context block. Teach the model who you are, what you sell, who your buyers are, and what you care about in a demo. Store it as a prompt or a custom assistant you reuse, so you never start from zero.
- Separate the organizational layer from the content layer. Before you touch any product, questions like "who's the most important person in the room?", "should end users get a separate session?", and "what happens if the C-level ducks out early?" are pure structure and strategy. LLMs are strong here, and it's often where deals are won or lost.
- Feed it your transcripts. Upload the recording or transcript of your last demo. Ask for a scoring rubric, then have the model track whether specific things improve session over session. That loop — score, adjust, re-score — is where a generic tool becomes a personal coach.
The skill isn't in the asking. It's in the context you bring to the ask.
Portfolio vs. Single-Point Solution
The second recurring debate: when you have a portfolio — multiple modules, add-ons, roadmap items — do you demo tightly around what the customer asked for, or go broad and light up the whole product fireworks?
Field reality splits into two camps. One tells SEs to keep demos as simple as possible, tease almost no future features, and drive straight to closing. The other deliberately widens the deal from the start, stacking use cases and modules to grow the contract.
The cleaner default is land-and-expand: go in with what solves the problem you and the customer have already agreed is real, urgent, and worth fixing now. Prove you can solve that one problem. The customer already understands you offer more; you don't need to bury them under a catalog and hope something sticks.
But notice the trap in how the question is usually framed. It's posed as a demo decision — what do I show? The real work happens earlier, in discovery. There's a difference between what the customer thinks they need and what they actually need, and discovery is where you separate the two. A good question can even expand the customer's own awareness of a problem they hadn't fully named.
So the sequence matters: discover broadly, then decide deliberately what to show. If discovery surfaces a second and third use case, you can still consciously choose to focus the first engagement on use case one and phase the rest in later. Mentioning a roadmap item to build a small vision is fine. Dumping the entire portfolio because a quota line told you to is not.
And it gets harder with platforms that have a strong base product plus many complementary modules. A CRM is "everything and nothing" — you can pack anything into it. That's exactly when discipline matters most. Start somewhere. Solve one real problem. Generate real value. The customer has limited implementation capacity anyway.
The Metric SE Leaders Rarely Discuss
Here's the lens that actually settles the portfolio question — and one that's almost absent from PreSales leadership conversations: customer acquisition cost.
Borrowed from marketing, but applied to the full sales cycle. How much SE and AE time, how many demos, deep-dives, and discovery calls, how much infrastructure does it take to win an average deal? Multiply that out and you know what it costs you to acquire a customer.
Now the strategic choice becomes quantifiable:
- Land-and-expand often carries a lower acquisition cost per unit of net-new ARR, because expanding an existing customer takes one meeting, not five. Once someone is a customer, use case two and three sell fast.
- Bundle deals lengthen the cycle and raise acquisition cost per deal, but if the bundle takes the contract from 100k to 300k, the math can still favor it.
There's no universal answer — but there is a calculable one for your business. The uncomfortable truth is that most SE leaders can't tell you their net-new ARR per unit of effort. They should be able to.
One caveat on land-and-expand: it carries adoption risk. If module one sees weak usage, the customer won't be ready to buy module two in six months, and your expansion thesis collapses. That's why the decision has to be holistic — factoring retention, adoption, and reputation, not just the first signature. Bundling something at a discount that nobody uses isn't a win; it's future churn.
Where This Is All Heading
Pricing models are shifting from license and seat-based toward consumption and credit-based — in e-commerce, payments, and increasingly in CRM, HCM, and ERP. When revenue tracks usage, you can't win with a clever bundle and coast. You have to keep delivering, constantly, or the customer simply switches off and there's nothing left to invoice.
That's the honest version of the business. Solve an essential problem, earn trust, and the expansion comes back to you on its own. Both the LLM question and the portfolio question resolve into the same principle: focus beats breadth, and context beats confidence.
Listen to the full episode
The original conversation (in German) goes deeper on demo coaching, portfolio strategy, and acquisition economics: PreSales Unleashed: Geben LLMs gute Demo Tipps? (270)