Hacker News Reader

Comment by AntonZ234 | Hacker News Reader

"assuming that what your sales people say the customer wants is actually what they want or need. This one is tricky. I've had sales people go "unless you build X, I can't close the deal" and then you build X and it doesn't make a difference. Reason: the sales person's analysis was wrong."

this is SUPER common, and very hard for organization to counter. As salespeople usually interact the most with users, PMs tend to just do what they say.

View on HN

I saw a head of sales literally kill a business by endlessly doing this, when in reality he was deflecting from his own lack of ability. There was always a clearly articulated reason why it was someone else's issue that he wasn't closing deals, and by the time that issue was fixed as a company emergency he had come up with two or three new ones.

This is a very common story. Unfortunately the incentives and general historical inertia around sales as a role don't always gel with the long term picture.

It's a very human story, but it's one I've had to try to put preventative structures around for my whole career.

The default, "your job is just to sell and your reward structures reflect that" creates an environment where the easiest path is to over-promise. Hence when that sales role sits too high in the org structure you naturally end up in the endless sell what you don't have -> scramble, sell -> scramble cycle.

It seems very obvious that the best salesman would sell the lowest number of features for the highest price, but the incentives are typically based on the top line figure instead which is nice for cash flow but not for profitability.

So far I've managed to solve it somewhat by building internal barriers, but they take constant maintenance.

I'm sure the better solution is to lean the incentives towards profitability but the implications are complex.

A land and expand strategy could maybe help mitigate it, what do you think? Keep the focus on small deals constantly closing, and then follow up to upsell them. Separate spiffs for each part of the sales motion.

On the SaaS side, yeah I think that's a good move.

In this case there's a large hardware component of the sale which incentivises the software over-promising. There's also a lot of competition (think a tender process).

It's really about shifting the small decisions, removing that marginal "yes, we can do that" which didn't need to be there at all for the sale to close.

You could have engineering estimate the cost of the new feature to deduct from the profit?

It's particularly common with big whale enterprise clients, where the salesperson is trying to close a very long sales process or the client has you by the short hairs in the contract. I remember one case where we had to implement a very complex and time-consuming custom SAML integration to a platform where we just had one client asking for it, because that client was too big to ignore. Once we integrated SAML, the number of end users actually using the SAML login option was in the single digits. It was just a checklist item for some purchasing officer flunky.

For SAML in particular I can definitely relate here. I will say though, that for SaaS products that you want large companies to use, you owe it to yourself to have an auth layer that is immensely flexible and pluggable. Auth is a huge mess and large companies nearly all have single-sign-on solutions, sometimes strange bespoke ones, and so you gotta expect to potentially build a zillion different auth integrations if you want to sell to large companies.

Sure, but if you are planning to go from SME to enterprise you need to think strategically for the long term. You'll probably need to have more developers to deal with the complexities and hand-holding you've touched on (auth is just one of the issues and not even the most complex) and probably non-technical roles for all the compliance and so on.

The danger of landing just one or two "whales" is that you bend your product backwards for these clients, but without thinking through the TCO it can cost you more in the long run and put your business in more jeopardy than when you rely on a few hundred SMEs.

This is exactly why we built WorkOS. Check it out if you’re looking for SAML/SCIM for your app. (I’m the founder.)

https://workos.com/single-sign-on

The fact that no one used it doesn't mean that building it was a mistake. Maybe the purchase officer got it wrong, but the salesperson who requested it be built got it right, since the deal did in fact depends on it.

Perhaps. But then it's important to look at the total cost of ownership: was it worth building a complex feature for one client that adds to the technical debt of a code base and tied up developer resources that could have been better employed elsewhere? Could we have pushed back on this feature or was it really a deal-breaker?

In other words, perhaps landing this one client was important to that salesperson, and perhaps in the short term to the company, but in the long term it may have been better to have lost that one deal. Very often these decisions are made with little calculus about the TCO.

> Reason: the sales person's analysis was wrong.

On the other hand, great sales people have a knack for understanding what customers really want, as well as non-technical obstacles to selling like procurement policies or management hierarchy. You ignore them at your peril.

Reply on news.ycombinator.com