Who Should Demo?

  • by

Who Should Demo? This isn’t a trick question – the answer is everyone, but different roles and situations call for different demos.


A few years ago, someone in product marketing issued me a bit of challenge.

“Why can’t anyone demo?”

She didn’t mean it as a question. The implication of the question was clear: “Demoing isn’t that hard – why can’t anyone do it?”

But take the snark out of the question, and there’s something reasonable there.

Anyone can demo. But demoing well, like anything else, is a skill. One that gets better over time, and, of course, with practice and coaching.

Compare it to marketing. People go to school for marketing (myself included). They start in a junior position and work their way up (myself included). You don’t expect someone brand new to marketing to run everything – it takes training, experience and practice. And even then, there are plenty of people better at marketing than I am – it’s why Martha is the head of marketing for Demo Solutions.

Demoing as a job doesn’t quite have the same obvious career path. Many enterprise companies such as SAP or Salesforce now have entry-level training programs for presales, but that’s relatively new. Those of us who have been doing the job for a while fell into it – often by accident. I’m only in presales because my first boss, Mike Fazio, ran a call with me as a business partner and saw that I had potential.

Assuming anyone can, with practice and coaching, run the demo – the question becomes who “owns” it?

I’m going to answer my rhetorical question with another question: What is the demo?

What is the demo?

This sounds like I’m trying to be way more new-agey than I am – but I mean it as a serious question. I believe that the phrase “the demo” is a bit of a misnomer. There shouldn’t be just one. There should be different demos for different audiences, delivered at different points in the sales cycle.

That doesn’t mean creating multiple demos. It means having the ability to ask questions and select the appropriate content for the meeting.

The word “demonstration” comes from the latin dēmonstrātiō, which means “deduction or proof,” and the verb “demonstrate” comes from the latin dēmonstrāre, which means “to indicate, describe, show.” Demonstrate means “to show clearly, to prove or make clear by reasoning or evidence, or to show or prove the value or efficacy of to a prospective buyer (thanks Merriam-Webster).

Take the word demo at its definition – it does not mean “show off live software,” or “show features.” A demo is literally (not figuratively) about value. And proving value doesn’t require live software.

A demo can be a whiteboard (back when I worked for Joe Cosentino when we were at IBM, I once saw him demo the most complex element of our solution in about 10 minutes with nothing but a whiteboard, and the whole audience was engaged. It was incredible).

A demo can be a PowerPoint.

A demo can be a video (if it’s in a meeting, it should have a live narrator, not a recorded one).

A demo can be a conversation.

A demo can be discovery.

Again, and I can’t stress this enough, a demo does not have to be live software. Sometimes the best demos aren’t.

What this means is that different teams can have different “demos” for different situations. Here is a guide for what each team member can potentially do as their demo during the sales cycle.

Who Should Demo? What each role can do for their demo

As you consider what each team member is doing as a demo, an easy rule to follow is the Pareto Principle (also known as the 80/20 rule), which (paraphrased) means that 80% of the gains come from 20% of the work. Early in the sales cycle, 80% of calls should be discussion and discovery/20% demo, and near the end, it should be reversed. This is because the prospect doesn’t care about everything your software does.

80% of the value of the software is going to come from 20% of the features (and associated benefits). Your goal as a salesperson early in the cycle is to figure out what that 20% are. If you just throw features at the wall and expect something to stick, that might occasionally work, but it means you’re leaving a lot of potential deals on the table.

The SDR/LDR/BDR/Inbound Rep/Inside Sales (whatever title you use) demo

Yes, SDRs can demo. But they should demo one thing.

An SDR’s primary job is to qualify a deal. Whether you use a framework like BANT (budget, authority, need, time), MEDDIC (metrics, economic buyer, decision criteria, decision process, identifying the pain and the champion), SPIN (situation, problem, implication and need-payoff), or anything else – the SDR’s primary task is to figure out whether someone has the ability to buy. Does the prospect have money (or access to it), do they have authority to make a decision (or access to that person), etc.

When I was running an SDR team, in a 30 minute call, 20 minutes would be spent asking questions, 5 minutes would be spent on a “here’s what the software does at a very high level” demo, and 5 minutes would be spent on next steps.

The SDR demo should follow the same framework as any other demo – context/feature/benefits. But there’s just one thing they show in that framework. This demo can potentially be the same every time, or there can be a few versions of it. But this demo is not at all custom.

Account Executive/Account Manager/Seller demos

I’ll be the first to admit that this perspective is that of a presales person, but the AE’s job is to run the deal. I’ve heard trainers say things like “you’re the CEO of your deal,” which we all know is a bit of a stretch, but let’s go with it for now.

First, before anything else, an AEs job is to run discovery. Where the SDRs qualification is focused on can someone buy, the AE then focuses on the use case, or is there a reason to buy.

This is where 80/20 comes into play. The early call with an AE should primarily be a conversation. They should get to that customer want/need. What is the opportunity? Why are we talking? How can we help?

Once the AE has identified the use case (ideally multiple, because the first use case identified usually isn’t the really important one), then they can deliver a brief demo.

