Time to Market

Time to Market S01E11 – Mastering Product Demos

- - - - -

Étienne Garbugli: This podcast is a sequel to episode 8, about how founders learn sales on the job. Today, we will focus on how to demo software. I know you have done a lot of product demos and advised founders on how to give them. So let’s start with: why do you do demos? What is the core purpose of a demo?
Sean K. Murphy: There are two good reasons to demo your software. Either you want to give prospects a sense of what they can accomplish with your product, or you want to offer proof that it will provide them value.
So, it's either a glimpse of possibilities or some level of proof.
Étienne Garbugli: But why can't I just put an explainer video on YouTube? Shouldn’t that be good enough?
Sean K. Murphy: Well, an effective demo is a conversation that's driven by mutual curiosity. It's fine if you want an explainer video. You can explain the basics of your product. But the challenge is that products typically become rich and complex pretty quickly, so you're going to be more effective if you understand the particular needs of the person you're talking to or the team you're talking to so that you can tailor or customize your presentation just to what they're interested in.
I think founders are legitimately very proud of what they have built, which leads them to give a demo that combines a Swedish smorgasbord with an IQ test.
They show off features--but wait, there's more! There is a lot more! That's the smorgasbord. All the while, they are asking the prospect if they can figure out how to use it to make a positive impact on their business. That's the IQ test: Are you smart enough to figure out how to use this to help your business?
They skip any discovery questions about needs. And that's the problem with a recorded demo: you cannot do discovery, so you can't tailor it to the prospect's situation.
Étienne Garbugli: How would you distinguish between a proof of concept exercise, a trial evaluation, a demo, and an explainer video? I want to focus on demos but understand how you differentiate them from these other options.
Sean K. Murphy: An explainer video provides a basic description of core capabilities and lets prospects decide if they want to invest time in a conversation.
An effective demo requires an understanding of the customer's situation and needs so that you can either give them a glimpse of what your software can do for them that opens their eyes to possibilities or offer proof that your software can solve a particular problem for them.
A proof of concept exercise relies on real or at least representative data from a customer. This is sometimes called a benchmark, especially if the prospect provides the same data to multiple vendors they are considering. You may ask for the data and give a demo based on their example, or they may want to run it in-house because the data is too sensitive.
A trial is usually an in-house evaluation run by the prospect and completed within an agreed deadline. After the trial, they may license your or another vendor's software, implement an in-house solution, or decide to live with the problem.
You may provide several demos to different people from the prospect's firm. It's a low-cost way--compared to a proof of concept, benchmark, or trial-- for them to get their questions answered and for both of you to decide if you can help them.
Étienne Garbugli: So, discovery is critical to making a demo successful. It allows you to understand what the organization is trying to achieve, gain a sense of its goals, and narrow the scope of what you present to their specific interests.
Discovery allows you to shape your demo to avoid the time-wasting tour of the smorgasbord and make it less of an IQ test because you can make specific recommendations and perhaps even forecast the impact.
Sean K. Murphy: Absolutely, discovery is crucial. The tailoring it enables is expensive, but it makes a demo substantially more effective. As we discussed in the earlier sales episode, you only have a few prospects when you are getting started, so it makes sense to learn as much as possible from them and to take more time preparing a demo for them.

