Wednesday, July 19, 2006

When software has too much stuff

It’s always a great surprise to me that the Sales Engineers that accompany Account Executives on software sales calls don’t just lose it and start throwing their laptops around the room.

Sales Engineering is a special art. Its a balance of impressing the customer with unique features against showing a deliverable amount of real software, while translating everything you know about your world to the little you know about the customer’s.

Why do you care? You’re probably not in the market for software, and sales doesn’t really affect the analysis and thought-leadership that some readers purvey. Or does it?

Sales, after all, is what keeps companies afloat. Software analysts and thought-leaders are voicing an opinion on where customers should be moving towards to implement better systems, being a mouthpiece for a ‘maybe’ market, and influencing customers to look at specific groups of vendors. Corporate architects are guiding what their companies will buy and deliver. Product Managers try and listen to everybody and mix it all with a little of ‘what the market wants now’, to get their product to be most successful. There are lessons from sales processes that we should all know.

Having done my share of sales support as a sales engineer, solutions architect and general gofer, I speak with a little authority. But I still have no idea how the really experienced SEs do it day in, day out. Sure, there is a buzz when a software demo goes well, everyone in the room bonds, and the customer’s head doesn’t stop nodding the whole way through. The problem is 90% if the time you have to deliver the impossible.

As ever the problem is with personas. These are what make the ‘buyer’, ‘user’ and ‘techie’ in the room who they are. Personas are the measurable attributes like role, education, age, computer skills. And they are qualitative attributes: risk tolerance, aggressiveness and the Geoffrey Moore psychographics of technology adoption.

Every organization has different personas for each role, though similar personas often cluster in particular industries and types of organization. Obvious differences appear in corporate, non-profit and government organizations. And if the personas stay in a particular organization for a while they absorb some of the surrounding personas from around them. Think of it as persona-perspiration – a length of time in a company is like a hot rush-hour on the Tube in London or the Subway in NYC. You get some of the surrounding sweat, anxiety and attitude of the surrounding people, just in a less condensed amount of time.

When a great Sales Engineer walks into a sales call with a new customer he or she is making constant assessments of the personas in there, balancing that against their roles. SEs use this to help them judge how to respond to specific questions, who to pay a little more attention to and when to be honest about a deficiency in the demo application. Even given all their experience and attempts to show the application in the best light using the language of the customer, there is a single issue that can derail the whole thing:

Incorrectly guessing how the unspoken goals of the business, and those of the individual personas, was translated to a set of RFI requirements.

When this happens you’ll hear:

"It looks like your application has far more in it than we need"

In my experience this really means:
“You should have guessed by now that I have no idea how I will convince my staff to use this, as they have rejected the last two systems I bought”

“I’m really hiding from you that I can barely use the Internet, so the slick collaboration tool you showed scares the hell out of me”

Being open and honest with vendors is the best way to get a demo that really addresses the business goals driving a buyer's requirements. This is important, as you shouldn’t be trying to judge software on how good a mind-reader the Sales Engineer was over the last 48 hours of preparation.

Of course, the issue still remains of the always unspoken goal:
“You won't guess that my goal is to just get the IBM/EMC/etc. guy to give me the software for free when I buy his big boxes of tin”

This is completely unavoidable, and acknowledged by everyone in the airport bar after the presentation and demo.

But if the problem really is that the software appears to have too much stuff in it, however well it was shown, buyers have a responsibility to do one of two things:

  • Stop the selection process and pick more appropriate vendors (not from the big names that Gartner tells you), because they all have a similar level of capabilities,

  • Get someone who can really envision how enterprise class software can help your organization exceed its goals

No software has too much stuff if it meets total cost of ownership the goals of the business. Only with good guidance from all directions can buyers really make sure they get software that really fits their organization.

Technorati tags:


Anonymous said...

You're right. I've been there as that SE. Why can't IBM & EMC just sell their software like the rest of us!

Phil Ayres said...

See Vinnie Mirchandani's post on the cost of sales to really highlight how customers could help themselves and the industry in general. Or maybe vendors just pick up a 'no-salesman' model.

His and other interesting discussions are linked from: