Hacker News Reader

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.

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

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.

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.

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?

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

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.

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

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.

I'm not sure how trust or relationships let you make a solid economic business case...

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.

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.

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

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.

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.

please:

   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.

test

> asdf

Are you manually applying the italics? Apparently

> asdf

That is indeed better...

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