Hacker News Reader

Comment by beachy | Hacker News Reader

Someone told me way back in time that in the ERP sales process, your two top answers are:

Q: Can your system do X?

A: Yes (doesn't matter what the question is, or that an entire add-on would have to be built that could never be cost justified).

Q: As a company we do things like this, will your system work?

A: Yes, our product works with your process, no matter what it is.

I have observed this to be true. Customers particularly love the second one, so telling someone that they must change their process to work with your super simple un-customizable product can often be a deal-breaker.

View on HN

I worked in a startup in the B2B space a while back, and it's amazing how much big customers can push you around and demand features. The salesguys would promise something and then a week later we'd have the feature in a special patch build for them. I heard Cisco did the same thing, and by the time they got big they had hundreds of special branches for different groups of customers. It was a mess.

Then I worked for a couple of big B2B companies (currently work for one) and it's basically the same thing except that two weeks becomes 6 months. But given how small the market is, you are still doing customization to drive deals. I think a big part of the appeal of developing these frameworks is so your own support staff can add the feature in without changing the core code. I'd imagine this would be the case for all the big B2B players. No way do any of these companies survive just selling off the shelf, and I have some admiration for the support guys that parachute into Penn State or the Foo Department of Bar or Nestle and help manage a whole massive deployment or roll out some brand new feature. They are working nights and weekends and I'm sure there's a lot of good war stories there.

Yes, it takes special fortitude to fight off the demands of your precious new mega-customer, be they a Cisco or whoever. Sometimes they'll really screw your product up if you let them. (Though sometimes also they'll give you those jewels of requirements that you really needed).

It's a sliding scale. You have to pander to them to some degree - there's no choice. But it takes grit to refuse to e.g. branch your core code or otherwise compromise your architectural integrity.

The problems are when the sales team does not appreciate the downstream costs of just letting this one patch in. And when you're a struggling startup, sometimes they're right and the social proof of the deal (and the revenue) make it a good choice to compromise your principles this once.

And sometimes you just screw your product up by not listening to what customers need, or by assuming that you know it better than them. For now i refused to do custom branches, instead the product is made more and more configurable. And it's more successful approach so far than trying to maintain a separate version for every customer.

Reply on news.ycombinator.com