It’s easy to be cynical when writing about sales guys.
The stretching of the truth, the over promising, and the race after sales targets make them the butt of many jokes and jibes.
But jokes aside, sales is one of the key drivers of every commercial organisation.
Sales generates revenue. Revenue generates motivation. Motivation generates success.
Over dinner with a bunch of software programmers, the question was asked :
Why would anyone in their right mind want to work in sales?
Ok… so it might be a profitable profession, but it’s also a lonely one. Your biggest enemy is yourself.
Haven’t reached your quota? Who do you blame? The product? The company? The industry? Yourself? …. How do you keep yourself positive?
Closed a deal? Well done! Enjoy the high for the next 5 minutes and then get stuck into bringing the next deal. Sales guys need to be forever the optimistic.
Their motto: Give me 10 minutes with the stakeholder and I’ll close the deal!
With us techies it’s easier. We’re always pessimistic.
Will it be built in time. Unlikely…
Can you deliver it on budget? Probably not..
Should you blame yourself? Absolutely not…. My code is great – It’s the bloody business team that keep changing their mind every 5 minutes.
Our motto: Give me 10 minutes with the person that wrote the functional spec, let me dangle them upside-down from the windowsill and you’ll see how the project suddenly gets completed on time, on budget, with all the required functionality!
BPM Software
It might sound a little pretentious, but I don’t see great differences between the BPM software solutions currently offered on the market.
That’s not to say that some are not ‘slicker’ than others, some more business-user oriented, some more techie, some Microsoft platform oriented, some Java, some open-source – but after checking the technical elements, features and functionality of the software solutions, you get a feeling that it’s one and the same.
The Competitive Edge
So, if the technical elements are the same, where is the competitive edge?
I firmly believe that the two elements that will define BPM vendor success in the coming years will be: BPM skills and Sales Operations
BPM skills is about having the experience and knowledge to deliver the right solution that will solve the business pain (…but I’ll leave the topic of BPM skills to a later post).
Sales Operations
The other element is Sales Operations
Once upon a time, sales guys used to ride off into the sunset, slay the dragon, and come back with a purchase order.
Nowadays – it’s not that simple. Marketing generate the lead, Presales do the demo, Technical build the pilot, Sales close the sale…
The responsibility still lies with the sales guy, but the sale itself is no longer a one man show – it’s a team effort.
The Tug of War
There is a fun tug of war between the teams.
Development teams build technical masterpieces. They build features. They are sure they know what customers need. (They don’t).
Let them run loose and you’ll be left with unsellable gadgets.
The sales team know what the customer wants.
but let then loose and you’ll be left with an unusable collection of bells and whistles.
The professional services team knows what the customer actually needs.
Let them loose… well, I don’t have a one-liner for them… but you get the point.
The trick is in bringing them all together. Creating a slick operation. Communication. Getting the sales guys to understand what’s technically possible within the product. Getting the techies to understand what sells.
Bottom Line
Techies, development teams and IT teams can no longer enjoy the sheltered environment of “Let the sales teams sell and let us develop…”
As BPM becomes more mature, the technical complexity has grown: Connectivity with WCF services, SharePoint security and webparts, SAP, BI drilldown, server performance…
It’s not enough any more to explain to the sales guys about web services, and give them a list of prepared answers.
More and more techies are pulled into the sales cycles to answer technical questions, to show integration, to explain the technical possibilities and limitations.
Arriving at a customer meeting with a tie isn’t enough.
You need to be aware of what you say… and what not to say.
Like it or not – techies are an integral part of the sales cycle.
The art of sales comes from experience (although it helps if you have a natural talent for persuasion).
Selling is a skill acquired with training, trying, and failing. You are not born a salesman, you make one of yourself, with patience and perseverance and the ability to learn from your mistakes and those of others.
Its a skill techies need to learn.
Programming might be the tools of our trade, but sales skills will enable us to build software solutions that will actually sell.
That said, we can still enjoy poking fun at the sales guys….
What do you call 50 sales guys at the bottom of a shark infested lake?
— a bloody good start!
Adam Deane 
HI Adam, I totally agree that sales drives the SW world. But sales tatics do not produce a good solution for the buyer. 50% of business expense in a software company are usually ‘cost of sales’. So buyers spend already 50% of their money on nothing. At ISIS Papyrus cost of sales is 15% and that is the reason that we are stilll smaller than others after 23 years and it is the reason that we are immensely innovative as so much of our money goes into R&D. It also is the reason that we are very profitable and thus financially stable – for our customers!
The sales targets of revenue and market share are not customer focused targets and that is wrong with it in principle. Analysts are mostly focused on that too. But that’s how the world is currently driven and it won’t change soon. But that doesn’t mean that everyone has to fall in line …
By: Max J. Pucher on 19/01/2011
at 9:39 am
Adam,
would have to agree with Max and add that to my disappointment, vendors have failed to keep up with the development of their potential customers, who have over the past years started to move from purely technical issues to asking about the implications. ‘Is our workforce able to handle BPM?’ ‘What does BPM do to our organisation?’…
Ideally, I would expect a BPM vendor to have some (hmm, any) process management philosophy that is not based on ‘fully integrated’, ‘highly automated’ and ’roundtrip’. And could someone please explain why BPMN is still one of the highest ranked and most often used sales arguments for solutions that are intended to improve the management of business processes?
Like I said some months back in a keynote to european BPM researchers, I have yet to hear from customers statements like “We went bankrupt because we didn’t have BPMN” 🙂
At the moment, BPM sales arguments are quite revealing about the state of BPM.
Thomas
By: Thomas J. Olbrich on 19/01/2011
at 10:00 am
Another great post, I love your site!
about sales high: the high can last longer than 5 minutes if it involves buying a fast car. A sales commission can be a year’s salary for the rest of us — but those commissions take years to bring in. High stakes gamble.
Thomas’ comments about BPMN are right on target. In fact following of something called a standard, any standard, is representative of the problem with the marketplace.
Good news: I reading this book “Hyper Social Organization” which predicts that increased personal communications technology may eliminate some of the need for stove-piped organizational structure. Sales people know what customers want, while developers might know how make things work, but if the customer can talk directly with the developers (heaven forbid!) and actually collaborate on the design of the product, customer directly with development, the discreet roles within the organization may diminish. If you think about it, these roles are needed because of the limits on ability to communicate to the masses. Look for a review some time soon.
-Keith
http://social-biz.org/
By: Keith on 19/01/2011
at 2:24 pm
hi adam, good observations in general. i want to add a few points:
– enterprise s/w sales has become quite complex. there is a large body of knowledge and experience under such labels as solution selling & consultative selling, along with elaborate sales processes that CRMs automate & manage, that do help and matter. but at the end of the day selling & buying has a heavy human and subjective aspect that is beyond rationale & technology. i honestly believe that there are those who are just naturally good at selling, and buyers buy from those whom they “like”.
– in terms of organizational structure you have over-simplified it a bit by talking about techie/dev and sales, and omitting product management & product marketing which i believe are critical especially for vendor organizations. one objective of product management and product marketing is to fill in the gap between engineering and sales by understanding the target market needs, and defining requirements, positioning, messaging, and enablng the sales with the right tools to sell.
– i agree with you on diminishing technical differentiation across various BPMSs. they are increasinlgy starting to have very similar capabilities. this holds true of other enterprise software such as ECM. certainly the effectiveness of sales ops (which again includes product managment & marketing) does matter. another way to differentiate is by building and offering horizontal and vertical solutions (beyond just brochures, powerpoint slides, and flash demos) that address specific industry needs, as well as redefining onself and refocusing (sort of a blue ocean strategy). case management that a number of vendors (e.g. EMC) are focusing on, as well as RPM (Progress/Savvion), CEM (Adobe), ALM (Serena), etc. are examples of this.
i have a couple of relevants posts on my points above in my blog at http://TekMarketing.net.
regards,
farshid ketabchi
@farshidk, @TekMarketing
By: Farshid Ketabchi on 19/01/2011
at 5:47 pm
I argue that the best “techy” guys are the same guys you can trust to bring with you on technical sales calls.
Moreover, I argue that in order to TRULY appreciate why you develop software, you must get out from behind your desk and hear the good and the bad directly from your customers. Yes, development documents and needs / requirements collections from a PM team is a vital part of the total product development lifecycle. But if you get a geeky type out from behind the desk, give him a tie, and let a customer put him in his place on why his web service does not mean a $#$@ in the real world, that same geeky type starts developing with real life use cases in mind.
….just make sure the tie is not an ugly orange / yellow shade.
By: Chris Adams on 21/01/2011
at 2:14 am