Crafting and delivering convincing demos

Speaker 1: As Matthew said, I am here today to talk to you about crafting and delivering convincing demos. I have been working on demos for the past few years, and that has sort of become my area of specialization within DevRel. With that, let's get right started. So in my talks title, crafting and delivering convincing demos, there are three keywords, and those form the three parts that I want to talk to you about today. The three parts are crafting, delivering, and convincing.

Speaker 1: So let's start with convincing demos and talking about what makes the demo especially convincing. And to do that, let's first cover why we actually demo something. I think there are three main reasons people demo things. The first one is to increase awareness. You want the audience to know about a product or maybe a new feature.

Speaker 1: The second reason is to explain the value proposition of your feature or product and do that in a way that the audience will understand it better than when it's written down. The third reason and possibly the main the main reason is to inspire and convince your audience. The first to increasing awareness and explaining the value proposition can sort of also be done in different ways with slides, words, videos maybe. However, a demo has something special in that it is especially inspirational and convincing. The best way to get people to evaluate and get people convinced of a product is to get them to interact with the product itself.

Speaker 1: The demo is sort of the second best thing. If you can't get everyone to try it themselves, then they can at least see you show them the product. So with these three reasons for demoing in mind, we can deduce some markers that make a demo convincing. And I think a demo is convincing if the audience remembers the product or feature afterwards and if the audience understands the value proposition of the product or feature. And lastly, if the audience has ideas how the product or feature could help them in particular.

Speaker 1: Now these three things are all things that you can measure, luckily. You can send out a post event survey and ask people maybe a week after, hey. What do you remember of the conference? What are the products that most stuck out to you? What what are they useful for?

Speaker 1: Maybe you can even do that afterwards by just talking to people. Then, of course, be a bit aware you may have confirmation bias. The last thing on here with leaving the demo with ideas about how something is useful to the audience, to to the user in the end is, I think, the most crucial one because you generally do want those sign ups. You do want people to use your feature or pay for it. And the best way to do that is if after the demo, they write away now, oh, this is what I could use it for.

Speaker 1: So that is something your demo should deliver to them. Okay. Now that we've talked about what a convincing demo is, what the markers of that is, let's talk about crafting and delivering these convincing demos. When I craft a demo, I generally go through five stages. That's what I call the life cycle of a demo.

Speaker 1: The first one is where I gather information and requirements for the demo, and the second one is where I brainstorm the story and start to develop the demo and the code. Then I go into scripting and rehearsing. And the fourth phase is where the actual demo delivery happens, And then I add another phase at the end, which is to make the content that I created in this demo reusable for the rest of the company. So the first three phases here, gathering, developing, and rehearsing, is sort of what I consider the crafting part of the demo, and the last two are all about delivery. And if you're wondering, okay.

Speaker 1: That's actually quite a lot if you split it up like that. And if you want to know how long it should take you to create a demo, I would say a good demo takes about ten to forty hours to create on average. You can be a bit quicker if you already know a lot about the product. However, I think that's a good ballpark. Of course, you can also take a lot longer if it's a very elaborate demo.

Speaker 1: But I think these are, again, good ball ballparks to aim for if you are starting to create demos. Okay. So let's dive into each of these phases starting with the gathering of requirements. So when I start a new demo, I like to create a demo requirements document. In this document, I will outline what the audience is.

Speaker 1: So this is where I write down, hey. The geographic of the geographic location of this is Europe, maybe Germany. Then I write down what the industries are, which will be present and will be in the audience, and even language affinities. So if I know, hey. The crowd that's going to come to this particular conference are PHP lovers, then that's good to know because I can craft my demo based on that.

Speaker 1: The second requirement that I put in here is the time. So how long can the demo be? Then I write down what the platform is. Will this where will this be demoed? Is it an in person conference, a virtual thing, a a Zoom Zoom meeting, or whatever?

Speaker 1: That's good to know because it it kind of limits and informs what you can do with the demo. Then I write down a list of stakeholders of people who should be involved and, optionally, also how far they should be involved. Are they approvers? Are they collaborators? That's all good things to know, and it's good to be on the same page with these things.