The AE demo should follow the structure of any presales demo – interesting (limbic in Demo2Win! parlance) opening to get the audience’s attention, context/feature/benefit, and a value close.

The goal of this demo is not to show features. It’s not to give a guided tour of the software. That’s where presales can come in.

The goal of the AE demo is to prove that they have something valuable to offer. That they can help with whatever use case they uncovered. That they listened to the prospect, and that they are the vendor with the answer (or not – disqualifying a call early isn’t usually a bad thing).

Something that I’ve found to be successful is creating what we called the “Level 1 demo.” This was a demo that was intended for anyone at the company to deliver. It was 100% in powerpoint, but had embedded videos to showcase live software. The AEs then had a few talk tracks that went with the software (a set list, not a script), and were able to spend the time proving value. This demo was only about 15 minutes (max) as it left the bulk of the call open for questions. The key to this demo is that what is shown doesn’t change, but the talk track does. This way it feels “custom,” even though it isn’t.

The “Level 1 demo 2.0” is similar, but it’s much more flexible. This is where the presenter (typically the AE, but can be presales) has ~5 potential topics and, after discovery, focuses on one or two specific areas. This demo is particularly useful when there hasn’t been any discovery prior to the meeting, but the customer is expecting a demo. With a demo like the “level 1 demo 2.0,” the customer thinks they are in charge, but the presenter is actually in charge.

Having a demo like this allowed the AEs to show something and not make the prospect wait for presales, which meant the prospect felt like they saw something, and it also meant that presales could focus their time on later-stage deals. This solution is very much a win-win-win.

Presales demos

The presales team is the primary “owner” of the demo. It can be built in conjunction with product and marketing, but ultimately, presales is the team that’s responsible for how it is delivered.

The goal of presales is to build out the use case with the customer. To identify the value points and to show that the company can do them.

Not to just show features. But to prove the value that the AE identified (and/or to identify more value points).

How technical the discussions are will depend on the role of the presenter (a less technical Solution Consultant like myself, or a more technical Sales Engineer or Architect), as well as who is in the audience. Is the business in the room? Not technical. Is IT in the room? Have at it with the technical discussions.

When I was in the field, I’d like to say that I was diligent about using the material that marketing sent, but that wasn’t always the case. And most presales people are the same way. It came down to accountability – regardless of who wrote the demo, I was accountable for how it was delivered. This is why strong cross-functional teams are so important. The more support I had from marketing the better, but I was going to do whatever I had to do to make sure the deal moved forward. Because that was my job.

Product team demos

When the product team demos, it’s all about the future. What features are coming down the pike? Why are they being added? What benefits will they provide to the customer?

A product person’s role in a demo is primarily to discuss roadmap. When I was in the field, I would never discuss roadmap unless it was absolutely necessary, and even then I had to “safe harbor” the hell out of it, and give the disclaimer that I wasn’t on the product team.

Again, it comes down to accountability. I wasn’t going to be accountable for someone else’s roadmap.

Marketing demos

Marketing teams can often butt heads with sales/presales teams, and it usually comes down to collateral. Marketing collateral is often (not always) great as a leave behind, but not so much as a presentation deck. This is because that content tends to be feature heavy, or has a lot of words. As I’ve discussed many times before, words on slides aren’t your friend.

The other reason that marketing demos can be challenging comes back to accountability. Marketing and sales often butt heads because they are being measured differently and working toward different goals. But here’s the good news – it doesn’t have to be this way.

A few years ago when I first led a presales team, one of my first tasks was to build a new demo. And rather than try to build it on my own, I worked closely with a marketing person. I whiteboarded what I wanted the demo to look and feel like, but I needed branding/copy/collateral that she had. The result was something far better than any of us could have done on our own, and I still use some of the ideas behind what we created.

If marketing teams are involved with demos – I recommend the following:

  1. Sit in on meetings with sales/presales. Watch how customers react to the content. Listen for the questions they’re asking.
  2. Don’t create just one deck – the presentation deck and leave behind deck are related, but not the same.
  3. Build content in conjunction with the sales team. There’s a cycle that often happens between sales and marketing – marketing builds the deck, sales ignores it, marketing gets frustrated that sales isn’t using the new stuff, sales gets frustrated that marketing is frustrated, and no one wins. But if everyone sits down together and has shared goals, the end result can be pretty great.
  4. If you are a marketing team member who is demoing – spend some time practicing with your friends in sales/presales. And have them practice with you as the audience. It’s a great way to build rapport and help each other grow.

Founder demos

Most of the time, founders shouldn’t demo.

I mean that with a great deal of respect for what a founder’s role is. Their role is to set the vision for the company, not to show the software. Plus, founders often have trouble getting out of the weeds of the software, or hearing criticism (it’s their baby after all).

A much better role for a founder is to be the executive sponsor of a demo. Be in the room to show vision, and to give the prospect confidence that they’ll have access to senior leadership. But let someone else live in the day-to-day of the software. Plus, it’ll keep the founder from getting bogged down.

Different demos for different folks

Everyone can demo, so long as they have the right training and coaching. It’s a skill, like anything else. It should happen differently depending on the role, but with a little bit of practice, anyone can be confident in front an audience.

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.