Software As Sushi
Software As Sushi
Why I Hate Jargon As A Sales Tool
I love software. I love sushi. I hate sales.
I’ve long believed that selling something that truly solves someone’s problem doesn’t require anything other than referencing the problem and, in the simplest terms and with simple examples, showcasing your solution.
People will pay you to solve their problems, and the easier it is to solve a more complexity-laden problem, the more you stand to gain. Therein lie the sales skills and strategy I value: helping people understand how to solve their problem with the solution you’re providing.
The scarce practical application of the above strategy I’ve seen is stunning, and its scarcity is why sales engineering to me has proven to be a farcical role up to this point in my career.
I can’t count the number of times I’ve stared at a sales-sketched architecture diagram or read through an attached-with-an-RFI API preface that was laced with convoluted marchitecture, technical-sounding features or systems that existed nowhere in the actual code, or overly-wordy descriptions of what was in reality quite an elegant and simplistic solution to a complex technical problem.
Look, I get that selling to the enterprise instead of the consumer can be hard. You can’t just do a invite-only beta, get a few tweens to mass broadcast inappropriate selfies, and call it a day.
Enterprise executive buyers often like to dispense with platitudes on the one hand whilst dressing up key technology decisions in language that is the equivalent to puffing of one’s chest on the other.
As I’ve been personally told, enterprise architecture is far more complicated than “The Twitter” or “The PlayStation” in the eyes of the wallet-weilding executive “architects” (though the scalability and security beget by such platforms perhaps makes such a position ill informed).
But when you dress up the technology you’re selling with conjured ten dollar words and lace your documentation with jargon that no one, including you, understands, you only do yourself, your company, and your product a disservice.
You put your executive staff in a position where they must perpetuate lies they can’t hope to understand. You enable — nay, encourage — sales staff to sell off-roadmap futures. You put your professional services staff in a corner where they eventually or accidentally admit to your customer what you actually have. You put your product team in the rotten position of having to retrofit your fibs into features and to give things dumb names that confuse the coders and customers alike. And you put your engineering team’s work to shame, masking the elegant solutions worthy of getting exciting about with window dressing it is in neither need nor want for.
One of the greatest sushi chefs alive has a singular philosophy that is an apt analogy for my belief: simple, all-natural ingredients prepared in simple yet skillful ways are the ideal. When you allow the natural flavours to come through without the reductions, without the aiolis, without the decadent and outlandish artificial presentation elements, you’re left with delicious food that demonstrates your masterfulness effortlessly and begs high demand and a higher price.
Why should software, even business-to-business or developer-to-developer technical software, be any different? Software is sushi, and it’s a dish best served, with all irony intended, au natural.
Reprinted from frankcaron.com