Speaker 1: Next thing that I put into this document is strategic messaging. And for that, I draw on the messaging that already exists within the company. So if you're demoing a product or a new feature, chances are someone else in the company has already built some sort of messaging around that. And it's really good to start from that and include that. It ensures consistency, and it means you don't have to reinvent the wheel and do a lot of work because you can just build on what's already there.

Speaker 1: The last thing I'd like to include in here is just a section to jot down ideas if you already know something that you want to cover in the story or implementation for the demo or if someone else has already brought up something like that. So building on these requirements, you can then move on to the second phase, which is brainstorming and developing. So building on these requirements, you may already have an idea for the story. If you don't, think about what specific use cases may resonate with the audience that you've outlined in the requirements. If that doesn't help, ask the product teams or other stakeholders what this feature or product was built for.

Speaker 1: Was there a specific customer who had a specific need and asked for this? If you have something like that, that can make a really good story to tell your audience. And if it's a real world story, even better. Once you've locked down the story, you then go on to developing. There's nothing super, like, exciting about this.

Speaker 1: It's just you need to do the work. The one thing that I can give you a tip for is if the product you're working with or the feature you're working with is still in beta, make sure you embed closely with the development team. Then you can save time if something is broken because you'll probably know, and you won't spend hours debugging just to find out, oh, actually, the feature is broken right now. Oh, well. And the other tip I can give you while developing is you can cut corners and you can hard coat things.

Speaker 1: Just don't do that for the main thing you're trying to show off. But it's perfectly okay, say, if you are demoing a login provider and you're trying to show how how quick and easy that is. It's okay to hard code the screen that people land on afterwards, things like that, as long as it's not the main thing of your demo. It's not going to hard code it. Alright.

Speaker 1: Now that you've brainstormed the story and you've settled on that and you've started developing the demo, it is time to actually start scripting. And this is something that you can that that some people might want to skip and might want to just do in in their head, but it's really good to write it down to ensure clarity, to make it shareable, and to make sure that you meet the requirements. If you just jot down some bullet points, that will already help because you can then check off what you're hitting, and you won't forget any pieces. So for scripting, there's a few tips I can give you. The first thing is when you're scripting for demo, don't think about it like a tutorial.

Speaker 1: People tend to approach a demo and then work in things like, and now you click on this, or now I click on create. This is not you're not trying to teach someone how to use the product right now. You're trying to tell a story. So instead of saying, now I click on create account, I'm saying, now I create an account, and then I click on it. So the audience in this case stays in the sort of story mode, and that's better for them.

Speaker 1: The next tip is people love to see code, but they don't love to be overwhelmed by it. So you need to find some sort of balance. And if you do have a lot of boilerplate code, take a step back when you bring it up on screen and explain what is on screen. Sorry. Okay.

Speaker 1: The next tip is and that's a repetition, but draw on the product's messaging from the requirements. It can make it so much easy easier for you to write this demo and write it well. Then the next thing and last part of this is if you can build an interactivity into the script, that is super great. However, if you do that, always have a plan b. Either plan someone in the audience who will definitely play with you or do whatever you expect them to do or have a backup plan just in case.

Speaker 1: Alright. Next is scripting. The other thing that you need to do in this space is rehearsing. So and while you rehearse, you will ensure that the script and the story flow well. You will go back and make adjustments and sort of iterate that way.

Speaker 1: That is the whole point of rehearsing in this at this stage. While you rehearse, what's really good is and what the number one tip is that I give to other people who ask me to review demos is do a Zoom call, share screen inside the Zoom call, and only you have to be in the Zoom call, record it, and then review it. That way, you can really see what's working and what's not working, and it will really improve your demo. Next tip is always time yourself when you do a run through. Don't always have to record it, but always time yourself so that you know whether you will be on time or whether you need to maybe cut some more content.

Speaker 1: The last thing is to share these things. So if you have a recording, you can share it with people. If you have script, you can share it with other people. It makes it so much easier if you have collaborators who can comment and help you make things better. Okay.

Speaker 1: So with scripting and rehearsing, these things sort of go hand in hand. So see those as really something that happens where you're moving sort of between the two, doing them both at the same time. And, also, again, repeating this because it's really important, collaborate with other stakeholders. They can make your demo so much better. Now if you've done all of this, there's one more thing you can do to make sure that your demo is really convincing and really good, and that is to test it.