There is a situation where discovery is hard to do. That's when you are at a trade show, and someone walks up to your booth. You can ask a few questions, but often, they just want to see a demo. And sometimes they won't answer any questions and just say, "Show me what you've got."
You can offer them a short menu of options: "here are five things I can show you, which ones are you most interested in? Which would you like to see first?" The menu gives them an idea of the range of things you can do, and their selections give you an idea of their needs or interests.
Étienne Garbugli: I have seen organizations that won’t share much information about what they are working on until they have narrowed their options to two or three vendors. They may not want to answer questions but would likely be open to making choices from a short menu.
The founder has a different challenge. They only want to demo capabilities that relate to customer goals or needs. You can be ruled out by presenting too many extraneous features before you get to what they care about. You need to continue to ask questions during the demo to calibrate whether you are moving in the right direction.
Sean K. Murphy: The founder has to make it clear they are trying to give them a few drops of precisely what they need, not douse them with a fire hose, right? It's
OK to be excited about your product, but drip irrigation is better than flooding the whole field. The prospect may not want to turn over many cards until they are confident you can help them. Good questions that demonstrate knowledge of their industry can unlock more insight than generic ones like "Do you have a budget?' or "Who is making the decision?"
Étienne Garbugli: In my experience, people often have an idea of the solution they're looking for, and they will often use that as a frame for how they evaluate whatever you're going to show them.
This can lead to a misalignment in expectations, which makes it troublesome to get that initial agreement around whether it's a good fit or will take them in the right direction. Your product might do 60,000 different things, and maybe it does what the customer is looking for, but if you don't do discovery, you may not be able to present your capabilities in a way that matches their understanding of their needs.
I've seen organizations withhold the demo until they can qualify a prospect properly. They want to ensure they can frame the value add for the prospect in the demo.
They tell the prospect, "I'm trying to see how I can help you. I'm trying to assist you in getting the desired outcome that you're looking for." Sometimes, if you show the wrong features, prospects will put the product in the wrong box and disengage. Even though your product can provide them with the benefits that they're looking for.
Sean K. Murphy: The word "qualify" can have three different meanings. It can mean that the prospect fits the profile of other customers you have been able to help. It can mean you have done discovery and believe that your product can add value. Or it can mean that you have asked the BANT questions – Do they have budget, authority, need, and a timeframe for a decision? The first two are designed to help you tailor the demo; the last is used primarily to rule out a demo. Prospects tend to resist BANT questions because you are not trying to help them.
Prospects may also ask very early, "What does this cost?" Some salespeople like to be coy and dodge the question: "Why don't you take a look and we can discuss the price later." I think founders are better off letting the customer steer and answering their questions. That way, you are responding directly, and you can ask them a question in turn after you have answered theirs.
The reality is that the customer is in charge. You can back out of the sale or suggest approaches, but it's their call whether to proceed.
Étienne Garbugli: I think, especially in complex B2B sales, there's a question of which box you put this solution in, which will then dictate pricing, who from the customer will get involved, and what process they will follow to purchase.
So, your demo positions your solution and influences how the prospect will evaluate it. For example, if I lead with a dashboard that's part of my solution, the prospect may mis-assess or miscategorize what I am offering. They may perceive it very narrowly as only a dashboard or overlook more powerful analytics that may be valuable for them.
It can be hard to recover from an initial misperception. I prefer to get a good understanding of their situation and needs so that I can present our most valuable features first. This can prevent getting disqualified from further consideration when you have something they can use. I try to avoid premature elaboration before I understand their needs.
Sean K. Murphy: Everybody's pressed for time, and I think sometimes you can fall into a trap where, in the last three deals we closed, we demoed these two features of our dashboard. But those features may not match the critical needs of the person you're talking to now.
We have talked about the importance of diagnosing before you prescribe. Especially because it can be so tempting to start talking about the product instead of making sure you understand their needs,
Étienne Garbugli: There can be tension between making the sale and learning. How do you modulate this in a demo? Should the focus be on customer success or closing the deal?
Sean K. Murphy: My idiosyncratic view is that the customer is in charge and does the closing. Every conversation will involve learning and a commitment to customer success until you clearly have product/market fit and are scaling–even then, it’s a good mindset to maintain.
There is an assumption that you can find a "beaten path" that works reliably for the majority of your prospects and allows you to take a "crank it out" approach. But most startups take a while to find their path, and many never do. Even in established firms, B2B sales activity is typically discovery-driven because of product complexity and the wide variation in customer needs and requirements.
I'm a fan of just using slides for early demos instead of live software. It minimizes your mental overhead so you can listen better and jump exactly to the points you want to make. As I mentioned earlier, I view a demo as a conversation driven by mutual curiosity, where you are using example outputs from the software to illustrate your answers to prospect questions.
You'll need to do a live demo at some point, but that's usually a second or third one after the customer has opened up about their needs. It's hard to ask questions and worry about how to operate the software, so it's worth considering having two people participate: one who focuses on running the software and one who drives the discovery process. Slides work reasonably well and address questions that are "out of sequence" in terms of what you might have to enter in the software to be able to address them.
I have not had it happen in a while that a customer says, "That's amazing, in fact it's unbelievable. I don't think the software can do that, I want to see it live!" But if they were to, you can always say, "no problem, give me a minute and I will show it to you live."
Étienne Garbugli: I agree that demos can become a well-rehearsed performance instead of a conversation if you are not careful. They get viewed as a product activity instead of driving new business. Ideally, they should provide a valuable context for understanding the customer’s goals and exploring their process and the various outcomes they are trying to achieve.
But you can drop into “for my next trick let me click a few buttons and show you how we turn a base metal into gold.” And if it’s live software, waiting for things to happen gives you a few seconds to compose your thoughts when you should be curious about how the customer is solving the problem now. So you fall out of discovery mode and into presenting. But you are not learning anything when you are talking.
Sean K. Murphy: It's easy to fall into the trap of believing that talking and showing off features advances the sale. Someone may ask, "can you do X?" and you immediately start to show it. But a better approach is to answer "Yes" and provide a brief verbal description followed by "Would you like to see it?" That may be sufficient. You can also answer "No" and briefly explain why you don't, or ask a question or two to explore the specifics.
Sometimes, it's worth showing the details using live software, but many questions can be answered verbally or with a slide or two.
I started doing demos at an electronic design automation startup a few decades ago, the training department wrote the "Demo script." So I learned that demos were supposed to train people how to use the software--which was a terrible idea.
One time, I was giving a demo, and the customer "took control" of it and started to ask questions and ask me to show how to do certain things that were in a different order from my script--or, in some cases, were not even in the script.
So I started to react and say, in effect, I am supposed to be driving this, but the sales guy said: "Hey, just show him what he wants." So I did and it went much better than the canned presentations I had been giving. I realized that I had to start asking more questions and letting the customer lead the exploration.
Étienne Garbugli: But you were pre-sales? They viewed a demo as training before they closed the deal and made them the responsibility of the training department?
Sean K. Murphy: I was an application engineer who provided both pre-sale and post-sale support. It was an EDA startup in the early 80s. I joined when there were about a dozen people, and as they added people, they decided that demos were a documentation and training problem. In hindsight, they mis-assessed.
Étienne Garbugli: Well, different groups can own demos, and each comes with a set of perspectives on what the process should look like and what the outcomes should be for the customer. Choosing customer success, sales, or training as the owner leads to different approaches and different metrics. Each with its own set of tradeoffs.
Let’s look at some specifics. How long should a demo be, who should do the demo, and who should also participate and gather information?
Sean K. Murphy: The average executive attention span, in my experience, is about six to eight minutes. Managers will typically spot you about that much time to show them something that leads them to conclude, "I should learn more about that."
If you are not getting questions and other indications of interest, you have to start gracefully wrapping things up. It's better to end early so you can come back than keep trying and exhaust their patience. You can always email them afterward and say: "Hey, I was thinking about that thing you said, I just wanted to let you know, here's a screenshot, here's this or that." People are very sensitive to lost time.
Especially in Silicon Valley, many things may be forgiven, but wasting someone's time is hard to recover from.
There can be up to four kinds of people in the audience for a demo.
People who are going to use the product directly.
Managers for the direct users are also likely to use it and will have different use cases.
Senior managers, executives, and business unit leaders are less concerned with precisely how the software works but very concerned with what business outcomes can be achieved.
Gatekeepers and process owners are less interested in how it works or business outcomes. But they are very concerned that the correct decision process is followed or that the product will comply with policies.

