You want what? Of course! Easy peasy. Now sign here.
A response to Gary Turner’s wondermissive on vendor staff understanding what they’re selling.
Last weekend, Gary Turner, now retired CEO Xero U.K./EMEA dropped an important story about getting everyone inside a vendor firm intimately aware of what they’re developing/selling. This was written in the context of product-market fit.
It’s a must read for buyers as it provides a useful insight into how sales and development works - or more often doesn’t work - in the interests of customers.
In his story, Gary talks at length about the different types of sales person and their relative understanding of both the products they’re pitching, their understanding of customer need and how that manifests between sales and development. Critically, he says:
A good salesperson with good levels of product fluency and, ideally, domain knowledge will rarely oversell, and they’ll also do a decent job of managing customer expectations. They’re also better equipped to overcome or argue customer objections and may be able to conceive process workarounds for genuine product gaps while convincing potential customers to compromise a little along the way. And they’ll know when a customer feature request is valid and when it’s bogus, so they won’t jam up your development schedule or soak up the product manager’s time on spurious product asks.
There’s a big set of problems here. I can’t count the number of times when buyers have told me about their frustration at getting what they want/need from software vendors. Most recently for example I spoke with a professional colleague who is tearing his hair out trying to get a definitive answer to what should be a simple question while at the same time being pressured into signing a fresh deal. He needs a feature set that is obvious to him (and me) and will solve problems of data accuracy, remove manual cross checking and save time. He keeps getting vague promises that leave him lacking confidence in making a decision. This doesn’t surprise me and is illustrated in Gary’s story:
…they (sales) may oversell the capability and value of your early-stage product to unsuspecting customers. Things can quickly turn sour when these customers realise they’ve been sold a pup, reject the product, and form a negative opinion of your business, and your word-of-mouth reputation can also take a hit. Worse still, contracts get cancelled, and revenue unwinds, making the revenue growth hill climb even steeper. It’s also shitty for morale.
You bet! But here’s the deal. Sales people are usually what I call coin operated. They want to make money and the way they do that is through target driven incentives. Hit your target and you get to pay your bills. Exceed your target and you get to take a nice vacation.
Perhaps I’ve been unfortunate in my dealings with sales but there is truth in what one CMO told me many years ago: 70% of sales people are D grade students. These people are characterised as lazy and over promising. By lazy I mean they don’t put in the legwork to understand the customer and will promise the sun, moon and a couple of stars to get a customer over the sales finishing line. It rarely ends well as Gary acknowledges.
One problem for vendors comes in recognising when a feature request is more than one buyer’s pet wish. The case I was looking at certainly isn’t but my colleague can’t get any assurance about delivery timescales. I see this as a problem of communication. It’s borderline deal breaking for the vendor.
Vendors have a lot of data on what customers are using but precious little on what customers need. They will tell buyers that they’re listening but I find that to be listening with half an ear.
Buyers on the other hand have difficulty explaining need. This is because the technical nature of what they do is often couched in the lingua franca understood in their industry and not the language a vendor can parse. This is where Gary’s exhortation around domain knowledge really matters. At the same time, buyers struggle to understand the dynamics surrounding development where there are many needs but constrained resources. Compliance related issues for example will always trump add-on features. Couple that with shifting timescales and life gets tough for developers very quickly.
A good example is the U.K. government dithering on Making Tax Digital. Slated for introduction in 2024, MTD has been pushed back several years. What was a development must-do for 2023 to give tax practitioners time to educate clients has now come off the front burner if not off the rails because who knows how policy will shift next, especially given we may well see a change of government in 2024. Developers must be livid. Practitioners would be forgiven for also being pissed as it upends planning.
Equally, vendors are notorious for setting unrealistic development timescales and even then getting it wrong. Again I see this as a comms issue only this time internally at the vendor. Check out the well known cartoon at the top of this story which I believe originated in 1989 or thereabouts. I see it regularly cropping up among developer war story presentations. While it raises a wry smile, it is a painful reminder that pristine communications are at the heart of successful software delivery.
What surprises me is the lack of stories where the various invested parties collaborate extensively around development topics. It does happen, but not to the extent I believe is needed. If it was otherwise then the frequency with which I’ve seen customer frustration would fall dramatically. The flip side is that good levels of collaboration lead to outsize benefits for everyone in the value chain.
What lessons can we draw? Gary’s insights are helpful to buyers. Understanding the key dynamics provides buyers with context around how they gauge responses from the frontline sales people. It also opens the door for buyers to request meetings with developers and marketers to explain the why of feature requests.
Buyers need to better educate themselves about software development. I am firmly of the belief that means a clear role for internal technical expertise well beyond the knowledge gained by those with a peripheral interest in tech.
I am fortunate that many years ago I was invited to a hacker night with a group of rock star developers. My initial resistance (I’m a suit not a geek) was broken when I was promised free beer and pizza. Yes - I’m a cheap date!
What happened opened my eyes to the potential for buyers to sit alongside developers in a meaningful way. It led to my attending many hacker events, learning much along the way. Crucially, I found that developers are not scared to answer questions and will often provide cogent answers as to why something can or cannot be made to work and how long it might take.
For buyers, it leads to, for example, having a clear understanding of what’s possible within specific time constraints. It means understanding a lot more than IF>THEN>ELSE in code or, more prosaically, being a super jock at conditional programming in Excel and thinking you’re done.
The idea is not to set up arcane technical discussions but about knowing enough to have an appreciation of where compromise is needed and where buyers can be insistent while at the same time respecting constraints. In my mind it’s a discipline that requires regular exercise and commitment. Sadly, it’s something to which a business user is rarely exposed in enough detail to make a quantifiable difference. In my view, being armed with this type of knowledge allows the informed buyer a better chance of keeping users onside during the development process.
Vendors should welcome this style of approach because it provides the kind of buyer confidence that keeps them paying for years to come.
Does that make sense?
I totally get this.........but often the chasm between customer/vendor isn't all one-sided. I could counter that sales people can get led on a merry dance with all of this simply because the customer doesn't know what they want, or delegates managing the requirement to a 3rd party who is less invested in the solution, or they want a unicorn and you only have a zebra you can sell....the list goes on.......I speak from experience :)