AA169 - Product Demos Gone Wild

Om, I have a story to tell you, because of my position, I go to a lot of product demos some in my company, some outside my company, so you'll, never get out of me where I was when I went through this product demo, but I went through a product demo and oh boy, if they could have hit a speed bump or an accident or any kind of problem that could have cropped up, It happened in this demo and I felt so bad for the presenter, but also the inner development early career Brian within me just was you know, saying I've been there if I had a nickel. For every time that a product demo went wild, I would have a bunch of nickels. I'm getting there. You are getting there. Product demos. Yeah. So these are. These are necessary evils, I'd say, right? You have something you've built within your organization. You have to show it to people so they can get interested in buying it. So you can't get around it. You have to have product demos. And I've been to a lot of those myself. I've actually conducted a lot of demos myself as well in a previous life. So you know, the whole point about product demos is you go in there with intent to show your best product, right? You put your best foot forward, and you hope everything goes well, if the stars align, which they don't always. And things do go wrong often, actually, so this podcast, we can kind of Scratch your surface. So what might go wrong? How can you get prepared for that? And what to do if you find yourself in that situation? Yeah, I'm using the term product demo very liberally because it could be a sprint review. It could be a a conference demo. Any of those things where you're demonstrating the software or you have a beta software or brand new software features or whatever that the customer is seeing for For the first time, any of those are applicable. But again, I just sat through this demo and everything that could have went wrong. I like the, the server crashed and then the, you had performance scalability issues that were apparent. And then when the data did come back, it was the wrong data. And every, every, everything that could have went wrong, went wrong. But again, I'm one of those early adopter users where even with bugs, if I have to click it a couple times or refresh the page, I'm still going to get to the outcome. I want to see it through to the end no amount of blow ups or spill overs or whatever are going to deter me from sticking to the demo. I'm that kind of user. So, that's a good point. So, you're that kind of user, right? And the person doing the demo has to understand his audience. If they're open to that, great, right? Just roll with the punches, right? But if they're not and here I'm thinking about not necessarily like sprint demos where you've your audience, cause they've been to many sprint demos If, if you're at a demo where external folks come, maybe a trade show, whatever it might be convention, right? And you're demoing to audience that is here to, for unknown to you. Mm-hmm., right? And things go wrong. Now to rescue the situation really is in the hands of the demonstrator, largely. There's usually somebody else, right? Overseeing this as well. There's usually somebody in sales or marketing. You know, who's doing the talking over, right? They maybe introduce the product, what it does, they introduce the company, and then they introduce the demonstrator. And then the demonstrator then runs with it, and things perhaps fall over, right? So at that point, it can either be the person who did the initial talking, right? Or it could be the demonstrator who tries to, quote unquote, rescue the situation here. Right. But if you don't know your audience like you were saying, you're okay. When, if you have to hit refresh twice people in the audience are looking to potentially buy the product. Yeah. You don't know how that's going to rub them the wrong way, perhaps. Right. So as a demonstrator, what do you, what can you do? Or, or if you're one of those salespeople or, or marketing people, what can you do I always find that making light of the situation Is always a strategy because it buys time for the demonstrator to perhaps hit that second refresh, change something in, in what they've done. And then hit hit the query again or whatever they've done. That's always a good way to go make light of this situation and do it that way. I've been in demos where the audience has been in the hundreds. And you try something, you know it's worked every single time because you prepped it, right? You practiced it and it worked. Except on the day, it didn't. So I'd say, okay, I'll try that one more time with interest. This time, do it with sincerity, right? And then try it. That's my second refresh. And if it works, great. If it doesn't, just say, well, if it were to work, maybe it'll work this time. That's my third refresh. So you can, you can find yourself in those situations quite easily. The other thing you can kind of hope to get away with, and you don't always, right, is to say, We added new features, right? And this is beta software. You get what you get, because we want to show you everything that we have thus far. You know, I could show you a release that's safe and stable, that's two weeks old, where everything just works, but you're not going to be able to see this new functionality, or at least the direction that we're heading down, right? That gives you a little bit of a pass. But if it happens over and over, it can really bury you. even the idea of a sprint demo is that it's, it's like a snowball the more it rolls, the larger it gets. That's the idea. The idea should be your customer satisfaction, right? The more it rolls, the more the customer sees, the happier they should become. So if they ask for something tiny in Hey, I like this feature, but it doesn't really solve the problem. What I really needed was. This other thing, you know? Oh, I you created a let me think about, lemme think about a feature for a second. There's one that I wanna reference, there was a feature one time where you take a picture of a document and then you send it to your home office. Like I've talked on the podcast a bunch of times about working on logistics, right? So that the, the truck driver has documents. They get it. They get a signature on their documents and the documents delivered. They take a picture and then they send it to their home office, their home office. Can then process the delivery and get paid for it because they have the signature. They have the paperwork right away. That's great. What's faster is all the little fields that are on the document. They get read and OCR and then automatically entered in the system so that somebody in home office doesn't have to manually rekey it. Yeah. Rekey all those values and then potentially make mistakes. Sure. Okay. So that was like the next evolution. So, they might get a demo. Take a picture of the document. There it is. Press the button. Now it's in your home office, it's in your inbox, it's in your workflow queue, whatever it is. Ready to process. And they might see it in the demo and it's like, wow, that's really great, that's cool. I can get started on the document right away. But, what do you think if we could OCR these values and do whatever? Wow, well at Brian and Om's Software Development Company, we never thought about OCR. Work on the OCR technology. Why don't we go see what's in the market, see what the cost is, try a few of them, try two, three of them, and then next, next sprint demo, we'll demonstrate which, what, which ones we think are the best, and we'll demonstrate how it might work on your document to you, and then if you like it, then we'll put it in the application, and then the next sprint demo, it's, you're basically working off of, What their requests were last time. Maybe you'll, you'll do other stuff in your sprint. Probably that might not take all of your time. Right. But that wiggle room that you get, like they're paying your bills now. You know what I mean? They're super happy next sprint. Hey, here's, here's the top. You know, the top OCR engine in the industry or whatever works really great works 90 percent of the time for your documents. Maybe that's good enough. Right. Do you want us to implement it? Yes. We want to implement it. Okay. Well, if we implement it, this license, all this stuff has licenses, fees, whatnot. Yeah. You got to pay this much additional, sure, no problem. Super easy decision. Now, boom, development team just made some money and now we got to go back to the people that see development as a cost center and say, Hey, look, we made money. And then we break their brains and then yeah. And then, and then everyone gets fired. That's what I'm trying to say. You see what I did? I introduced a whole different podcast. That is a different podcast. What are you going to do when you're not a cost center? Anyway, like that was, I don't know if I'm going to leave this in or keep or cut it out of the podcast so we can stay on the topic. And not have me whining and complaining about software finance again, again, again, again, and again. The more that you demo and those users that saw something last time, Hey, we, we did this with OCR. We were picking we're picking numbers off of your documents or letters or whatever characters off your documents. And we're putting it down in fields, even if that blows up server crashes, whatever, in the middle of demo those customers are still invested. Their willingness to go along for the ride because they are bought in already. That is different than when you're demoing to somebody that you're trying to make a sales to. Exactly. To you make someone that you're trying to make a sale to for the first time. You know someone who doesn't know that, that, oh, your company is not the kind of company where you, you ask for something and then you write your congressman and then you copy it and triplicate and you send it into the void, and then you get a megaphone and you scream into the void and then. Three months later, maybe you get a status report from a project manager. And, you know what I mean? Like that kind of thing, like the normal ask for an enhancement from Facebook and see what you get that kind of thing, you know? Yeah. Yeah. Right. Internal customers. I'll just say, right. People that you're demoing to with your, your sprint reviews frequently, it could be external, but people that are known to you, right. To your point, they're vested. If the server crashes or whatever. And you excuse you know, them and say, look, it's just going to take me another five minutes to reboot. It's not the end of the world. But yeah, I mean, if you've got audience that's just coming in for the first time looking at your product, they don't really maybe even know your company that well, right? So it's not just the product functionality that they're looking for. They're looking for the company as well, right? How are the, how are the company members treating them? All of that. If it blows up the first time, it is really up to the person doing the demo to find a way to sidestep it, find a way reboot the server, whatever it takes, right? In my experience, there's a whole plethora of strategies that can be employed here, depending on your experience level doing demos. You know, the other one that. I deal with more recently in my line of work is the shuffle that you and the salespeople have to do when you're demoing anything that involves an LLM or any kind of machine learning type of model in any way, shape or form. Like everybody knows those models take a while after you hit run, they take a while. So you gotta do a little story or a little shuffle or tell them a little bit about what's happened on the back end and then hope. That your hope so good. Yeah. Hope that your, it will hope that you come through, hope that your input is known. You know what I mean? That, that was what you were saying is like, Hey, I've done this demo a million times, right? And I know it comes back in less than 15 seconds. So I got a few little prepared quips stories things that take them that take about 15 seconds. I think every. The funny thing about this is sales people are trained in this kind of thing. Maybe it's like on the job training that they're trained, trained in this kind of thing. Or maybe maybe they get trained by the company in, in The, the how to present the product or whatever, but a very rarely does the product team, the product manager, developers QA people, whoever like sit with a salesperson and get critiqued on Hey, this is kind of how you could improve this skill. And these are ways you can do better just, just some, some feedback on the method of demoing. That's super valuable. I think of maybe one company I've ever been at, maybe two, one or two, single digit number, regardless, that, that, that I've, that I've ever been in a position. Where the people in sales, marketing and whatnot actually sit in the demo and then gave me some feedback about like, here, here are some ways that you could have connected and things that you could have done to improve your presentation skill and your demonstrate the demonstration of the software and how you tell your story and lead through that's that's I don't know, it's kind of sad when I think about it. I was just going to say what a lost opportunity, because that's really the easiest way to get feedback is to From your own staff, from your own salespeople, marketing people, product marketing, what have you, right? This is a safe environment when you're doing your practice sessions. So get that feedback and then really hone your technique. So when you do have to do a demo for quote unquote for real, right? You've incorporated that feedback. But some of the good salespeople though you can't really do that. First of all, look, let's just acknowledge that you can't really prepare for all eventualities. Things will just happen right out of the blue and in that situation, for example, where you've run this query several times, you know it comes back somewhere between nine and 15 seconds every time, right? You do it in the demo and 15 seconds go by and nothing still spinning the spinner. Another five seconds go by. And now you're starting to get anxious as a demonstrator. It's like, what's going on here? Right? So again, either yourself, if you have some experience or the sales people could say in the previous version, this used to take 25 seconds, right? And then let's say the query returns in 18. Now it's less than 25, right? So you situation that situation has been turned around at that point. You can just say we've improved this. We've done nothing really different. Probably. It's just how you kind of. You know, it's it's it's difficult to. Overcome the situation as a demonstrator. You could do the same thing. You could say nine times out of 10. This comes back in 20 seconds, right? And you know that to be you're really being economical with the truth. Let's face it, right? You know that to be not quite true because it comes back. Let's say 15 seconds or less 20 seconds. It's a little longer and then it actually comes back in 18. You still don't look as bad if it comes back in 20, you don't look as bad because you've set the expectation now, right? And that only happened in the In the moment when you hit it and you went past the 15 and it hasn't come back yet Last thing you should do is just simply sit there and stare at the screen or even worse is gee what's taking it so long? That's what really pulls the the good demonstrators away from the ones that have done it a while, right? So yeah, I mean there's a lot of things like that that you can get better at with practice Right and practice with your internal stuff. Your point is It's just invaluable. Oh, one more on the audience engagement. So if you don't know, really know your audience, be very careful in this Being bold with them and say, Hey, would one of you like to come up and hit the keys on the keyboard? Or would you like to role play? Yeah. Right. I know the intent is good, right? Because you're trying to say this isn't really canned. Yeah. It can backfire on you. I've seen it backfire. Not because the audience is like doing this maliciously or anything. I've seen it backfired because the person that was selected from the audience, English wasn't their first language. And when they were asked to do something, they just misinterpreted it totally. And they were confused. We are now seeing them confused. Everybody else in the audience is not going to get a good vibe from this. Right? So just know your audience. There's two things inside of knowing your audience that I think about as real, , important concerns for me. Number one is their technical proficiency. Right. So it depends on the feature you're showing them, but if you're showing them something deep something that requires a lot of like I think about like a data analytics product that I worked on where we were, we were publishing data, like low level data. You can go to the catalog, select your data source, and then pick the columns out of your data source. So it's sort of like a, like a simplified SQL type of deal. That, that requires people to understand like, Oh, what, what are these fields for that we want? You know, what data source is do I need? You know, if I want to get a particular type of report or build a particular dashboard if they have very little data proficiency. Yeah. Like they're, they're gonna struggle in that. The other side of technical proficiency is that something about their use cases, their, their pain points that they're trying to solve. You know, something about it ahead of time. You know that this particular group is trying to build dashboards. Is struggling because they don't have access to all these different data sources. They need to build the dashboards every time they go get a different data source, they got to get permissions and sign offs and it says, et cetera. And if they're going to use your data platform, They can kind of shortcut all that because you've dealt with it all for them. They have access to everything that the different data providers are happy to provide, and are willing to provide without additional sign offs or whatever. Or maybe there's special things built into your platform where they can get access to things. But anyway, , you know their technical proficiency, and you know their pain points. And you can tailor the demo to both of those. Yeah, that's a key point. You know, cause that's the difference between people kind of just walking by your booth and be like, Oh, that's kind of neat. And, and the people saying that like, Oh, this is something that could be life changing or transformative. And something that I would be willing to pay for because it's so useful that Yeah, I, I think that's a, that's a really key point. So what, one of the things I've seen over the years is people certainly having the, the actual demo live demo. Right. But also at the same time, they have these monitors on pedestals. Scattered around their booth where a product demo is self running. And I never liked the idea because You don't know who the audience is. You don't know what pain point it's solving, if any, from the audience. So the only play you have is, this is like, this is cool. Right? That's the only thing you have. And who's willing to pay for that? Unless it's gonna hit that this is solving my problem. So I never liked that. I always liked, The idea of signing people up, walk ins are always welcome, but you can have multiple demos of different types going on depending on your product portfolio. But have knowing that people can sign up and you can reach out to them and say, what is it that you're looking for? Yeah. Right. What problem are you trying to solve? And when you, when you, when you're astute, what you can do is you can recognize those people in the audience and say, what One of you don't have to call them out. You can say one of you have this problem perhaps in the audience, and this is how our product helps solve that. Yeah. That's that is the way that kind of really hit the mark, right? Yeah. Otherwise you're spraying with a big hose, right. And, and hoping something sticks. No, that's a much smarter way, especially if you're deployed with the team, like conferences, stuff like that. And the team is observing, listening, they can bring back and share the things that they've heard with the audience so that when they have, when it's their time to resent You now can tweak and tailor your presentation for the things that your team has heard. So you're sure that you're resonating with people rather than guessing Oh, we'll do the big bang presentation all around the world presentation. Yeah. Because, because one of the things that like, especially product demos, I've done a lot of them the other thing that you deal with in every product demo, just like anytime you do any kind of presentation, corporate presentation is there is never enough time, regardless of whatever time you have. Like there is never enough. That's the universal truth. It is never enough time. So managing your time in the demo presentation, demo, whatever it is, we probably could have a whole nother podcast about this, but managing your time in the demo is super critical. Yeah. Cause you, you don't want to just simply do the first 20 percent of your demo and then find yourself running short of time. So, yeah, I agree with that. I think one of the, one of the techniques you could use to help you with that is let's say you have. Customers that are all, because customers usually attend these things too, right? Whether it's trade shows or whatever. Get some of those customers to come to your booth and be open to talk about how the product has solved their problems. Yeah. And their problems are probably also some other people's problems, their prospects, right? Sure, sure. So again, this comes back to get your people to get your audience to sign up beforehand and then ask them the question. What are the top two things you're trying to solve today? And align those customers up with these prospects and say, What you're trying to do is already being done for the most part, let's say, by Fred or Mary. And you should talk, right? And I think that buys you a little time because you don't have to go through the whole thing in detail. For that particular prospect, you probably have a scripted demo. We should probably stick to it. That's very interesting. Look, we used to do that with the logistics customers. We used to connect certain customers to other customers to say, Hey, this customer had the problem you're having and they solved it. You know, usually we would only do that if they solved it with one of our features that they did not buy. So it is a sales business development opportunity in disguise, but also like a networking opportunity. Hey, I'm going to introduce you to another customer. They already solved your problem. They're living in your future. And also they're spending more money with us. But their pain point is relieved. So that was, I mean, that was a. Easy win. Yeah, I agree at the time we a long time. So we actually flew out one of the at the customer side. You have people that know your tool very well and can train other people to use it. We flew out one of those people for an entire trade show to do demos for us. And how we differentiate ourselves with competition is We're not going to do a demo for you, meaning the vendor, right? We're going to have a customer get up and talk about how they're using this tool to solve their problems. And then queue up this person and she would come up and she would wax lyrical about how how the products really work. It worked out for them. And then leave it open for like contacts to say, if anybody has any questions, contact me. I'm going to tell you how it is. Right. Because I'm a customer. I don't work for these guys. Right. I think that's very effective. I think you do have to work with them to make sure that. So what's going to happen is that the version of the product that's in production at their site is an older version. Undoubtedly. Right. By the time a demo comes around at a trade show, you have added lots of features. So you have to train that person saying, well you may not be using these yet, but this is how it works. And now you have double benefit because they're going to go back to their organization and talk about it. He gets what's coming next, right? Yeah. So it's, it's easy, it's easy to do that. All it costs you is a flight and a hotel room. Yeah. You know, with a willing customer. Yeah. The thing about time management in demos for me has been a customer will get on a, a customer will get on a tangent. Let's hope it's a customer because I think the more I'm going to say it from the perspective of a customer will get on a tangent about one specific thing and they'll only want to talk about that for the rest of the demo and you'll have all of the rest of this stuff queued up and you won't be able to talk about it. Cause that's what the customer wants to talk about. However, I've also been on calls where, you know the, the executive stakeholder has been on the call or the. Sales person who sold the feature has been on a call with the customer and they start monopolizing the time talking about a specific feature or really anchoring on one thing. And the customer kind of gets on board with what they're talking about. So like the kind of the hostile parties have taken over the call, but I, I don't know if I have a hot take on this one, but I'm like, I honestly, I never mind that because like, obviously if they're, if they want to waste the whole call. Not talking about any of our new features. And just talk about this one thing that is so painful for them. Obviously we are solving the wrong thing and we need to pivot to what they're talking about to solve that within reason right? Well, if that's or at least talk about it. Yeah, we should definitely not shut it down, right? Because that's of that's of relevance that's of importance to them You know as long as you don't have other people on the call that have vested interests somewhere else if you have a general Demo, for example, right? Where it's not just one customer, it's multiple customers and one customer is monopolizing it. That may not go all that well. I would probably just say there's lots we can talk about there, right? Yeah. I'd be happy to set up time. I didn't write. I didn't write until one on one. So I mean, definitely that, that's a, that's an option. But don't, don't, definitely don't shut down any of these interactions because you're closing the door in their face and you don't want to do that. Yeah. No. See a point about your, your salespeople leading that. Right? That can be trained in that. You can say, Look, this is a general audience, right? So if somebody wants to go down a tangent, I'm probably going to refer to you and say, can we, can we host another call for that customer? We can deep dive into this matter. I mean, it might be just for one specific customer at that point. Well, if that's the case, then it's their call, right? Let's do it. Yeah, exactly. Yeah, let's do it. Especially if you know with confidence that the product does what they're looking for. Yeah, yeah, yeah. Entertain them by all means. A lot of my calls, I've talked on the podcast where when we do stories the stories generally are one, one persona per story. I've talked about that on the podcast before, and usually when we're doing a demo. Unless the features for that one persona are applicable to many, many, many people. I will try to just have that one persona represented on the call. So it'll be a demo to that one persona. It does that sometimes mean the engineering team has to tell somebody, Hey, join in the latter half of the call. We're going to be demoing to this other persona in the first half of the call, joined in the last 15 minutes, or joined in the last 20 minutes, or something like that. Yeah, sometimes I do that especially with internal stakeholders. If it was a customer, external customer, I probably would just set up another call. You know, just set up a separate 30 minute real quick type of thing. Because most of my stuff is separate. small I'm not, I'm not going three months at a time and then dropping my, my hottest new mixtape or whatever on the internet. Like that's not the way I work. I want, I want small, so I can get small feedback and then do the next small iteration of that small feedback because I, I, I had this feeling and I brought it up here on the podcast before that customers, companies, everyone has metrics, things that are important, things that they measure, whatever. And then all that stuff falls by the wayside when you just. When people have confidence that you know, they, they don't feel when they have confidence that you will keep delivering software to them on a regular basis into the future. When they don't feel like like I can't let Brian go because if he goes, I may never hear from him again. He may never give me a feature ever again. Like that, that, that fear of abandonment. That fear of abandonment. Do you have development fears of abandonment? That could be a whole podcast, too. I think it is like I think you're right. If you were in that situation where customers are looking at you as a almost like a big key then, then, yeah, you definitely want to make sure you address that before the demo. Otherwise your demo is going to be just. Targeted to that particular aspect only, right? But one of the, one of the tips I can share with people that are looking to improve doing demos is, by all means, record it and watch your recording, right? And show it to people that aren't in the demo at the time because they won't have Context continuity and ask them, how can I improve? What do you see here? That doesn't make sense. What's disjointed about this demo for you? If you're in the demo, you understand what's being said prior and you kind of get the context. So you don't get, you get feedback. It's all valuable, but it's not as valuable as feedback from somebody who doesn't have the content. So we're kind of in a, how to make your, how to make your demos go smoothly. Category at this point, we already covered two, which is asking for feedback. Hey you're a salesperson, you're an executive, you're whatever. Can you watch my recording? Can you watch my demo? Can you watch whatever? Or attend, right? And give me feedback on, on my techniques. And you know, that I can improve. So you're asking for feedback for improvement. The other one implied in that you're recording is that you are, I like rehearsing 'cause you can re, you can record a rehearsal and send that for feedback without ever going live. Sure. Absolutely. No, exactly. That was my intent. Especially if you're brand new. If you're a brand new product manager, you or a brand new person who's being asked to demo, for example. Like the example I started with this podcast is like a junior employee is being asked to demo in front of a large audience. It would be good to prepare that demo, just write down the bullet points, the highlights that you want to hit. You don't have to write a script or anything like that. I'm sure you can write, but you don't have to do any of that. Write a script what you want to do, what you want to, the highlights that you want to talk about, what you're going to do in the application while you're talking about it. Run through it, record it, fire it off to somebody, ask them for feedback and you know, rinse and repeat. Maybe ask a couple of people, ask your boss, ask somebody you respect, ask somebody in sales. I mean, you could ask a couple of people. It's a recording people can watch on their own time. If they don't give you feedback, Hey, you, you've lost nothing. Exactly. I agree. And don't forget to ask your peers as well. The rehearsal part of that we haven't talked about yet is that, Oh, you're rehearsing your demonstration at this point. We don't talk about that with sprint demos either. It's like, Hey. I have a team, like I'm the product manager for the team. I expect the developers are going to be demonstrating functionality. How do they improve at this? We don't ever, I can't recall ever on a development team talking about, Hey, we're going to rehearse this sprint demo. Yeah. I, I, yeah, I've come across that in a, a scaled environment where they rehearse midway through. Well, that's, that's a little bit different. And I, I try, I always try to steer my teams away from the concept of like, well, now we We have to spin up a whole demo environment and we got to maintain it. And we got to copy all the data to this thing. And it's, it's a hold. I'm like, no, no, no, no, no, no. I know I want to, I want to demo the live feature. The way we the way we deployed it in production as is, and if it falls over, it falls over, I want to see the real live feature in production. I don't want to see a mocked up demo. Yeah. I'm a big fan of that. This reminds me of these You know, there's cooking shows that you see where, where the chef says, this is how, and they actually put the dish together and then they put that aside and go, here's one I baked earlier. And that looks golden beautiful, right? It's like, yeah, but how does it really work? You know, so I'm a big fan of that, really. You don't have to go through the extra overheads of setting up environments or anything like that. As long as you can be. Open and say this is this environment. This is how it's working by all means. Don't you can use synthetic data. That's okay, right? But if you use production data where customers can kind of recognize the data, right? That's even better. If you have one customer that you're demoing to, you could do a lot worse than just get a copy of their data. Yeah. Because they recognize their data. Sure. Yeah. Now you get instant buy-in when they see that. Mm-Hmm. as opposed to just just mock data. Right. Yeah. So there's a lot you can do as, as far as gaining credibility is concerned without really spending a whole lot of effort on it. Yeah. I, I was at I, I mean I, at most of the places I've been, they have had they, they have at least. Two systems, most, most places have three, most places have a, a a development playground type of environment, and then a middle ground, either stage or QA or something that looks close to production looks, feels close to production, and then they have their production environment. You know, some places have four, very, very few that I've seen, but most places have either two or three. Yeah. And in this, this goes along to having a backup plan if, if it doesn't work in production, you can always open a new tab, flip over to your stage environment that you know is good. Cause maybe that's where you test it, or maybe that's where you've done your internal shakedown or whatever. Yep. You've got another place ready to go. Right away, as opposed to standing there with egg on your face. I agree. I absolutely agree. And this is all the more critical when you have integrations with other things, other teams, other products, sub products, whatever you have, you have integrations. Maybe your stuff is solid. It works right time and again. It just works. Except when you integrate, We on some environment like stage, let's say, and you have this other team's product and maybe that's where the issue is. Right. But you're doing the demo. Right. So in that case, yeah, it behooves you to have a backup plan where to your point, I just swap over to another tab and say in this environment it works. Yeah. And. But be open. We're not lying to anybody here. Just say, well, the integration seems to be having a problem right now. But, we have it working in this other environment. Yeah, a great example of that. I was just talking about flipping between a production and a staging environment, I remember we all the mobile apps have back end APIs, like integrated with back end APIs. And I remember that we had, We had back end APIs that the responses were hard coded in stage, for example, you would always get the response. The response will always come through correctly because we're not, because the stage environment doesn't reach out to the real production response. But it would always come back with the proper inputs for the program to use. Stub data. So if you had a problem in production and it wasn't returning the proper results, sometimes bad data got through, right? Sometimes it's just bad data. You could quickly flip over. Your mobile application to the stage environment. Nobody would be the wiser. Rerun , your trial, whatever the demo is. And now you're getting perfect data back every time. Yeah. But as long as you're open, right. And just say that this is a stage environment and only this part of the contract is what we're trying to show you. The rest of it is mocked up. Yeah. We'll get to that next sprint or next, whenever we meet again, that's okay. I think people are okay with that. The other thing that we, we haven't said out loud, Yep. But I want to say it out loud before we get out of the room talking about this is that there's no point in having demos if you're not going to use the feedback that you get from customers, if the feedback is, this is all great perfect five star review on, on next door, your great neighbors five out of five would, would, would move next to again. I guess you can get that as feedback. I was like, this is very rare, but you can still get more, right. You can say, well, how can it be improved? Right. Yeah. Well, what, what did you look, what do you, what do you wish for? That's not there. Yeah, because you know, so it's always, you can always solicit feedback, right? Even if somebody says it was excellent, but yeah, it's a valid point. You may get the feedback that is their part of the deal. That's their part of the contract for showing up right at this venue, where virtual venue, where I'm showing you the demo. Your part is you will give me feedback and please be open, right? Give me to a brutal feedback. Every feedback is welcome. If they give you a brutal feedback, guess what? Now you've got somewhere to go. You can improve, but if they give you no feedback, you have no idea how it landed. Well, I mean, this is part, like we talked about knowing your audience right I mean, if you're showing a non technical audience, something tactical, maybe they can't give you great feedback, but if you're showing the audience something that they're interested in, something that That deals with their pain points. If you align your demo up with your audience number one, you're, you're setting yourself up to get feedback, right? Cause they already want to tell you about what they're saying. But the, the other, the other side of this is I think about some developers that I've had on my team that some of them are like real, real, real what's, what's, what's a good way to say I think about like a in a retrospective You have some people that are like ohm. It seems like you have something to say, but you haven't said anything yet Is there anything you have to you know? But what do you think about this topic that kind of that kind of drawing people out? Like if you have team members that have that ability There's no reason to not involve everybody on your team. I think about different personalities Please And they're different abilities to interact and then to, to, to sense things. You mean different levels of EQ to sense things? I guess, I guess what I'm saying is you could cover for each other if you're involving the whole, whole team. Now, if you're just going with a sales guy and you're the product manager and you're just going off and demoing stuff and your team doesn't even know that you're talking to customers like you kind of lose an opportunity that you could have involved them not only developing their skills, not only getting them broader experience. But they could have helped you. Maybe you don't even realize it could help you. And this is the number one way I think about they could have helped you is, is your did you, developers are hearing the back and forth and if they're you know, if they're confident enough, maybe it's their first time or whatever, right. If they're confident enough, they can hook into the conversation and start asking additional things. Yeah, I agree. So I want to say a couple of things here, right? One is. You said earlier, if you're demonstrating a technical product to a non technical audience, right? Again, this is all part of knowing your audience. If you're doing that, don't use technical jargon. Use their language, right? So that you can communicate with them at their level. So you have to talk their language so that you can communicate. And the same thing applies. I agree, first of all, that developers should be engaged in this conversation, right? Or at least listen initially. But when they do speak, they've got to be coached the same way. They don't use technical terminology with non technical audiences. Sales people can help you with that. Yeah, for sure. Agreed. Absolutely. That's, I mean, that's, that's why the main point you have to ask for feedback on your, your presentation, your presentation style, that kind of stuff. All right. So in like, I want to, I wanted to reserve, I didn't say it at the beginning of the podcast, I probably should have, but I wanted to reserve at least a couple of minutes to talk about experiences with issues during demos. Issues is a good way to put it. Call. I was, I was going to call this, demo disasters. That's what I was going to. Reserve a few minutes for us to have fun with demo disasters. I already told you about, I already told you about one where I felt, I felt a lot of pain in that moment. You know, the, the, I mean, the, the funny thing is that there's a lot of stuff in this, in this podcast that I would like to talk about, but I'm trying to keep it super on track. I've been in some demos. Where some executives come down and start it's like going on a diatribe about who needs it, who asked for this, who needs this this is not what we need or customers that are upset or agitated, like just the people that are out of line basically, but I, I, I don't want that to be any part of this podcast because I feel like if someone's out of line, like you just hit the, hit the red hangout button and you're done. If you're remote and executives intrude in this way, just tell them to hit Alt F4. Nah, if they're in person, hit their red hang up button. Yeah, yeah, yeah. I like that one even better. So I think this is an important little little segment of the podcast. Anything that can will go wrong. And anything that can't will probably still go wrong. So you just have to be prepared for it, right? You know, you know the worst, you know the worst feeling about a demo going wrong? I think again, in the mobile world, mobile development is when, because a mobile app, you can do some stuff on the local mobile app, like there is some local processing because mobile apps have databases on the phones and stuff like that. But in order for them to do anything real, substantial they have to hit the API that they go to. They have to hit the, the, the, the web server that they go to the backend and if your wifi sucks, what a terrible thing to torpedo your whole demo, we can't get wifi and it's not in your control. It often happens, especially if you're outside somewhere, like at a venue where you're doing the demos. You never know, right? Yeah. And you might think that if all the sales goods that, that you get from venues con conference centers or whatever else, they'll say high speed wifi available. And sure enough, you go in there, you test everything's blazing fast, except in the demo it just happenstance, right? There's multiple vendors doing demos. Everyone's consuming that bandwidth. So many people are, yeah, it happens, right? Yeah. So you just have to, you just have to know that it's gonna happen. First of all, don't start sweating under your collar. Right? It's gonna happen. It's not a maybe sooner or later. If you're in the game long enough, it's gonna happen. Yeah. So be prepared, right? Be prepared with a couple of things that you can put out there to kind of help you, right? Just make sure they're not boomerangs that they come back and smack you in the head. Right? But definitely, Yeah. Allow for all of these things. I've had things like brownouts occur during demos. Never could have planned for that, but a storm went through real fast, and a brownout, and the server blipped. Of course we didn't have any any protection on the server. So the server's now rebooting, and it takes time. Yeah. Right? So during that time, You have a choice, right? You say, well, the servers now rebooting and just kind of everybody's just looking at each other. This is no good. Five minute break. Half the time people don't even trust you. Would you say that? Yeah, luckily, in that example, the lights blipped so everyone could kind of relate to it. But yeah, have have a few things. Play this out in your mind with your friends, with your colleagues, your peers and say, How can we have strategies like that? Where if something does go wrong, you can make light of it. I mean, humor. Make light of it. I've had an anecdote that I shared with you this earlier this afternoon where I was behind in this almost like a server area doing things back there, swapping things out back in the days of not enough memory available. And the demonstrator when we practiced, I said, just continue doing what you're doing. And I will keep doing what I'm doing right and I made the comment ignore the man behind the curtain Well, she took that to mean that that is like a keyword or a keyword code word So during the demo she kept saying ignore the man behind the curtain She said a few times before I registered what she's trying to say. It's like no, it's not time yet I couldn't see her. I couldn't see at what stage of the demo. She was at I was trying to just listen And kind of keep up with it. So things will go wrong. That's a given, right? And you just have to make the best of it. Another anecdote I can share is a demonstrator, very, very smart demonstrator but their problem was when something went wrong, they would go bright red in the face, get flustered and start pounding the keyboard. And this, this guy, he started hitting the keyboard. We literally saw a couple of keys from the old XT style keyboard. Fly off the key. It's his frustration coming through, right? But that didn't help, right? So you just have to kind of know that when things go wrong. Don't do that. Yeah You know use other people around you to help you to let your sales people are good for that. Yeah well, you know the other thing about when things are going wrong is like when you get stressed and things are going wrong you Like your mindset goes to a place where you're not taking in the feedback anymore. I think about a demonstration that I was in one time where the customer was they were asking the presenter a bunch of questions. This is when I was a developer. This is a long time ago when I was a development team member and the customer was asking a lot of questions about the flow through the application. You know, Hey, why, why, why am I coming to this screen? What happens if I had this thing? And they're just hammering the presenter with questions about what if, you know what I mean? And the, the problem with what ifs is you very quickly come to the end of the presenters theoretical understanding of the system. And customers have a way of getting quickly exhausting all of the knowledge to get to a point where we're like, we have to look through the code and find out what happens when you get that deep or whatever. But basically the customer is when they're doing that, they're, they're expressing frustration with your UI UX, with your user experience, your, your user journey, basically if we could have stopped and just graphically demonstrated on a whiteboard or whatever storyboard, yeah, like a storyboard like you're going through a journey, a user journey map, basically you're going through these screens and then you get to this point and then it splits off and you make this decision tree and you go this way. Like if we could have demonstrated that visually that would have been something we could take immediately back to the backlog if X then Y and then Zed, I did it again, then You know, you go all the way back to a, and it could have been immediately turned into a story for feedback, but because of the way that it was just hammered at the presenter who was already overwhelmed cause maybe something was happening and that's why the customer hooked onto it. Then maybe we didn't get that feedback. We forgot that the main point of the demo is not necessarily to get to the finish line. It's to talk about how we can enhance the product, get that into the backlog and then see you in the next two weeks or whatever. That's a really important point. This, this actually, I've lived through this scenario where everything was going swimmingly well during the demo and it was a demo of a, an advertising system. So you basically have a, an editor and you're typing text in there. And often you don't want to sit there and actually type text. So you have some text that you save in your buffer, right? Then you just. Paste it in there, right? And I did. I did that. But I was going through the different types of advertisements and I picked one in the employment section and at random because you have the newspaper front is publishing app. And I put in there, you know therapist wanted was the headline. And then it's some description of the skill sets needed, etcetera. So it was a short paragraph, and I had that saved in the buffer. Yeah. And as I'm demonstrating this, I paste that in there, so I hear some text, I'm gonna just paste it in, so you don't have to watch me type. I do that, and it hyphenates and justifies the column of the advertisement, right? So one column, textual ad. And I hear people guffawing in the audience what's going on? So I look at my screen. And everyone's laughing, right? And it had hyphenated the word therapist after T H E. Right? So, of course they were laughing. Okay, so I laugh with them and I say, well, luckily the system has a feature where you can change the hyphenation point. So instead of having it after E, usually a bad idea to have it after vowels anyway. I'll change it. And I did that live, wasn't part of my script. So I'm like, here, I'm going to bring up the the dictionary and moved it from after the E to after the R. And then I hit the hyphenation button again and it fixed it. Right? Wow. So it's demonstrating a feature in flight of your demo when you come across that. Yes. And like, what else could I have done? That's, that's funny. Like you just brought up a random memory for me because in a system that I worked on that generated random GUIDs. Like you know how, like you get up, you'll subscribe to something and it'll give you like a confirmation code or whatever, like the confirmation code. We had to remove vowels from the alphanumeric characters. Yeah. Oh yeah. You know where I'm going, you know where I'm going because it was generating some naughty words and like, not, not, not like not like the, the, the good four letter words, I mean the bad four letter words, but in, in the quote, a random confirmation code, we had to remove a vowels and that's how we solved that problem. I didn't even think we removed all the vowels. I think we just removed you. I know. But yeah, we had to do that one. Now I don't remember if that was on, I don't think it was on a demo. I think that was it, but it very well could have been. It very well could have been. Yeah. But yeah, that was, that's a good one. It never happened in any of the practice sessions. I can guarantee you that. Yeah, well, yeah, yeah, yeah. Well, you hit the lottery on that one in front of a crowd. Yeah, right. Congratulations. They just picked all the random ones in practice, like automotive ads or whatever, but that's what you do. You get extra credit from. You get extra credit from the crowd for handling it for playing it cool and handling it and showing, Hey, we're going to move past it. Same thing with like, Oh, the, the, the query is taking the, the, I'm going to send to the LLM and the LLM normally takes five seconds in all my prep for the demos, but now it's taken 10 ish seconds or whatever, 20 seconds. I'll be telling you it takes between 10 and 20. Yeah like play it cool. If it comes back in 25, it's still not that bad because you can say, look, the environment we're in, connectivity is not ideal. So it took a little longer. Right. And just keep rolling with it. Yeah. If we're going somewhere on this podcast, this is where we're going is your presentation skill is the difference between. A good and a bad demo, which is tough for people to hear. It's tough because that's, that's product management is probably closest to it. The development team members, scrum master probably can help a lot with it, but every team doesn't have a dedicated scrum master. Managers maybe are doing it or whatever. So everyone's kind of sort of. Doing a little bit, but they're doing it so that they can get done with it and move on. No, one's really advancing that skillset. So that's, I mean, that would be the takeaway is look for opportunities to advance those presentation skills. Cause I, again like at the end of the sprint, there will be people with good presentation skills, people with bad presentation skills. Every, every time that you present, it's an opportunity to improve those skills. Exactly. I agree with that. Absolutely. And practice does make perfect. You come across all these scenarios. So be the first one to put your hand up when, when somebody says, who's going to demo this, this sprint. You know, just embrace it, right? It's not you. You're just the hands on the keyboard person. The team is really showing the work, right? So feel free so know your audience ask for help speak the language They speak a lot of the points we hit on this podcast and have a backup plan and have a backup plan Yeah, all right Well, my backup plan is to like and subscribe the agile podcast the old arguing agile All right, and let us know what other topics you'd like us to talk about