Hacker News Reader

Hacker News

Comment by tlogan | Hacker News Reader

Full thread

tlogan

Excellent article. And I want just to add more real world problems when dealing with large customers:

- they want to have multiple 'demos' with 5 or more attendees which end up being hours long

- you need to work hard to find out whether people you are talking to have any purchasing authority

- they want to have PoC deployed

- they want to have a kind of reviews and special contacts: security, special contracts, special NDAs, etc.

- they never pay invoices

- they are always want to tweak how the product works

In short, enterprise sales are more about relationship and negotiation - so you need to have team dedicated for doing only that (sales, sales engineers, etc.). It is not hard - but just you need to have team and process for doing that. For example, many established companies will have "paid PoC": You want to test our solution? Great. You have to pay first to test it.

View on HN

Hit right on the nail with every point. I'll add one more: feature requests that are fishing expeditions on the customer's part, but are interpreted as show-stopping issues by sales/management.

And one more: byzantine network architectures and change management procedures that take six weeks and seventeen different signoffs to get a VM provisioned or an account created.

"feature requests that are fishing expeditions on the customer's part". This is a red flag. If your product market fit is strong, and you understand your value proposition, your prospects requests should fall somewhere on the roadmap. If they are too far out in left field, you may have other problems. The more your product solves a real problem, the more willing enterprises are to do things your way (take a patch every week, forgo some network architecture standards, etc). When selling, look for the signs that they are willing to play ball as an indication of commitment.

Those feature requests might be, say, integrations with other software they run (often one-off internal software) that they'd otherwise end up doing themselves. They want to see if "just asking nicely" will be enough to get that work done, rather than having to plan a whole project around it (even though it obviously would translate to you having to plan a whole project around it.)

Always, always push back.

When I'm on a call and the customer/prospect* asks for something we don't have, I push to make it concrete. Here are some of my questions:

- How are you doing that now?

- Where is that in your roadmap? Is that required for the current phase?

- When do you plan to implement/use it? Is this 3, 6, 12, or 24 months out?

- Is this more or less important than X? Where X is another project or initiative, because there always is one.

- Is that a nice to have or a must have?

* Until they give you money, they're a prospect, not a customer.

When a big customer makes a feature request, call it a change request and tell them you'll make them an offer (they pay money up front) for it. Sure, if they never adopt the product the effort could be better spent elsewhere, but at least you'll get paid for their bullshit.

If it's expensive for you to do then you should always demand real money up front.

As someone who has 10 years of experience in EnSW, this is very f'n good advice. To all of the techies out there dealing with enterprise sales - close the sale, close the sale, close the sale. Worry about product later (and all of those are acceptable answers).

If you want to watch that as a form of entertainment, I can recommend the "Billion Dollar Buyer" show (you can find it on yt).

i would just add that the proof of concept can cost upwards of six figures.

in other words, real companies that make real things charge their customers real money.

if there's no money, guess what, they're not a customer! move on. the business sociopath who you're interacting with at the other side of the table is more than happy to have you work for free for as long as you're willing.

Reply on news.ycombinator.com