Image: “Computer Software Development” by Fabio Bruna, CC license

Being on the “buy side” of corporate software for many years I’ve seen numerous pitches by software vendors. A few were excellent, most were forgettable, and quite a few were incoherent. Like actress Clara Peller in the Wendy’s ads — for those of you alive in the 1980s — I was often left wondering: “where’s the beef?”

One thing missing from nearly all of these presentations: a clear understanding of what my company did and what our business needs were, not to mention how the software solution met those needs.  Nearly all the meetings with vendors centered around the software and its ability to do this or that.

Another common theme: the vendor would present a business problem — one that you may or may not have — how solving this problem is the key to business success, and how that is accomplished with the vendor’s packaged lines of code.

Some advice to software vendors:

Ask the potential customer what they hope to accomplish with your solution.  Listen.  Ask questions and clarify.  The first response you get is probably not enough information.  Once you understand the problem and how you can help then you are ready to present something.

Know the specific issues facing the customer’s industry. Is there a language used in that industry that someone in your firm is familiar with?  Many software vendors have expertise in selling to specific industries, but have few people in their organization who’ve actually worked in that industry.

Limit the accolades for your firm.  You don’t need five slides explaining how great your firm is and how many of your firm’s customers are household names.  The customer probably wouldn’t be meeting with you unless they already knew you were legit.

Most importantly — connect the dots.  Most people cannot, in their minds, translate software functionality into business benefits.  You must do it for them and you must use the language of their business to do so.  You also need to leave behind a draft business case for investing in your solution. Most people don’t know how to write a business case, for anything.

Image: all of the two- and four-door model cars offered by Dodge in 1974 (excludes station wagons), by John Lloyd, CC license.

It used to be that if you wanted a certain type of software application, you would identify the 2 or 3 companies that specialized in what you needed. That specialization still exists today, but the picture is becoming more and more blurred.

You will find that many software vendors are trying to grow beyond their core expertise by claiming their solutions can also handle other functions within an enterprise.

As an example, consider software firm Enterprise 21, whose advertising places it firmly in the category of manufacturing: “Discover Enterprise 21 Manufacturing Software Solutions.”

But its advertising also includes this claim: “Enterprise 21, however, is more than a stand-alone manufacturing software system – Enterprise 21 is a fully-integrated ERP system that encompasses order management, inventory management, procurement, RF and barcode-enabled warehouse management, advanced forecasting and planning, CRM, business intelligence, and e-Commerce functionality. All transactions and processes in manufacturing are directly linked to all other business departments and units throughout the enterprise with a single database to deliver vital, real-time business information.”

What to do with this information, that this package can also replace systems for other functions? Some applications can, and some truly cannot. It’s quite possible Enterprise 21’s solution is a good fit for some companies for multiple functions.
My experience with these types of claims is that:

• While a package can indeed perform other functions, it is likely to do so with limited features because the ancillary features are not what the firm has spent years developing and improving, unlike the core features of the application.
• There are usually other vendors that specialize in or have spent years developing applications in those other functions the vendor has expanded into.
• If you just want the core functionality that the application was originally designed for, you’ll need to determine how to use just that portion of the solution while integrating it with the rest of your enterprise’s software.

Determine the scope of what you need – that scope that gives you the bulk of the benefits you want. From there you can incrementally determine in an incremental way whether the added value of expanding the software’s footprint is worth the added cost and time of implementing it.