When is it OK to make exaggerated promises?
You can tell when a software sales guy is lying – his lips move.
That’s not fair – at least it’s not fair sometimes.
I recall a conversation many years ago with a technical delivery person who was being briefed before a sales meeting.
“If they ask if the software can do it, just say yes”
“But that’s not true. It’s a lie. Are you asking me to lie?” he replied.
“Yes” I said. I confess, I was the sales guy.
The thing is it’s never a lie to say software can do something because the answer is always yes. It’s just a function of time and money. Now if the customer had asked a more astute question like “Can the software do it today?” then it may not be true to say it can. But to say that it can, while omitting the important caveat “just not yet”, is not in its strictest sense a lie.
Making false(ish) statements about a product isn’t simply a question of honesty. Making exaggerated claims can be no more than earnest optimism about what the product engineers can pull out of the hat and a key skill of the sales person is knowing where to draw the line between eager aspiration and dishonesty.
Some technical people get really frustrated when a sales person promises something on their behalf. Not only do they seems to promise something that can’t be delivered, they put a delivery date on it that can’t be achieved and all without reference to the art of the possible.
But who is right and wrong when this happens? Is the sales guy wrong to sell something that isn’t even on the drawing board? Or is the technical person naïve and lacking in commercial acumen?
In May 1961 just weeks after Yuri Gagarin became the first man in space, was John F Kennedy wrong to promise that by the end of the decade the USA would “Land a man on the moon, and return him safely to the Earth”?
At the time, nobody knew whether this was even possible. The technology didn’t exist and even the bare bone of the methods they’d use were undecided. But sure enough, the ambition that JFK presented to the world was fulfilled just as he’d set out. Of course, it cost a fortune. By the middle of the 1960s, the Apollo program was consuming more than 4% of the US federal budget.
Let’s be straight about this – if the scientists and engineers had led the space program, they wouldn’t have set such an unrealistic target and they’d have never secured the budget – not because they’re not ambitious or because they are complacent – it’s because they know what they are talking about.
I do not advocate allowing any kind of crazy idea to drive the development including the development path of enterprise software but when the techies get frustrated at the sales guys I grin to myself and question: Who is naïve here? Is it the sales guy for overstretching aspirations or is it the delivery person being over cautious and defensive?
I’m also reminded of something else that Kennedy said in that 1961 speech. “We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone.”
For me at least, this is truly inspirational stuff and I would – not always – defend the sales message that promises to push the boundaries beyond what is already established and yes, to make promise knowing not whether they can be fulfilled.
And if you are one of those put-upon software delivery guys who is regularly asked to deliver on the promise made by someone who doesn’t really understand the detail, you might disagree. You may think that a comparison with the Apollo missions is a bit over the top – after all, you’re not being asked to send a man to the moon. To which I’d say: “Exactly!”