Everything I Wish I’d Known Before I Started Demoing SaaS

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'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).

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.

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.

"...feature we needed...".

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.

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...

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.

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.

Have you ever ditched a service that had shitty support?

I definitely have. I've even switched to a service with fewer features because the previous solution had absolutely awful support.

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.

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

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.)

It depends on who you are. If you're a random SaaS provider, you're selling your software and the conversation is about lining up checkboxes.

If you're a provider who the customer cannot get rid of, you can fuck around with relationships, solutions and other mumbo jumbo.

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."

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.

There is a parallel to that in VC business...

> 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).

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 have different problem (on sales side).

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.

So perhaps instead of asking for specific features, you need to describe the specific problem that you need solved ;-)

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.

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.

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:

http://www.screenleap.com/

No silly viewers for people to install to watch your demo.

Selling is easier if you don't reveal your cards early in the game. Buying is much harder.

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

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.

This is sales 101. "Sell the sizzle, not the steak."

...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).

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.

Good salespeople actually do care!

So if you have a meeting scheduled for a demo, why wouldn't you check out the website? Are you actively trying to not have a good meeting?

I almost always go through materials before a meeting because it makes me better informed and we end up having a much better conversation.

Twilio has a reputation for giving a killer API demo. Check out https://news.ycombinator.com/item?id=11985368 and the links in comments within.

Is that really a thing?

I would never think to check how a SaaS company was funded when looking at their products.

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