I've sat through probably thousands of demos in my IT career and I must say this quote featured in the article is bullshit:
People don’t buy features, they buy solutions, trust, and relationships. -Rob Gonzalez
I can't count the number of times we (various IT teams) have selected products because they were the only one that had a feature we needed. I'm at the point in my IT career where if I'm watching a demo I politely let them do their little spiel for 5-10 minutes and then I'm like, "yeah yeah show us feature X" (because I want to see that it works and how it works).
What always destroys a demo for me:
* Sales people that don't know the technical details.
"I'll have to get back to you on that." (for nearly every question)
* Irrelevant use cases. "Schools use our product!"
* Can't actually provide a *live demo*. Only slides or,
"Let's watch this 10 minute video after which I probably
won't be able to answer any of your technical questions!"
* Complete failure to mention anything in regards to security
or if they do it's nebulous bullshit like, "we your data
in transit!". This one is becoming greatest concern lately.
Everything I've read about this sort of thing says that the #1 thing you can do to improve sales of any software product is to add new features. At least, that works once your product has been established. Selling it initially? No matter how you slice it that's hard.
It goes both ways. Some companies only care about a specific feature and will overlook almost everything else. Some companies care about the relationship and are willing to sacrifice features. I know a company I was working for year ago was switching from IBM Notes email to a cloud provider. Microsoft and Google were the last two in the running. We ended up going with Google even though Microsoft had more robust DLP and auditing features because the Microsoft sales guys seemed to assume they already had the sale and would respond to emails without reading them or sometimes not respond at all, whereas Google actually sent someone out to our Midwest headquarters to walk us through it face-to-face. The decision makers didn't want to be just another sale, they wanted a company that cared about our success, and Microsoft lost the sale based on that alone.
And take established players like IBM: why do people pay more for IBM when their competitors are faster, have more features, and have flashier sales pitches? Because IBM is comfortable, reliable, and you know what you're getting. Better the devil you know than the startup that's going to get bought out and shut down a year from now, right?
But yeah, I've also seen a lot of companies turn down a great product because it was missing a feature they needed. It's always a cost/benefit analysis, is that sale going to offset the cost of developing and supporting that feature? If it's a feature built for one customer and no one else is asking for it, it's probably okay to lose that sale. But if someone else asks for it and you implement it later, go back to that first company and pitch again.
That is the point. You needed those features which means that it was solving your problem of needing that functionality/feature. When people say "sell solutions and not features", it just means that whatever you sell, has to solve a problem for the client otherwise it is just a "Feature". A feature that solves a problem becomes a "solution".
If the feature was something you didn't need, you would not buy them even though the feature may be nice and shiny. So it still has to solve your problem.
I haven't sat through as many as you, but I've found that telling them upfront I'll want a sales engineer and deep dive works best.
From the book Pitch Anything, sounds both of us are "analyst frames".
"A particularly dangerous one is the analyst frame that fixes on granular details. The best way to knock off this frame is to give a direct yet high-level answer that describes overall goals or systematic features and then go back to your pitch."
I can spot when reps try that one on me. In my field I know the devil is in the details, so I need to always push back for a detailed technical answer. I give context, but it is annoying how many reps act like I'm inconveniencing them by actually doing my due diligence and knowing what I need in a solution.
If a potential customer only talks about "feature" and it does not talk about their problem then I consider the customer a "troll". Move on.
The problem with "feature you need" is that many many times IT have no clue that problem X can be solved with feature A, feature B, etc. And whether they envision that "feature' should look like will never be exact the same what my team implemented.
In short, from founders perspective, if I cannot understand that we are solving problem X then I cannot sell our product. But there are some shark which can do - but for small startups that is not good.
That's fair, but I think "solutions" contains the features your company needs to be successful. That's how I interpreted the quote - customers don't want to see a massive feature list, they want to see how you solve their business problems (which will be through features).
This is an interesting perspective coming from someone who has sat on both sides of the table.
The bulk of customers over the course of my career have had non-technical people making purchasing decisions. Sales engineers (techies who work on the sales side) are always brought into appease the buyer side technical people who are generally brought in to vet a purchase far too deep in the sales cycle.
The answer to the "necessary feature" question is always yes. "Do you work with X SSO technology?" "Yes." "Show that to us." At which point the sales rep decides whether it's worth the labor cost to build/demo (assuming they haven't already done so). The elegance or performance of a given feature are never considered, except in product x vs. product y scenarios where x and y are evenly matched and even then the technical side is an afterthought to cost, market strength, gartner's opinion, relationships, etc.
I guess what I'm saying is that my experience is that from a sales perspective and an executive perspective, technical details matter little in most cases. That's a big reason why companies with great technology fail while others with terrible technology see great success. Too many brilliant engineers have trouble understanding the importance of great marketing in opposition to great solutions. You can fail with a product that saves companies millions of dollars when none of that spend is a pain point. You can succeed with a product that makes companies spend millions of dollars fruitlessly if you are addressing one of their key initiatives.
Your experience could be a complete and utter failure of sales reps to recognize an opportunity, or it could be that they just don't appreciate that you are a decision maker.
I think the quote comes from a particular perspective: non-technical managers buy "solutions." These are the only "people" that matter, because they're the only "people" usually allowed to spend "real money." (Engineering teams might get a corporate credit card, but these are for the <$5000 purchases that corporations don't bother caring about.)
Most decision makers targeted by software providers be it CIOs or business heads are interested in outcomes and project success and not the technical details.
These are taken for granted and will be fleshed out in the POCs or demos to the various technical teams by the vendor's technical marketing and solution teams. The business heads or CIO evaluate the solution proposed and are usually risk averse. An expensive purchase or botched project will look extremely bad for them which makes relationships important, in that the vendors delivers what is promised even if it takes more resources on their end. And these relationships can last long, leading to buying preferences, even if the technical solution is not completely there.
Sales always under intense monthly to quarterly pressure will always over promise and solution and services teams will always resist that, as it usually mean more free work for their BUs but this is long running conflict in most enterprise software companies.
This is the most interesting comment. I work professionally in sales and am getting ready to launch what could be classified as SaaS/PaaS product.
As to the need of a specific feature, that's an interesting position. I know people whom show you the work around, and ones that offer to build the feature after they have a signed contract. If you were given the two options and like the person/company which would you prefer?
I completely understand your frustration about sales people not being able to answer any question, but if they actually get back to you with a real answer does this not make the wait worth it?
The other three are completely valid and they should be ashamed of themselves...
I'm fairly perplexed by your reply. It seems so backwards from the way I experience demos. I never find myself with money laying around, looking for a way to spend it, and time laying around, entertaining demos for the hell of it, when I could be working.
If I'm spending my time watching your demo, it's because we have a problem we need solved, and believe you can solve it. You won't even get in the door without knowing what our problem is, so hopefully you'd be able to speak to solving it -- though of course, having to get back to me on precise technical details is fine.
But I can't fathom purchasing something (signed contract) on the promise that you'll add my feature later, maybe.
I suppose it would be backwards from what you typically experience.
Let me try again: You're looking for a piece of software, you need it, and are ready to buy. Let's call it a CRM and the feature you're looking for the ability to add a new contact from the main screen. (It could be anything and any feature, but just as an example)
During the demo, you love the software, the people instill confidence, and you can see yourself using this everyday. If it takes three extra button clicks to add a new contact (giving you a workaround) would this make you happy?
Or you're really happy with everything, and the choice is to sign the contract and we would have the button before install date (written in the contract.) Would that be a better option?
I'm interested in how you as the person listening to the demo, would take those two options (giving only one option would be presented during the demo) Does this make more sense?
A better example of needing a feature: When I was freelancing, I needed an invoicing software that can generate an invoice in my client's language. I don't care if the backend is English-only, but everything client-facing needed to be translated. Believe it or not, Harvest still doesn't offer it, which made me ditch them.
Interesting, did you find a service that offered it in a language that you needed?
If it was a new service, this should have ruled you out (for Harvest's case) before you became a qualified lead.
I was trying to ask about something that you could use with a workaround (like a few more steps create a translation) or offer to write what was needed to translate for an additional commitment from you. Would you have taken one of those options, or was the client facing information needing to auto-translate a deal breaker for you?
Let me clarify: I had clients who only spoke French, and other who only spoke English. I'm in a French-speaking area, so it would have been really bad to send my French-speaking clients invoices in English. On the other hand, it also doesn't make sense to send French invoices to US-based clients.
I actually used Harvest for a while, and I basically changed all invoice labels to make them bilingual.
I ended up switching to Pancake, it actually supports setting a per-client locale, and the client-facing parts are translated correctly. It's still not perfect, though, but at least it's there.
I think perhaps the issue is that I'm not typically evaluating things that do not already exist in the company. My employer is established and most things generally work.
I can think of a few pain points I have around storage vendors, functionality of their interfaces, some virtualization niggles, etc. In that case I already have a functioning product and I'm looking to extend functionality and solve a specific issue I have, so if the new product doesn't have it, I stick with what I have.
I'm trying to put myself in the place of someone who doesn't have a category X product at all and am evaluating a number of vendors who all compete in category X, and I'm coming up blank. So likely it's a peculiarity of my scenario -- or, at least, not the kind of customer situation you're dealing with.
Additionally, a lot of SAAS pitches are done to enterprises and those pitches happen to sales/marketing folks and not devs/tech leads (who come later in the process).
I think what you're describing is the difference between a technical buyer/recommender and an economic buyer. You're obviously a technical buyer, so for you, features that solve your specific pain are important and you probably acted as gatekeeper to the whole process. But at some point in large purchases, there has to be an economic justification - and that is where the solutions/trust/relationships become more important.
You make a good point about the specific needs of IT departments, who do care a great deal about features and their particular pet peeves (security, robustness, etc.). Definitely important if you're doing enterprise/complex sales. I don't think Joanna is selling that kind of a product.
Wanting to see how "a feature that we needed" works is better phrased as a "solution". It solves a problem you have. The quote your referenced is simply saying that a large feature set is not the most important thing; whether it solves your problem or not is the key.
Freaking this. If you're in sales and you don't know your product inside and out, then you need to either sell something else (which you do understand) or you need to work on improving communication with engineering management, so that the proper details work their way into your sales kit. Time is too valuable to waste these days and wasting your customer's time is a cardinal sin of sales.
I agree but it also depends to who you are selling. I've been surprised how many times I made an in depth demo accompanying a sales rep only to find that the prospect superficially cared about it and was in fact buying that everything would be great if he did go with us, our sales rep was selling trust and relationship
He really does cover this with an appropriate quote.
Don’t waste time showing [prospects] the step-by-step process of doing something. Create a vision of what benefit they can get by using your product. Then demonstrate how they achieve that benefit. Only if they ask for more should you get into the “step-by-step” process of how to set things up.
Only if they ask for more Well, you are asking for more. That's a good thing! It means you're engaged. You are asking about a needed feature. Should the pitcher instead mind numbingly list through all of the catalog of features, hoping they get to yours before mutual boredom sets in? Hell no.
I thought this article was full of awesome advice for the reluctant salesperson. That would be me.
alias hnquote='pbpaste | fold -s -w 77 | sed "s/^/ /" | pbcopy'
Then your quote will be
Don’t waste time showing [prospects] the step-by-step process of doing
something. Create a vision of what benefit they can get by using your
product. Then demonstrate how they achieve that benefit. Only if they ask
for more should you get into the “step-by-step” process of how to set things
up.
Since we're bikeshedding HN quote styles, please don't. While this is marginally better, it still causes horizontal scrolling on mobile devices.
My preferred style is:
> Don’t waste time showing [prospects] the step-by-step process of doing something. Create a vision of what benefit they can get by using your product. Then demonstrate how they achieve that benefit. Only if they ask for more should you get into the “step-by-step” process of how to set things up.
This has the advantage of letting the browser do the word-wrapping, while still setting off the quote in a different style.
Sharing a bit of my own experience: I used to do a lot of demos for my SaaS (usually 1 to 2 hour long, because it ended up in some form of coaching session on cash-flow forecasting habits), but after a while I realised that I got more churn from such users ultimately.
I later replaced those demos (which I still do occasionally) by 2 things :
How did the trial conversion go? Do you have a lot of in-app prompting and email around conversion?
We tried that at Cronitor in 2015 but we saw less engagement from users who started a trial without a cc and less engaged users, predictably, converted at a lower rate for us.
I have no in-app prompting at all, and I have a simple 5-email benefits-oriented email series (via customer.io).
I don't have enough numbers for things to be meaningful (it's a small-scale SaaS), but I seem to recall that removing the CC without onboarding initially was not great, and things improved with the onboarding tour (sorry if I cannot be much more specific!).
Removing the CC avoided the need to handle refunds for some people, which was a bit of hassle to handle.
Don't forget to allow an extra 30 minutes for all the inevitable tech glitches with Zoom or Adobe or whatever your remote solution is. Get ready to bash your head on the wall when you discover that they are trying to use IE 7 on Windows XP to connect to your presentation, and nobody in the meeting knows how to "load chrome" or even has permission to do it. Finally throw your deck away and do a voice-only call via someone's cell phone sitting on the middle of the conference table.
Some places, particularly government networks, have extremely locked down Internet access - the tool that I've found to work the best for screen sharing is screen leap:
Don't forget the client that calls in with their phone (because it's "easier" and the conference bridge allows phone call ins) and therefor can't see your screen. I always make sure to stress the importance of using a computer to connect because of screen share.
Many SaaS websites seem to try as hard as possible to hide the actual product from you, with no screenshots, no live demo, and sometimes even no free trial, and a "demo" page that only has a form to request a demo. And according to this article, even in that demo, you're not supposed to see much of the application.
Now, I trust that this is sound advice for many (enterprise) customers, but personally I hate it.
It's got to be that they're not multi-tenant. I'm with you--I would only bother building for SaaS if the cost of a minimal new customer is insignificant. Then while your competitors are saying, "Give us your phone number and we'll call you," you can be saying, "Click here and try right now with no credit card."
I think a lot of these companies, though, are more-or-less selling hosted versions of the stuff they've been selling for decades... which is very much not multi-tenant, but it's what they've got.
the conversion from a trial to a sale for enterprise software is super low for two reasons:
- software only really works when you commit to it by importing all your data and your daily workflow within it
- no one wants to put that much effort in a trial
companies are also super paranoid about competitors getting a hold of your product and ripping the good features
It's only super low because people expect to sell to enterprises with relatively low-touch sales methods. If you want to sell to enterprise, with no prior customers, you need to be setting meetings with several stakeholders (engineering, financial, legal, infosec, upper-management if possible...) within that company, demonstrating to each how your software fits their specific burning need, and helping them adapt the evaluation instance to their specific needs until it becomes indispensable. In short, as a founder, you ought to be expecting to practically work out of your customer's offices, at least in the beginning of the sales process.
If the feedback you're getting from an enterprise sales meeting is "we need solution X which isn't part of your product," then either a) you're still doing market research or b) the enterprise is asking for something that doesn't fit your cost/benefit curves.
I worked for what is now a £10 million p/a turnover that didn't do this, so it really does depend on what you're selling.
They sold a document/project management system, extensible like salesforce that was generally used by the whole company.
AFAIK, they targeted CEOs and IT heads, but they targeted SMEs and gave up on larger customers because they believed it simply wasn't worth the effort for those customers, they just got mucked around too much and closing sales took far too long.
This is what I take from it: by revealing your cards there's less room for manipulation. The buyer already has preconceptions that could range from:
- This will not work; I didn't see this in the screenshots
- I don't understand what I saw and now I have irrelevant questions
If the buyer tells you the pain points, and only the pain points, as a seller you can focus on _those_ and cut out the bullshit. It makes manipulating easier as a seller, and as a buyer you're left to trust the seller that everything will work out in the end.
Haven't got the experience to say whether or not this is a good thing.
> Don’t waste time showing [prospects] the step-by-step process of doing something. Create a vision of what benefit they can get by using your product.
This 100 times. This goes for many things too, it's often very easy to feel like you are being productive by painstakingly going over basics and step-by-steps but anyone who is genuinely interested will follow up themselves. Anyone else is going to get bored fast. This is why it's so important to have and show this big vision - you need to hook people to stay interested.
Great post, it's also nice to see something well over 1,000 words! Thanks for taking the time to write all this up!
I learned this lesson as well. Step-by-step is a training session. For a demo start with the end (show the wow") and then dig down if they ask questions.
You also need to account for losing internet connectivity. I had a demo before I knew what I was doing where I went to the customer site and they set us up in some sort of dead zone, essentially could not connect to either guest wifi or mobile hotspot to show the product for most of the time or when it did connect the lag was so bad it seemed like the product was incredibly slow.
Most places will not allow you to connect via a wired connection to their network for good reason.
I then started tripping all over myself because I had not prepared for this situation. I did not land the customer.
If possible, running on local host is the way to go.
...and when running from localhost, watch out for any resources loading from a CDN, and, of course, for your local dummy data being total crap and/or accidentally offensive (and get ready for "Why is all this text in [Latin/French/Italian/something really bizarre]?" when you use lorem ipsum).
I learned long ago that -any- placeholders confuse people. Image placeholders? "Why is it showing me just an image of some random person with the word 'placeholder' over it?! I would have images of Y!" It's frustrating, but that's reality. Figure out the sort of thing users will actually have in there, and try to put something similar. Preface lorem ipsum with "Your text goes here. Fake text follows: Lorem ipsum dolor sit amet..." or similar.
A million times yes. I had a client tell me an example draft deliverable was "the worst document I've ever been handed" when I was showing them a preview of the document format in week two of a three month project. It was supposed to be documenting their entire architecture and solution I was building for them, so it would be delivered at the end of the project. They asked to see it early, so I put in placeholder data. They were not impressed, and it nearly tanked the whole project. They didn't want to pay thousands of dollars for obviously placeholder text. Problem is, none of their real information had been fleshed out yet, so I didn't have real data to put in.
But then on another client, I put in better (more realistic) placeholder text for the same document and they thought I had sent them another client's information and got real scared about their own data privacy with our company. That's when I learned to refuse a client's request to show them a document before it's (at least nearly) finished. If they want to see the format, a static picture of very obvious placeholder data serves just fine.
Good idea! If it's an image, you can watermark "DEMO" or "DRAFT" very visibly over it, and that hopefully will help them realize it's neither real, nor intended to be what is submitted.
I think a large part of the problem comes down to two somewhat related things: people only understand things based on their own experience, and people have very little imagination.
As developers, we spend all day building things that don't have the right or final (or any) content, and we understand that a box filled with lorem ipsum will look fine once the real text (which doesn't exist yet) is in there, or a screen with just a big red rectangle adorned with "PLACEHOLDER 500x300" will look perfect once the final image is inserted. But for consumers of what we build, they have no experience of non-finished products: they don't ever see placeholder images on Facebook, they don't see unwritten copy in the newspaper, and when they open up Microsoft Word, they don't type "The quick brown fox..." into it, they type the actual text they want. We know that the hard work from a development perspective has been done, and it's now someone's job to write the copy and pick the images (which is, of course, no easy job)... but to the end user who has no concept of the code whatsoever, all they see is a page where everything is totally wrong.
Secondly, imagination: if all they can see is a red rectangle, many people will find it very hard to imagine a tastefully chosen hero image there instead. We built a product a while back which, in large part, was intended to be flexible and extremely configurable - that was a really key feature of the software. When I was initially demoing it, I showed it in two configurations: one that was incredibly basic, and one that was a wild mix of various garish colours and fonts. I had anticipated that people would use their imagination to interpolate various tasteful designs between the basic and the garish, but no - all they could see was boring or ugly. Even with a careful explanation - "Of course I've used awful colours, you can easily choose from your corporate palette!" - it just never went down well. (Now when I demo it I show off the configurability by tweaking in real-time two pre-existing designs, very different but both very pretty, and both of which are firmly grounded in real-world use-cases, which avoids nitpicking like, "Well, it looks very nice, but we'd never use it like that, we'd have another foo after the bar...")
To the guy saying to use Bacon Ipsum, just no. That's fine and funny when you're a developer sharing something within a development team, but otherwise for a surprisingly large number of clients it will be confusing and possibly seem extremely unprofessional.
For Python, I've used the Faker package to generate dummy data. It was quite easy to use, and much better than the homegrown approaches I'd taken in previous projects.
The solution -- I ran some demos in a previous life -- is extensive screenshots, plus static html to move between them. Everything should be totally canned. This shouldn't be your demo, but it's the backup for when internet connections go to shit and you don't want to be just screwed. This will also help when god realizes she hates you and your app breaks just before a demo.
This could be a pretty cruel way to vet somebody. Intentionally deny them wifi access and see how they react. Perhaps more competent companies perform better? More likely people just flop.
This may seem old school but I actually have a printed out spiral bound deck customized to the client that I take to pitches. In addition to the digital presentation.
I do it for a few reasons:
1. Because our service is expensive and some more old school clients want to hold something in their hand
2. It sits on their desk pretty much forever, keeping the brand in front at all times
But it has the added benefit that even if the power goes out, I would still be able to pitch.
Really? Every time I hear 'how was your day?' from some random I don't know, it always seems like a silly question, almost a formality. I invariably respond with 'yeah, fine', just to get it over with.
I should maybe add that I struggle with small-talk at the best of times, so I'm probably a sales person's worst nightmare :)
Maybe I should also add that I'm from the UK, and we don't generally go in for 'have a great day' and all that American smiley stuff :)
I have had people fall asleep in the middle of my presentation (after lunch-heart medication). I have had people throw up in the middle of my presentation. I have had people cry in the middle of my presentation.
At that point, I stop politely. I'm not in sales mode anymore; I'm in human being mode. Maybe they need an ear. Maybe they need a beer. Maybe their staff understands that they fall asleep after lunch and that you can continue on.
Sales is mostly empathy and education. I'm selling to you because I believe that I'm going to make your situation better. If I reach a point where I believe that is not true, I'm going to stop selling to you, refer you to someone else, etc.
Occasionally, this loses me a sale. Oh, well. I generally engender so much good will when it happens that it almost always rebounds back to me later.
You don't care at the same level, and if you try to show you do you will rightfully be seen as phony. Normal human-to-human empathy is enough. You don't have to cheer them up, but you know what it's like to have a bad day. So do I, they suck.
As a backup, in case: the site internet is down/you're presenting onsite & their internet is down/ you're not running locally/ whatever - it can be useful to have a "virtual demo" ready to go, ie, a powerpoint deck of screenshots showing your intended demo flow. Not as good as the real thing but better than nothing...
Advice probably applicable to more than demoing SAAS.
Also the author has clearly acquired some sales chops by reading those books on demos - the note at the end about researching and writing the post in 9 hours using airstory had me clicking on the links!
Of course they disclosed they were an airstory founder on their blog.
So, the linked article mentions "know your audience," but I think glosses on emphasizing that a bit.
Engineers, content creators, program directors, are going to be looking for different things and make decisions in different ways. Don't just ensure decision makers show up; make sure you're talking about the pros and cons those decision makers will care about, rather than the ones you think they should care about.
Sitting at the other side of the table (as a regular engineer in BigCorp), that was an interesting read. One thing I recognized from too many demos and product workshops (whether they are on site in our offices or remote) is this section:
> Ask lots and lots of questions. Follow the 80/20 rule: 80% of the demo content should be about your customers, and 20% should be about your solution.
Spending an hour explaining our systems, our business and our pain points to a random sales rep is usually not a good use of my time, especially if I still don't really know or understand your product yet (don't expect me to have even visited your website before the demo if I'm not the person who booked it).
Currently we have more or less simplistic demos, which also do not look shiny. And we have to highlight everytime that these demos are using just a tiny subset of the full API and much more stuff is possible. When we got more customers we were also able to point to some nice looking apps but this is also not always optimal.
I dunno, but when it happened to me, it totally derailed everything. It was one of those moments when you want to argue with the prospect - "As if funded companies don't go out of business?" - but that's probably not a good strategy. :) So I just sat awkwardly and tried to explain that we'd been approached by VCs but hadn't pursued anything.
I hope it doesn't come up that often. I worry, though, that it's actually some sort of signal to the average prospect (who's not in the startup world).
One approach -- besides make sure you have an answer ready to go next time -- is to talk about two things (straight up stolen from patio11, but if there are mistakes in memory, they're mine):
1 - who do you think you matter more to, some company with thousands of customers or me?
2 - I don't give a shit what their SLA says, when you call late at night, you don't get eng. If you call my cell, you get the person who wrote it all. Who is going to get your problem fixed faster?
The real kicker to this line of argument is "When you call BigCo at 3 AM, you will get someone who listens attentively to your problem but cannot do anything to help you. When you call at 3 PM, you will get... an interchangeable replacement for that person. If you prioritize getting the problem fixed versus someone picking up the phone, pick us: we work defined hours but all of your requests will be handled by the person who build the system and can actually help you rather than just opening a ticket and sympathizing that nothing has been done about it."
(Hat tip to Jason Cohen for this line of argument.)
This is a fantastic way to respond to it. But I do fear if it's a slightly emotional response and not a more assuring one. It's probably the best way to address the elephant in the room though, aside from having a kick-ass product that addresses their pain points.
In my limited experience selling things, sales are all about emotion. Yes, there are a few actual deal-breakers, but things like a willingness to learn new things or adjust their workflow or deal with a mildly suboptimal workaround depend entirely on emotion. And the same suboptimality or problem in the hands of a person who wants a deal to work vs someone who doesn't swings in two different directions entirely based on the potential customer's emotions.
I always check, because it sucks to have a vendor go out of business unexpectedly. Good to know what the financial situation is. Bootstrapping is fine as long as they have been in business a while.
It also gives a clue about their expectations for the relationship. Venture-backed companies are not necessarily more stable, because they are often under pressure to grow very fast.
I think perception matters, and if you give off the vibe that your company may not have the resources and wherewithal to support my business in the long run, I'm not going to go with your offering.
This is good advice, beware of seeing this as the whole story though.
Once you play with the big kahunas, your prospects will be tightly controlled and briefed by their procurement teams. Which means most of the question techniques outlined in the post will fall flat as the proc guys have read the same playbook.
This is where the side chats during coffee breaks, etc become the core. Be ready to show your software to anyone, anytime. The literal elevator pitch. Anything to outmaneuver the proc team.
But on the flip side, bigger companies will send out RFPs to have you answer their most important questions before you ever get to the demo stage so the line of questioning will change.
If there's anything doing demos has taught me over the years, it's that clients really hate answering the same questions over and over. If you have any of that information ahead of time, don't ask them again. But also like the article says, don't assume their answer is still the same. Say "what I understand you're looking for is X, has that changed?" It shows you're paying attention and have read the information they sent you.
Depends what you mean by "the procurement team". People with procurement in their actual job title are glorified paper pushers who's job is to make you think that you need to offer a better price but are actually entirely subordinate to the people who've made the decision to recommend to buy your software.
On the other hand, the level of upper management that tends to make the decision is exactly the sort of person this demo advice applies most for: the people who really don't care about the flexibility of your search function or UX (because they're probably not using it themselves) but are quite impressed when you use it to highlight a solution to a problem unique to their company/sector, and don't actually have time to watch a walkthrough of Feature X but do remember the story about how it saved a company facing similar issues $100k
The article covers a bunch of different stuff - some of which I'd expect buyers to try and dodge, some they won't be so concerned with.
For example, when I hear this bit from the article:
Sales rep: “So, currently your company is losing out on
sales opportunities because leads are falling through
the cracks. [...] how much revenue do you think you’re
missing out on just because of ineffective lead
management?”
[...]
Sales rep: “So we’re talking hundreds of thousands of
dollars in lost deals every year.
What I hear is a sales rep asking "What is the highest price you'll ever pay?"
Revealing this strikes me as an unconventional approach to price negotiation.
I would imagine senior executives at major companies would know such things - be it from their procurement teams, their education, or elsewhere.
Though it can be much easier if you're asking the more sensitive questions as a plausible part of a demo rather than grilling them at the beginning.
e.g.
"So this is how you track your lost deals from each month, and we allow you to use different ways of handling bulk leads and smaller volumes of high value leads. So what sort of number do you think might be falling through the cracks in a typical month?"
[...]
"that definitely sounds like something you'd want the ability to monitor individually. Particularly as earlier you mentioned your typical deal size was at least $10k, so that's over $50k each month that our better lead management system could help you with accurately tracking and following up"
A lot of the time the procurement team can tell the buyer to fuck off, or they'll suggest another software they already have a license for to try first
What always destroys a demo for me:
Everything I've read about this sort of thing says that the #1 thing you can do to improve sales of any software product is to add new features. At least, that works once your product has been established. Selling it initially? No matter how you slice it that's hard.