While much has been written about how to construct a good fundraising pitch, there has been relatively little discussion about the demo itself. But the demo can often make or break a pitch — especially for founders building products focused on mass market end users. When you’re trying to build something transformative but are just starting out, your demo (should you choose to include one) should crack the door open and instill confidence that stellar things are ahead for your product and company.

So, here are the five most common mistakes I tend to see with fundraising demos, and some thoughts on how to address them.

Mistake #1: The Random Walk

Most demos feel kind of like a random walk. It seems as if the founder feels they should include a demo in their pitch, so they bake in time for it. But then it seems like the demo itself is not at all rehearsed and is all over the place. You’d be surprised how often during demos I hear founders say to themselves “hmm … let’s see … what else can I show you?”

Your demo should have a very specific purpose, usually to highlight something positive and important. I like to say that the demo should elicit 1 or 2 exclamation marks. These include:

  • Woah, this team really obsesses over great design!
  • Woah, what that product just did was magical!
  • This founder is really resourceful. How did they get that done when they aren’t technical and have such limited resources?
  • That particular flow/viral loop/interaction is amazingly good!

The risk of meandering is especially present if you allow the investor to “drive” the demo. While it seems cool to have an investor just play around with the product, you really only want to let the investor “drive” if a) it’s a consumer social product and/or b) it’s a 1:1 meeting. For everything else, it’s better if the founder drives the demo themselves. The exception around consumer social is that I think that great products and unique interactions are hard to experience as a third party. You just need to touch and feel the product yourself to appreciate it if it’s good or really, really special.

You don’t want to go through the rigmarole of a demo if you don’t think the investor will be wowed by something you are showing.  Create exclamation marks or rethink whether you should do a demo at all. 

Mistake #2: The Time Warp

Managing the timing of a demo is tricky. You usually want to get to your exclamation points quickly, land the punch line, and then wrap.

I find most demos have fairly awkward timing for two easy-to-fix reasons:

1) Taking too long to get to the meat of the problem.

The first is taking too long to get into the meat of the product. It’s amazing to me how often I find that demos start with some sort of generic initial flow that tells you nothing about the quality of the product or team other than that they have built something that 99% of other products also have.

If you are going to show a sign-up and onboarding flow, it should be because you think there is an exclamation point associated with it. Otherwise, skip it and move on.

I highly suggest having a few tabs open prior to the start of the pitch. This way, you can jump in wherever you want to or shift to the parts of a flow that are really interesting if the investor’s attention starts to wane.

2) Moving too quickly through the good stuff.

The opposite problem here is moving so quickly it’s tough for the investor to feel like they have their bearings and actually appreciate the good stuff that you are showing. Also, if you have practiced your demo or given it a bunch of times, it’s easy to forget what it’s like to see your product for the first time.

So, when you get to your first important screen, pause, and talk through what the investor is looking at. Start with who the user is supposed to be, so they can put themselves in those shoes. Talk through the relevant parts of the page so they have some baseline understanding of what they are looking at and where everything is. It may feel tedious to use precious time to lay that groundwork, but you’ll find that you can start to move more quickly after establishing a baseline. 

Mistake #3: The Buggy Demo

There is a law of the universe that says demos done in front of investors will fail proportionate to the importance of the pitch.

It’s like entropy, you can’t really fight it, so you need to ensure against it. Have a backup plan in the event that something goes wrong. Have a backup connectivity option in case there are wifi issues. Have the demo ready to go on a backup machine in the case that yours craps out.

Some founders have effectively used pre-recorded demos. I find these can be quite good in three situations.

The first is when you want to cover a lot of ground, because part of the exclamation point is to show how complete and robust the product is even at an early stage. It ends up being easier to move around and speed up low-value flows through a pre-recorded video. It also eliminates the risk that something goes wrong.

The second situation is when your product is incomplete and buggy. A bunch of things may not really work as designed yet, so it’s better to pre-record it and ensure that it goes more smoothly. It’s hard to get away with this when your company is more mature — at that point, you should really be showing the real product. But when you are pre-launch, I think this can be a reasonably good approach instead of trying to demo something that you know is buggy.

The third is when you are trying to show an actual interaction with a customer or third party. If your product is in the market in some way, it doesn’t hurt to just show a recording of the product in action.  This allows you to cherry pick the best interaction, and no one will hold that against you.

Mistake #4: How Do I Know This is Really Working?

Demos of AI products can sometimes be tricky because it can be hard to appreciate how well it’s really working and how it compares to something totally generic. If the idea is that your product is drawing insight from huge amounts of data, how is one to know that this is actually correct? Or, could you just have fed this info into ChatGPT and gotten the exact same thing? 

If your product is predicated on a better model or unique data that leads to better outputs, be ready to highlight this. It’s ok to show some canned examples if it really makes the point that your product is interesting and unique. You also may want to be able to show the trail of reasoning that led to the unique output. Even if the demo feels a bit manufactured as a result, it’s more important to hammer home your point and create confidence that the product actually is doing something unique.

Mistake #5: Function Over Form

I think design is integrated into a product, not a veneer slapped on afterwards. It’s not like you have a core technology and then just slap on a pretty interface. Instead, I think great products are well conceived end to end experiences, and core technology makes these experiences possible. This is a bit of a contrarian POV right now because building software products is increasingly seen as a commodity. But I think it’s actually the opposite — AI makes building functional software a commodity, but that means that designing elegant and truly effective products is even more important. 

So, I often question the value of showing unpolished products with the caveat that “We haven’t given this any design love yet.” Why would you show a demo at all if it isn’t well designed? The only reason to do that is if the product has some jaw-dropping, unique functionality that is very apparent even with bad design. Even for AI products, the magic often is in the integration between a performant model and a product that is delightful and natural to the end user. 

Hopefully these are helpful thoughts. For a while, I felt like we were moving away from demos as SaaS was becoming more mature. But with AI applications, I think demos are making a comeback, and executing on them well is becoming more and more important. I’d be curious if folks have other examples of common pitfalls around demos, or tips on how to really make these demos sing. Please share!