Quickly move the conversation off the feature and on to the real problems the customer faces by asking about why they want the feature in the first place. Don’t assume the salesperson or even the contact person at the customer has a clear idea of this or of what alternatives there are to solve the rot problem. Be their problem solver and the need for the feature may go away.

Sometimes, of course, they really do need the feature (or another feature you don’t have). That’s where you talk about workarounds.

If that doesn’t work, then you just have to head for the truth. When the real and final answer is no, often what the customer really wants is:

1. An audience – they want to be heard by someone with the power to affect the roadmap.

2. The truth – too often the salesperson is too afraid to say no and will spin vague yarns about priorities and alternatives. The customer is usually relieved when you just so “no.”

3. A reason – its easier to swallow a “no” when you have an idea why things are the way they are.

Customers are grown ups. They can handle it. Few sales have been lost over a single feature, but if that single feature really is the difference between a sale and no sale, you’ve lost the sale anyway.

1. Sales staff are not focused on solutions to problems.
2. Features have names, but these names do not translate into solutions.

Beating the “solution selling” drum is common for management. It has become cliché in high tech companies. However, sales staff believe that if they throw enough features at the customer, the customer will be satisfied enough to evaluate the product and go to the next level in the sales cycle. This process works for many products in the under 1000-seat range. As the prospective client gets larger, the compexity increases. It does not take many seats at a client’s site to reach a point where some customization is required by the customer. Or is it? Often, by identifying the current manual process and the problems the customer wants to solve, we can find a way for the product or service to solve these problems. If you work with the customer to solve these problems using your product or service as the toolkit, you will be amazed by the success rate.

When customers request a feature by name, they are trying to give a solution a name. Sales staff too frequently think the name is a solution, but they do not identify the problem. Sadly, without turning the feature discussion into a problem-solving discussion, the sales person makes the sale hinge on a named feature. The path is paved, and it is difficult to recover.

At this point, the PM gets involved with the client, and the first question goes something like this, “What problem do you want feature XYZ to solve, and how do you solve this problem today?” Then, we have a second conversation. We explain how we can solve these problems today, and how we will solve them in the future. At this point, feature names mean nothing and the conversation places our product or service at a competitive advantage.

Keep asking “why”…

If they stop at the first “why” with “because I just want feature X” then you’re SOL. But if you can get to the root and find out WHY they want it and what they’d do with it, you can propose your mucho better solution.

Then you’ve got em hooked.

If they stop at the first “Why” with “because all the other products have it”, you can get the droid back on side with “if we do feature X just like all the others, we’re replaceable”. With your whizbang implementation that accomplishes the same thing, you can lock the customer into a NEW Feature Y, that they’ll bug all the competitors about from then on. And you’re one step ahead.

My best friend? The Product Roadmap. I share it and share it often. This is what is in the pipeline for enhancements for the next 2 years rolling. It was agreed upon by the User Advisory Board (UAB)and is reviewed 3x per year to make sure we are still on track.

Then I can say – it’s not on the roadmap – or – it is on the roadmap but it is 3 releases out. And, Mr Customer, a jury of your peers (the UAB) made those decisions.

Now – if you don’t have a feature you think you can sell like that, don’t fear. Pull the ‘security’ rabbit out of your hat. This basically boils down to explaining that their feature didn’t make it in because you put your priority on security enhancements (or performance or extra quality checks or some other non-functional attribute of your product) A customer will be hard pressed to argue their feature is more important than something fundamental like performance or security. The real beauty here is that those aren’t features you can actually demo, they just have to take your word for it that you improved them !

Now – I’m not saying you should outright lie but you probably won’t be. You know those bugs that the developer submitted themselves that were full of technical jargon ? You didn’t really know what they meant but note attached to the bug report said ‘already fixed – just assign to me so I can check in the code’ You had some of those right ? Well those were probably something to do with security, performance or general system stability, so you’re in the clear !

All of this talk of “coaching the sales person” and “executive sponsorship” is an excuse for your not having enough solid business justification for your decision. . .and a boss who will back you up.

You *can* turn “no” into “opportunity”. You just have to add OPPRTUITY. So come loaded with those letters and be prepared to talk turkey.

Man, I do *not* miss being in the software business.

Second, the salesperson took the customer’s requirement verbatim. I’ve found that coaching the sales person to facilitate a conversation with the customer about the quantitative business value of Feature X almost always leads to i) the feature wasn’t that important anyway or ii) the customer has a legit need that could be solved in another way