Every good salesman knows that when you’re selling you don’t sell features – you sell benefits. But that’s not enough. Weak proposals that are based on generic benefits (e.g. copied from a vendor whitepaper) are unlikely to be convincing. Luckily, there is very simple brain storming exercise you can use to come up with benefits specific to your organisation – thus making your proposal far more compelling.
The technique involves taking a benefit and then refining it by asking “what is the benefit of that benefit.” You basically keep going until you find something that resonates with the prospective client or customer.
For example, lets assume you’re trying to sell a car which has excellent fuel economy. The fuel economy is the feature. The obvious benefit is: you’ll save money on fuel. Benefit of that benefit: you’ll be able to spend more money saved on things important to you.
That’s a simple example, but you should keep drilling down until you find a benefit that appeals most to the prospect. Here’s an example. Another benefit of low fuel consumption is: you won’t have to fill up the car as often. Benefit of that benefit: you’ll spend less time in petrol station queues. Benefit of that benefit: when you go on family holidays you’ll be able to maximise the quality time you spend together. Benefit of that benefit: the memories you’ll have from the quality time you spend together will last a lifetime.
The slightly cynical readers will be thinking “that sort of stuff is for shady used car salesmen”. If that’s what you’re thinking then remember that all buying decisions have significant emotional element. And this includes IT proposals. A proposal is essentially a sales tool – you’re trying to sell the reader on your idea. So you have to press the right buttons. And this technique will help you find those buttons.
It’s hard to do a genetic SOA example because every organisation has different “hot buttons”. This example is somewhat contrived but it will give you some idea of the power of this technique (especially when you have a few people brainstorming).
I’ve seen mediocre SOA proposals that have a bulleted list of benefits and maybe a definition of what each one means. Definitions don’t sell. Here’s an example of how to do it better: Take the benefit of “reduced integration costs”:
- Benefit of the benefit: because the cost is less, you will be able to integrate more applications.
- Benefit of the benefit: you will no longer be tied to delivering additional functionality through enhancing existing applications built in-house
- Benefit of the benefit: IT will be able to devote more time to evaluating best of breed solutions that meet business requirements.
- Benefit of the benefit: best of breed solutions are typically higher quality and provide richer functionality that bespoke applications written in house
- Benefit of the benefit: the richer functionality means that staff will be more productive and the higher quality will mean less downtime due to computer issues
The person reading your proposal is not being called on to think or to make these connections themselves. Instead, you’re walking the reader through your thought process. This is all pretty simple stuff, And it works.