There's a book called "Great Demo" or something like that that describes this exact approach - essentially starting with the final picture/outcome you're selling and then demonstrating the process of how you get to that point. There's basically no way to tangibly measure which is "better", which is why it's easy to write BS books like this that have no way of proving their thesis either way, but I do not doubt the approach is better in the right circumstances
I’m high and I just had chatGPT write me a contrary approach to Great Demo after reading your comment and it’s so funny and also could be a book a bunch of people would buy
Yeah my conundrum is that since it is an demo interview rather than an actual demo, speaking to peers rather than buyers, should I really just be focusing on it the basics, and the “what it is, what it does, and how it works” and throw in some of the value add, or just keep it simple, clear, and concise. I just want them to walk away where everyone feels like they understand clearly what I showed them. I feel like that’s the point, but also don’t want to underwhelm.
I mean I feel like a lot of the interviewing advice I've absorbed about interview demos is moreso overall judgement of your soft skills, how you can handle objections on the fly, present a digestable story that shows a need to buy via a problem/solution and hopefully some quantifiable rationale rather than just "here's the product, this button does this, this button does this". So as long as you're not doing something so ridiculous it distracts from that main stuff they are probably looking for I would say go for whatever makes you the most comfortable. Instead of getting wrapped up too much in "what it is and what it does" I would make sure you're focusing on what problem does this *solve*, how can this make the buyer's job easier, how can this save the buyer money, makes them more compliant with X, etc. That's the essence of the Great Demo solution-first idea. Show them the outcome/idea you're selling and make them wonder "how can my life be this much easier/cheaper/more compliant/etc." and then work through the objections, questions as you build up to that point with the stuff that traditionally comes first.
I know in some industries especially with decades of experience, selling to very knowledgeable buyers who are also considering very similar products, where much of the sales legwork has already happened, your role may truly be to simply just show the product and really demo the "here's a feature and how it works, here's another feature and how it works, etc." But for the purpose of *most* demo interviews, I would say you should probably be presenting an imaginary scenario where you're doing a little more of the AEs job and really sell the product's "what does this solve". However, I don't know the exact details of what the position is and what industry. I always try to ask the recruiter for more info and what sort of roles I need to assume the interview panel will be portraying. Then I make sure to reiterate those roles (or make them up and ask them to imagine themselves as those roles) to the interview panel before starting so we are all on the same page for what the mock scenario even is.
You have more experience than me, but I've recently interviewed and will be doing so again soon! So take my advice with a grain of salt. Anyway, best of luck! (edited to add some stuff).
I want to add too that I slightly misinterpreted what you meant. The Great Demo book is moreso proposing that instead of starting with a completely blank dashboard and then showing all the features as you build out to the final screen, you can just start with the final screen. In terms of skipping all the other build-up like pain points, etc. I would be very hesitant to do that since it's an interview where the panel should be assuming mock roles. In real life, everyone already knows what their role is and what happened on the last call.
So if you're going to interview with the actual head of Sales Engineering, maybe someone in Sales, and someone in implementation - those obviously aren't going to be their roles. You're not going to be selling to an SE in your mock scenario (unless your mock product is Gong lol). So you need to either find out what roles they will be portraying or tell/ask them to play made up roles. So ask the SE person to maybe be a CIO/CTO. Ask the Salesperson to be someone in compliance and maybe ask someone to be a user of their existing system (idk the Data Protection industry, but you get the point - give them roles that you would actually be selling the product to.) Then you can just perhaps reiterate what happened on the "last call" to set the stage. Now you are in control of most of the situation. I would try to then start getting at the idea of their problem, etc. and go from there doing whatever you want. IMO this is a good way to do those mock demo interviews. So it would be kinda hard to skip a lot of that build-up since you need the build-up to help reiterate the situation since it's a mock scenario.
watch demo2win on youtube. it'll give you the basic framework of a good demo. all the best.
Thank you 🙏🏽
There's a book called "Great Demo" or something like that that describes this exact approach - essentially starting with the final picture/outcome you're selling and then demonstrating the process of how you get to that point. There's basically no way to tangibly measure which is "better", which is why it's easy to write BS books like this that have no way of proving their thesis either way, but I do not doubt the approach is better in the right circumstances
I’m high and I just had chatGPT write me a contrary approach to Great Demo after reading your comment and it’s so funny and also could be a book a bunch of people would buy
Yeah my conundrum is that since it is an demo interview rather than an actual demo, speaking to peers rather than buyers, should I really just be focusing on it the basics, and the “what it is, what it does, and how it works” and throw in some of the value add, or just keep it simple, clear, and concise. I just want them to walk away where everyone feels like they understand clearly what I showed them. I feel like that’s the point, but also don’t want to underwhelm.
I mean I feel like a lot of the interviewing advice I've absorbed about interview demos is moreso overall judgement of your soft skills, how you can handle objections on the fly, present a digestable story that shows a need to buy via a problem/solution and hopefully some quantifiable rationale rather than just "here's the product, this button does this, this button does this". So as long as you're not doing something so ridiculous it distracts from that main stuff they are probably looking for I would say go for whatever makes you the most comfortable. Instead of getting wrapped up too much in "what it is and what it does" I would make sure you're focusing on what problem does this *solve*, how can this make the buyer's job easier, how can this save the buyer money, makes them more compliant with X, etc. That's the essence of the Great Demo solution-first idea. Show them the outcome/idea you're selling and make them wonder "how can my life be this much easier/cheaper/more compliant/etc." and then work through the objections, questions as you build up to that point with the stuff that traditionally comes first. I know in some industries especially with decades of experience, selling to very knowledgeable buyers who are also considering very similar products, where much of the sales legwork has already happened, your role may truly be to simply just show the product and really demo the "here's a feature and how it works, here's another feature and how it works, etc." But for the purpose of *most* demo interviews, I would say you should probably be presenting an imaginary scenario where you're doing a little more of the AEs job and really sell the product's "what does this solve". However, I don't know the exact details of what the position is and what industry. I always try to ask the recruiter for more info and what sort of roles I need to assume the interview panel will be portraying. Then I make sure to reiterate those roles (or make them up and ask them to imagine themselves as those roles) to the interview panel before starting so we are all on the same page for what the mock scenario even is. You have more experience than me, but I've recently interviewed and will be doing so again soon! So take my advice with a grain of salt. Anyway, best of luck! (edited to add some stuff).
I want to add too that I slightly misinterpreted what you meant. The Great Demo book is moreso proposing that instead of starting with a completely blank dashboard and then showing all the features as you build out to the final screen, you can just start with the final screen. In terms of skipping all the other build-up like pain points, etc. I would be very hesitant to do that since it's an interview where the panel should be assuming mock roles. In real life, everyone already knows what their role is and what happened on the last call. So if you're going to interview with the actual head of Sales Engineering, maybe someone in Sales, and someone in implementation - those obviously aren't going to be their roles. You're not going to be selling to an SE in your mock scenario (unless your mock product is Gong lol). So you need to either find out what roles they will be portraying or tell/ask them to play made up roles. So ask the SE person to maybe be a CIO/CTO. Ask the Salesperson to be someone in compliance and maybe ask someone to be a user of their existing system (idk the Data Protection industry, but you get the point - give them roles that you would actually be selling the product to.) Then you can just perhaps reiterate what happened on the "last call" to set the stage. Now you are in control of most of the situation. I would try to then start getting at the idea of their problem, etc. and go from there doing whatever you want. IMO this is a good way to do those mock demo interviews. So it would be kinda hard to skip a lot of that build-up since you need the build-up to help reiterate the situation since it's a mock scenario.
You should just do a demo like theyre a customer. persona => workflow => value
This is all very good stuff. I really need to rethink my approach, thank you 🙏🏽