In general, you want to speak to each group on its own. If you've got a mixed audience, you focus on the business person first because they're the most likely to leave. Next, you talk about the impact on business process and headcount–changes in productivity, error rates, cycle times–if they adopt the product, which are the managers' concerns. Third, many questions come about how to use it and what tasks can be accomplished or results achieved from the direct users. Finally, you can address questions from the gatekeepers, but it's better to defer those to a different meeting if possible. The users will typically wait and let questions from managers and senior managers be answered first, sticking around until they leave to get their questions answered.

Sometimes, you get a question from a gatekeeper that you must address, but you can generally defer it until after you handle questions from the other three groups first. You can write it down on a whiteboard or flipchart in a conference room or in a Google Doc on a Zoom call. You say, "I will come back to that. Did I capture your question? If the gatekeeper insists, you can ask the rest of the audience: "Is this the most important topic to address next?" If they say yes, then you must address it immediately.

Étienne Garbugli: So prospects will give you five or six minutes to grab their interest. You need to tailor your presentation based on who is in the room and your understanding of the organization's goals and objectives. And you need to communicate the specific value you offer that's different from what else is available.
Sean K. Murphy: There are two common mistakes founders make. They spend more than 20 seconds talking about their startup–unless they get questions on it–and they repurpose their investment deck as a demo pitch. A better place to start is with a critical output or information that will be useful after a user exits the application. What is the customer left with after they use the software? Is it a particular report or other deliverable that will be valuable to another department or their customers?
If you can show them something they need, the six-minute timer gets reset because they have questions and want to learn more. This may stretch into a 45-minute or hour-long conversation, or longer, that’s driven by their curiosity about your product and your curiosity about a particular set of business needs.
A third common mistake is to save the best for last, to treat the demo like a mystery novel or a magic act where the big reveal comes at the end. It’s better to show a critical output up front to grab their attention. If it does not, then it’s time to strike the tent and move on gracefully.
Étienne Garbugli: How would you know that your demo is working?
Sean K. Murphy: So, the demo is working if you're getting questions, if you're getting data from customers, if they're asking to bring more people into it, essentially, if the sale is advancing. Right?
Étienne Garbugli: How do you tune or adjust your approach with different customers? I would assume that different types of customers would get demos that emphasize distinct aspects of your software. How do you figure that out, continue to refine your approach, and keep moving in the right direction? How do you decide when to make changes and what to tinker with?
Sean K. Murphy: We've discussed segments before, but it's worth covering them again because first-time founders can be oblivious to their value. They don't want to segment; they want to be efficient by running every prospect through the same process.
You need to resist premature calls for efficiency and scale. Instead, remain alert to the likely possibility that different prospects will use your product to satisfy different needs.
Secondly, the way that you talk to managers is different than executives, is different from the users. Another word for an executive is the economic buyer. Ultimately, that is the person who will sign off on a purchase.
You must figure out what will move the needle: why will they spend money on your offering? What is it they want to see? What do you need to prove so they decide you are worth spending money on?
Étienne Garbugli: How and when do you know that your demos don't work? How does a startup team assess their effectiveness?
Sean K. Murphy: You can tell your demo didn't work when people became polite: "Étienne, I want to thank you for your time today. You've given us a lot to think about. Can we get back to you in a week or two?"
Very few will say, "You bored the crap out of us. You did not listen when we explained our needs and wasted our time. We're not coming back."
Sometimes they say: "Thank you, this has been helpful." But they find a way to put off a second meeting.
You are failing when your first conversation does not lead to a second one. I don't know what you're doing wrong if you do six demos and none lead to a second conversation. You may be talking to the wrong people. You may be telling them the wrong things, but it's not working.
Étienne Garbugli: You need to keep score on your process across all of your prospects: are your demos turning in evaluations and sales?
Sean K. Murphy: Another practice that feels less efficient is to put at least two--and often three--people on a demo. This allows at least one person to keep track of all the questions and gives you someone to debrief with afterward.
Especially in the early going, you must anticipate that you may never hear from a prospect again. So when you debrief, one question you must always ask--because your state of information won't get any better as time goes by--is if we never hear from these people again, where do we think we went wrong?
With another team member on the call, you can candidly discuss what seemed to go well and what went less well. We did not have a good answer to this question; we need to understand better what it means when they say "X." I am not sure I would have shown that feature that way.
Étienne Garbugli: I think a good takeaway from this discussion is the idea of taking note of the questions you're getting, the objections you're getting, and who is asking a particular type of question or making a specific type of objection. Because you need to adapt and adjust so that future demos will improve after you apply what you have learned. You can be stumped the first time you get a question and fumble it the second time, but eventually, you will learn what resonates in different situations. Your discovery process should also become more effective as you experiment and understand how to diagnose various problems.
When we talked about tough calls a few episodes back I suggested that teams needed to build a decision factory, a system that reliably delivers good results. Do you see that mindset applicable to building the demo process as well?
Sean K. Murphy: Yes, and one way to make it more effective is to resist creating one standard process. You don’t want to be the doctor who tells everyone who calls, “take two aspirin and call me in the morning.” You need to diagnose the specific problems and constraints on a solution a prospect faces and tailor your demo to their particular needs. This approach will make your engagement process or intake flow much more complex but should increase the number of follow-on conversations you have and, ultimately, the deals you close.
Étienne Garbugli: Do you have a final take away?
Sean K. Murphy: You should definitely look at competitor demos when you can. You can learn a lot from how they solve the same problems you do and the discovery questions they ask. How do they differentiate their value, and how does that compare with your approach? You may be able to do the same things they do, but you may need to feature them better.
Étienne Garbugli: Good suggestion: founders should regularly put themselves in the customer's shoes and consider what it feels like to buy software. Buyers will typically look at demos from many companies and then pick a few for more detailed consideration. Learning how your competitors run their demos gives you a better chance to figure out how to make it into the final consideration set. It's also a good idea to ask a prospect who else they are looking at because it can give more insight into how they view their needs.
This is a good place to end the discussion. Please contact me on twitter at @leanb2b or Sean at @skmurphy with questions or topics you would like to see us address.