If your daughter ever comes home with a friendly, outgoing guy named Norbert, shoot first and ask questions later.
Some years ago, a salesman named Norbert at the SCM vendor where I worked got a call in late December from a prospect that had decided to buy from a different vendor. He asked to keep an appointment he had made for a wrapping up session. He went to the meeting with a sales proposal in hand, and after reengineering the vision of the customer, actually left with a sales agreement. Now that's a short sales cycle!
It's amazing the things that you can learn if you hang out at a bar with a group of hard-drinking, fast-talking sales folk. It's also amazing how much free booze you'll get if you have a reputation for helping them out. Since I did both, I picked up a little bit about solution selling (SS). Now that the hangover is gone, I'm going to tell you what I learned.
SS is a sales methodology formalized in the 1980's to deal with the long sales cycles and high knowledge requirements found in the sale of complex, diffuse, high-dollar systems. It should come as no surprise that nobody needed much time to decide how to purchase systems that are simple, easily understood, or cheap. The complex stuff was causing huge problems since the salespeople didn't understand what the customer needed (in many cases, the customer needed to buy more products or services) and the customer didn't understand what the salespeople were selling.
The software industry has more than its fair share of complex, diffuse, high-dollar systems. Consider an office e-mail system, for example. Deciding which system to purchase, or even if a system, as opposed to a collection of single tools, should be purchased, qualifies as complex (hard to understand all the issues, both for the sales team and the clients), diffuse (broad impact across the organization), and relatively high cost.
Out of the software space completely, selling advertising campaigns is another candidate - there's no way of knowing in advance just exactly how popular two beer drinking lizards, or Joe Isuzu, are going to be. Instead, the requirement is to sell confidence, as neither the client nor the seller really knows what the results of the campaign will be. SS is a methodology with application across a wide range of sales markets.
Tools for test case management, requirements management, and change management definitely meet these criteria. They are complex, affecting the entire software development lifecycle. They are diffuse, impacting developers, testers, product managers, projects managers, and senior management. And they are very expensive1, even when the software is available at no initial cost.
How Is Software Sold?
There are three basic sales models used for computer software: bundling, shrink wrap, and solution selling. There may be organizations out there with complex products that don't use the solution selling approach, but I couldn't tell you where.
1 Total Cost of Ownership (TCO) must account for hardware, installation, training, support, scripting, and maintenance.
Bundling
Bundling is easy; you provide a copy of your software as part of some other purchase. You may or may not actually reflect the software cost in the price breakdown on the invoice. Some classic examples of this are all of the old school computer vendors, who include the operating system with the hardware. Also, remember the controversial browser wars, where the bundling of Internet Explorer with Windows was claimed to be an unfair competitive advantage?
Shrink-Wrap
You know about shrink-wrapped sales already, as you use this model every time you go to the store. There are software stores, too, and these typically sell shrink-wrapped software. In general, this is software that you can use at a single workstation. Perhaps it is limited by possession of the original CD, as with computer games.
Solution Selling
The relative complexity of a system may sometimes be high enough to disqualify it from shrink-wrap sales. Other times, the system itself is relatively simple. It is the impact of the system on many different users or other systems that causes the shrink-wrap approach to fail.
This is where diffuse comes in. Nobody, I hope, considers e-mail a complex tool from the user side. Most users send and receive messages all day long with minimal training. However, the impact of the system across the whole user community, including the need for special servers, maybe a dedicated administrator, etc., make the system too complex to be sold as a shrink-wrapped package.
Objectives of Solution Selling
Simply put, SS was developed to help ignorant salespeople deal with ignorant customers. The objectives of solution selling are:
· To establish the salesperson in a consultative, cooperative role with the customer. No longer will the salesperson be an adversary, trying to pry money out of your hands. Rather, the salesperson is there to help you spend your money effectively, like an elder brother helping you buy your first car.
· To focus the sales process on establishing a broad, complete vision of the business issues and strategic goals facing the customer. Rather than trying to sell a single product, SS organizations typically have a broad product line that includes products and professional services. Understanding the complete situation helps the seller determine what additional products and services the customer may need.
· To establish a vision in the mind of the customer. "When you're ass deep in alligators, it can be hard to remember that you set out to drain the swamp." Establishing a shared vision helps the customer know that the original objective has been met, even if subsequent developments have changed the scenario.
· To make the customer want to buy from the salesperson. This is about money. Nobody wants to help out but not get paid for it.
Skills
Sales people aren't techies. They don't study programming books and they don't go to school for engineering. Instead, they have skills that are not technical. Attempting to convert a salesperson to a techie removes a skilled salesperson from your arsenal and provides you with an angry, confused, clueless semi-techie. Before you techies out there smile too hard, picture yourselves with an attaché case and a suit and instructions to sell half a million dollars-worth of product in the next three months.
The skills that salespeople develop are selling skills. Frequently, these are people skills: schmoozing, listening, eliciting information, networking, etc. They don't necessarily have programming skills, or network administration skills. Sellers generally aren't good at handling technical questions. The solution selling methodology tries to mitigate the impact of this by elevating the dialog out of the technical arena.
Solution sellers don't want to get bogged down in discussing bits per second, or ergs per gram, or anything technical. Sadly, managers are as likely to be technically misinformed as the salespeople are, and once a manager tells you that an eight-megabit ROM will be large enough, he probably isn't going to listen when you tell him he meant to say megabyte.
Solution sellers want to talk about solving the problem and delivering a solution, but not about specifics. Hence the name: SS. The objective is not to answer a technical need. The objective is to convince the client that the seller's organization has all of the resources, hardware, software, services, support, manufacturing, creative, legal, whatever it may take, to solve the client's problem. Selling a solution. Solution selling.
Solution Selling KPA's
A key process area (KPA) is a term that I've taken from the CMM. I want to show you that there is a definite methodology here. A set of processes is interacting to produce a desired outcome. In fact, SS is probably a more valid methodology than anything in the SCM space (compare the number of training courses offered).
Identify Key Players
The identification of key players is both a prescriptive and a descriptive activity. A company using the SS approach will identify typical key players, such as "IT manager", that are likely to be involved in their sales approach. After a sales team makes contact with a potential customer, the team will describe the actual players they met.
This is an application of patterns. Players that are expected but not present will be sought out. Players that are present but not expected will be accommodated if they are truly key players, or they may be excluded in favor of a higher level of power or authority. For example, a senior developer may be the ‘squeaky wheel' that is driving the acquisition of a new SCM system. But the sales team may try to exclude her from the negotiation process in favor of the VP of Software.
Establish a Pain Chain
"Pain" is SS jargon for things that are going awry. Sales are down: that's pain. Expenses are up: ditto. SS is very specific about one thing: there is no technical pain. My PDA cannot synchronize with my calendar tool, but that's not pain. That's a cause of pain or, perhaps, a symptom of pain. The pain, in this cas,e might instead be, "My employees are missing too many meetings" or "We couldn't get the PDA synchronization feature into the last release."
A pain chain is a set of pain descriptions, along with the reasons for them. In each case, a link in the chain has as one of its reasons a pain from a lower level. Thus, the VP of software development may have, "We miss too many ship dates" as a pain entry, while the SQA director has, "Our QA cycle is too long". The SQA pain is a contributor to the VP's pain.
The objective of the pain chain is simple: to get commitment from the upper echelons of the organization. If the sales team can show a simple visual aid that ties the VP of software development down to the Integration Test manager, then the VP will be committed to helping the manager.
This commitment means that there is an increased likelihood of the organization successfully implementing the solution that they buy. It's hard for a test manager to impose restrictions on a development lead, especially one who claims he's running late. But when the VP says, "Do this thing," it's amazing how the response changes.
Establishing a Vision
A vision is a very personal thing. The SS objective is not to show you a car and say, "Want one?" Rather, when creating or reengineering vision, the objective is for the customer to say, "I want a car. It should be red. A convertible. Two door. Very sporty. Go fast."
The customer must own the vision. It is the customer's vision, not the seller's. The saleswoman may ask questions to help customers define or articulate the vision, much as a psychiatrist asks questions to help clients understand themselves.
Vision creation is the term used when establishing an initial vision. Vision reengineering is used when competing with an established vision.
The 9-Box Question Procedure
The 9-box question procedure is a 3x3 matrix of questions that are used to help the customer with their vision. Along one axis it uses open questions, closed questions, and confirming questions.
Open questions are exactly the sort of thing you learned about in school: they require a long, descriptive response. Closed questions are targeted on a specific detail and require a shorter response, such as yes/no, or a choice from multiple options. Confirming questions are not really questions. They are an opportunity to restate the customer's words to confirm that the saleswoman and customer are on the same page.
Along the other axis there are three categories. These categories are causes, effects, and capabilities. The causes are where pain is uncovered. The effects are where the pain is mapped to other players. The capabilities are where solutions are explored. Because the pain is described in abstract terms such as, "Our release cycles are too long", the solutions are not technical ("buy our software") but rather capability based ("Shorten your release cycle").
Here's an example 9-box diagram. Note the sequence numbers:
| Open Questions | Closed Questions | Confirming Questions |
Causes | 1. What is causing these long release cycles? | 2. Would you say the average test cycle is 25%, 50%, or 75% too long? | 3. So the long release cycles are because your test cycles are about 50% too long, right? |
Effects | 4. Other than yourself, who else in the company is affected by these long release cycles? | 5.If the shipping team has to work overtime, how many other teams are? Is the sales team affected, too? | 6. You're saying that the sales, documentation, and shipping teams are all impacted by this? |
Capabilities | 7. So what will it take to shorten your release cycle? | 8. If your regression tests ran each night, would that ...? | 9. To confirm, if you could automatically run regression tests each night, that would ...? |
Notice that the 9-boxes technique is an iterative one, and that there's no limit to how many times an individual line or an individual box may be used. The objective of the SS seller using the 9-box approach is to ensure that each box is checked off. Every open question, every reported pain, should be narrowed down, explored, and capabilities for solution should be discussed.
As with key players, the vendor will provide the seller a list of expected pains (problems we can solve) and instruct the seller to dig into these areas (see box #5, for example).
Finally, note that the closed questions (middle column, numbers 2, 5, and 8) are supposed to be phrased in terms of line noise: #$%. That is, the questions should specify number (#), dollar value ($), or percentage (%). This ties in to the value proposition. See "hard value proposition", below.
Sponsorship
SS acknowledges two kinds of sponsors: sponsors and power sponsors. A sponsor is someone who will get you into the organization. A power sponsor is someone who has the power to make the decision, the power to implement the solution, or some other important level of power.
What sponsorship boils down to is access to a high, appropriate, level of authority. The reasoning is that a senior developer (sponsor) can force a decision, but the VP of software (power sponsor) can force the implementation.
A solution seller will almost always try to get access to power. She doesn't necessarily want to sell to that level of power, but she does want access so that she can construct a pain chain. If she can get the CEO in the pain chain, then the CEO will pressure the VP of software who will ensure that the SQA manager doesn't forget to tell the integration test lead to the following.
Control of the Sales Cycle
Maintaining control of the sales cycle is a fundamental tenet of SS. No SS vendor wants to give up control of the sales cycle, because very few customers are good at buying complex software. Having a "Don't call us, we'll call you" customer is the same as having no customer. There's no way to predict when the final decision will be made and no way to help the customer through humps or difficult transitions. Control of the sales cycle means setting the pace for the customer's decision making; it doesn't, however, mean forcing a short decision, nor does it mean eliminating due diligence. It does mean making sure that all the elements of the sales cycle are going to have value, and ensures that the vendor will be able to influence each step of the decision process.
I once visited a client who had an enormous box filled with CDs and manuals from a vendor. I asked if an evaluation was under way, and was told, "We've got a demo version. They set it up for us, but nobody has used it for two months."
That's a sales cycle out of control. The demo isn't providing any value to the customer. It's occupying a server that could be used for something else, and the manuals are taking up three or four cubic feet of space in someone's office. It's certainly not providing any value to the vendor, so what was the point of that demo?
For reasons like this, a SS salesman will resist any demonstration or evaluation period unless it is well documented. A well-documented demo or evaluation period, with a fixed schedule and defined objectives, is a wonderful aid to sales. A poorly documented one is just a giant hole in the calendar. The salesman will resist expanding the scope of meetings, bringing in other departments, and the like, after getting access to the right power levels and building a pain chain. The trade-off for the salesman is more potential sales versus wasted time.
Pilot Plan
A pilot plan is a schedule of activities and timing for a pilot project. If you are unclear about how an implementation should proceed, you'll want a demo, or a pilot, or an evaluation period. Demanding a pilot will cause the sales team to negotiate with you for desired outcomes. Ask them to provide a pilot plan for you. It will almost certainly be optimistic, and it may not cover every single issue, but an experienced sales team will have resources available, including plans they've done in the past, that can take you 80% of the way to understanding what challenges your purchase will involve.
Reference Stories
References are a chestnut of sales. The credible reference can help a balking customer over a hump by giving confidence that someone else has done this before.
A typical SS reference story is very abstract, and looks a lot like boxes 7 and 8 of the 9-box chart, above. A reference story will look like this:
Level: Vice president
Problem: Suffering from long release cycles (box 7)
Needed capability to run nightly regression tests (box 8)
Solution: We provided this capability
Before you ask, yes, they're that short. Sometimes a single company name will be published, but usually not. Instead, if the long verbal list of other customers who have been "saved" by this solution doesn't satisfy the VP of Software, the sales team will go back to HQ to get permission to arrange a reference phone call with a customer.
Hard Value Proposition
The final sales proposition will be made in two parts. First, of course, there are the individual line items. This many server licenses, that many clients, so many simultaneous connections, some number of training courses, thus and such professional services, etc.
The second and more important part, however, is the value proposition. This proposition uses the pain chains and the 9-box results and speaks in simple, direct terms to the issues that were raised during the sales cycle.
Sales proposal:
By providing the software and services listed in the appendix (first part), I hope to provide your company the following value:
- Shorten test cycles by 50% (pain from SQA manager)
- Shorten release cycles by at least 1 month (pain from VP)
At a total cost of $1 million.
Sincerely,
S. S. Person
This is a hard value proposition. It skips over the details of the solution (leave that to us, we're the vendor, we know what you need) and proceeds to the outcomes. The point is that the salesman isn't selling software, and he isn't selling professional services: he's selling a solution to a set of problems. Selling a solution is what it's all about.
Using What You've Learned
Now that you know all this about SS, what can you do with it?
Use It Yourself
First, use it yourself. That is, if you need to convince someone in your organization that it's time to buy a new software system, the techniques here are just as valid for you as for a salesperson. Of course, they get more practice than you do.
If you've been wanting that requirements tracking tool, or software upgrade, use these techniques. List all the key players in the acquisition process. Put together a pain chain that links these players to your request.
Send an e-mail or two that mentions some of this pain obliquely and encourage them to answer the open questions from the 9-box process. Identify your power sponsors: who can approve this money? Who can approve the implementation effort? If there's a budget problem, then who can change the budget? Finally, put together a pilot plan if you need to. Obviously an upgrade shouldn't need one, but new software will.
If you do all this, your chances for a successful close go through the roof. Keep in mind that the solution selling approach is fundamentally right. Your boss (or her boss) doesn't want to upgrade because the new database server supports multithreading. Instead, your boss will want to upgrade because the new database server will improve responsiveness by roughly 15% across the board, saving each developer about 30 minutes each day.
Understand the Sales Cycle
Second, you can use this information to understand and guide the SS process when you are dealing with a vendor. Suppose you do want to buy a brand new requirements management tool. You look up requirements management on Google and make a list of vendors, but then what? Well, when you call them, you'll go through the prospect filtering process. If you can preempt the sales team, making their jobs easy in the beginning, you can overcome some of their objections to giving you stuff. They're still in love with you as an easy sell, since you gave them sponsors and access to power and pain chains right off the bat. When you ask for an extended pilot with some free professional services to handle the installation and explore integrating their tool with your in-house defect tracker, well…
Conclusion
To wrap this up, let me make it clear that SS is not some sort of evil doctrine. It's a process that is genuinely intended to make the sales cycle go more smoothly for everyone involved. A sales cycle built on the SS KPA's is more likely to conclude in a reasonable time. Since you wouldn't be talking to these people if you didn't need to buy something to solve your problem, it's not like you're being tricked into buying something you didn't want. Of course, this presumes that you're paying attention during all those sales meetings: please don't buy 100 licenses if you only need 5!
Two nice things about solution selling are (1) it's full of tricks that you can use yourself and (2) it's predictable, so that you can understand what the sales team is doing throughout.
