I have a slightly unusual background in that I spent much of my time on the end-user side of the fence before setting up as a software vendor. The gulf between the vendor and the enterprise buying community can be seen by the term which software vendors use for their customers: “users”. There is only one other industry that I am aware of that names its customers in the same way, and that is the narcotics industry.
The fact that few people working in software companies have worked for “user” companies, and vice versa, can lead to some serious misunderstandings and a confrontational “them and us” mentality, resulting in missed opportunities all round. Vendors and customers circle round each other suspiciously as if speed dating, where both stand to gain if only they think about the long term. After all, if you buy a piece of enterprise software you’re usually looking at a five- or 10-year commitment. If you were going to enter a serious relationship with someone you’d take the time to try to understand what motivates them, yet this repeatedly fails to happen between vendors and customers.
"Small software vendors are usually cash-strapped and eager to please customers. But this eagerness can go awry"
There are many examples of dysfunctional behaviour. Small software companies are usually cash-strapped and eager to please customers. Smaller vendors will generally bend over backwards to try to solve customers’ needs since their business is proportionately more important to them. However, this eagerness can go awry.
Enterprise customers often have esoteric requirements that are specific to their unique processes or organisation, and are keen to push vendors into making modifications to the standard product as extensions, but then expect the vendor to support these for free. The vendor’s sales person is usually too anxious to push back, so a standardised product ends up with more and more “specials” which the vendor’s limited R&D team has to worry about supporting.
As more customers do this, you no longer have a standard product that can easily be upgraded, but rather a series of semi-custom builds, each pulling the original clean product design in different directions. Customers then get frustrated when the vendor seems slow to produce upgrades, despite a major reason for this being all those little customised specials that the customers themselves negotiated.
Pricing is a contentious issue, and again, both parties need to understand each other’s point of view. Often, a software company starts out with a simple pricing policy such as “flat fee of $300,000”, or “$1,000 per user”. Then a customer complains that they don’t really want to use the whole product so shouldn’t have to pay for what they are not using. The vendor responds with a “lite version” with some contract restriction. The next customer wants something different, and a “professional edition” comes out with new options and contract terms. The dance continues until the vendor has a price sheet the size of a phone directory, which its own sales staff can’t understand and which the poor R&D team has to keep track of when producing new versions of the software, testing for all the exotic configurations dreamed up by an over-flexible commercial team. In these situations, everyone loses.
Small software vendors want your money, for sure, but they also want active references in order to sell to more customers. Despite this obvious dynamic, I have seen again and again companies purchasing software, getting real benefit from it and then refusing to do a case study for the vendor, citing the “policy” of the corporate PR department. This is mostly a smokescreen; PR departments are in the business of generating positive publicity for their company, so if a project has gone well and brought real benefits to the company, how bad does that look?
However, it is true that writing up a case study is a hassle with no obvious gain to the immediate customer. Much easier to say “it is against our policy”, which neatly deflects the blame. Vendors need to understand this and find ways of getting a win-win rather than just saying “please do a case study”. If a project has gone well then there are plenty of trade magazine awards out there for “best project in the industry”. If a project is nominated for one of these and wins, then the individual project manager will get some benefit – kudos among peers, and the awards dinner can be seen as a cheap “thank you” for the hard-working project team. What corporate PR department is going to object to “our company wins award” headlines?
Good relationships require give and take. Enterprise customers need to better understand what motivates vendors, and vendors need to grasp the complexities of corporate politics if both are to get the best out of their relationship.
About the author
Andy Hayler is founder of research company The Information Difference. Previously, he founded data management company Kalido after commercialising an in-house project at Shell