People don’t buy features, they buy solutions, trust, and relationships. -Rob Gonzalez
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.
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.
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."
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.
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.
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.
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...
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.
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?
As a reference, The guys at Close.io use the first option ( http://blog.close.io/)
patio11 (who is kicking around here) uses the second option (http://www.kalzumeus.com/)
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?
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 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.
> We invest in people not products.
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 definitely have. I've even switched to a service with fewer features because the previous solution had absolutely awful support.
If you're a provider who the customer cannot get rid of, you can fuck around with relationships, solutions and other mumbo jumbo.
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.
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'
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
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.
Are you manually applying the italics? Apparently
That is indeed better...