Speaker 1: By that, I mean, test it on someone who doesn't already know the product or feature and then ask them for general feedback they have. Ask them to explain the product or features back to you. Compare what they're saying against the messaging that is in your requirements document. And lastly, ask them what ideas they have for what they would do next with this. For this, you can do a bit of role playing.

Speaker 1: Ask them to pretend they are of a certain industry and have a certain product. So but the main point here is you can actually check off all of these things, and let's make sure you have a convincing and good demo. Alright. So after all of this rehearsing and scripting, you should be on a very good path to the demo day. So that's the next step.

Speaker 1: So for demo day, it is super useful to have a sort of pre demo checklist. The things I put on there are the following. I say, I need to be there at least 30 before it starts, whether that's an online or a an in person menu. Next thing is then disabling notifications, closing other programs. I want to make sure that I don't forget to do that because it's annoying if a notification pops up while you're demoing.

Speaker 1: Then enabling caffeine or amphetamine, that makes sure that your that your laptop doesn't go into standby while you may be waiting to go up on stage. Next thing is set appropriate zoom levels for the web browser and software. So for that, go to the back of the room if it's an in person event, and just make sure that you can see everything even from the back. Then if you have time, and especially if that's a high stakes demo, do a full run through or multiple. If you're co presenting with some others, practice the handovers.

Speaker 1: And lastly, that's something that people tend to forget, reset the demo. That it it's not a great experience if you go on stage and then you find the data from your last run through and you go, sorry. I just need to reset this right now. Okay. So so much for the demo checklist.

Speaker 1: If you run through that and you've done all the rehearsals, you should be doing a great job with this demo. However, things happen. Demos can go sideways. If that happens to you, don't panic, of course. Try to stay calm, but also debug the issue.

Speaker 1: Debug the issue while talking about what you're doing. So if you're seeing a four zero four, say, oh, okay. Seems like we can't connect. Maybe the server that we just tried to deploy isn't actually running. Let me go to the terminal and check the logs.

Speaker 1: That way, the audience stays engaged, and it can actually make the demo even more engaging, more exciting to the audience. So it's not a bad thing if this happens as long as you can recover. And if you have rehearsed enough, you probably have a good idea of what went wrong already because you may have run into it during rehearsals. Alright. So now the demo's all done, there's one more thing to do, and that is to make the content reusable.

Speaker 1: And the way I like to do that is to add it to a wiki, add instructions, and add the code so that people can reuse it. And I have a template for this much like with the demo requirements. It looks like this. What I put on there is the strategic messaging, so the most important message that we're trying to get across when we deliver this demo. I add setup instructions with the link to the code and things like that.

Speaker 1: I tell people what windows or tabs they should have open when they start the demo. I give people reset instructions that they should run-in between demo runs. And lastly, I give them the script. Now here, I always add a note that this is an examples And I encourage readers to adjust this for their specific audience or goals because those are generally not exactly the same. Okay.

Speaker 1: Now with this demo documentation, other people can build on it, or you can build on it. You can build blog posts and tutorials on this content. You can do video content, or you can use it in streams. If you go on Twitch stream and you want to do something that is a bit more, you know, rehearsed rather than live coding. Okay.

Speaker 1: So I think I've got a few a bit more time, two more minutes to give you a brief summary. So here again are the five stages of crafting and delivering demos. You start by gathering requirements about the audience, the time, the platform, staycoms, and the messaging. Then you brainstorm the story for your demo, and you start coding the demo. In the third step, you script, you rehearse, you collaborate with your other stakeholders, and if you have the time, do a test.

Speaker 1: Then you're ready for demo day. Use a checklist. Stay calm. Explain if you're debugging. That way, your audience will be guaranteed a good experience.

Speaker 1: And lastly, with all of that done and you having spent maybe up to forty hours on this, make sure the content is reusable so that others who may want to use it can use it easily for blogs or videos or streams or other things. And then after the demo, check with your audience. Check that they remember the product or feature. Check that they understand the value proposition, and check whether they have ideas on how the product or feature could help them. And if some of that could use improvement, iterate on the demo.

Speaker 1: After the demos, before the next demo, you can always improve things. Alright. I think that is almost my time up. So thank you very much for listening, and I look forward to the q and a.