Selling the Sizzle, Not the Steak
Terry R. Bacon, Ph.D.
 President |
Of Salesmen and Heroes
It's hard to find heroes in the world of sales and marketing. The feats of the best sellers are generally unknown except to those who pay their bonuses, and if they gain too much notoriety, the rest of us usually resent them. Indeed, the principal image of the salesman in our society has been Willy Loman, Arthur Miller's decidedly antiheroic figure in The Death of a Salesman.
Now and then, however, a folk hero emerges among that group of humans purported to be able to sell refrigerators to Eskimos. Recent sales heroes have been people like Zig Zigler and Buck Rogers of IBM. Back in the late 40s and 50s, the hero among hucksters was Elmer Wheeler, who once advised his fellow salesmen to "sell the sizzle, not the steak."
That is the subject of this paper—selling the sizzle and not the steak. In a way, this is the story of my conversion. I was educated as an engineer. I was dragged kicking and screaming into selling. Before writing my first proposal, I held the typical engineer's view of salesmen: loudmouthed, overbearing, full of hype, lacking subtlety and substance. When I first heard Elmer Wheeler's advice, it confirmed my suspicion that the world of selling is an impure world of gab and guile and glitz.
Of Heroes and Engineers
My world, by contrast, was one in which substance mattered. We engineers were concerned with functionality, with reliability, with elegance. That last element is crucial. Elegance in engineering does not necessarily mean complexity. It means that the design or solution solves an engineering problem in a particularly satisfying way. The most elegant solutions are often the simplest, but you may have to work through great complexity to reach simple elegance. Anyone who's accomplished that knows that, in engineering, we all are heroes. Every time we tackle some new problem, we slay another beast.
What sets us apart from other dragonslayers is our pragmatism. As complicated as a problem might become, we strive for practical, workable solutions—and we appreciate it when others are equally practical. That's why, when we are forced to write proposals, we describe our steak in fine detail and ignore the sizzle altogether. The steak, after all, is the thing. It's what's being sold. Buyers who are educated enough to appreciate the qualities of our lean sirloin will not need to be sold by a huckster making sizzling sounds in their ears.
At least that was my attitude. Then I began writing proposals—losing proposals. And I asked myself why I was losing them. I spoke to the people who were reading them. Often, these people were engineers like myself. I learned, slowly and painfully, that proposals are not engineering documents. They're not technical reports, specifications, dissertations, or treatises. They are sales tools. Their purpose is to sell something to somebody. Understanding that distinction has made all the difference in my proposals. Now I think Elmer was at least half right: In proposals, you have to sell the sizzle to sell the steak.
Customer-Oriented Proposals
Although I believe Elmer Wheeler was right about what you sell to buyers, I still find that his advice goes down hard with my fellow engineers, especially those technical purists who believe that potential buyers ought to be able to base their buying decisions on a circuit diagram and a list of parts.
So I frame my advice a little differently. I tell them to write what I call customer-oriented proposals. Simply stated, these are proposals written from the customer's point of view. They take a "you" attitude rather than a "me" attitude. In a moment, I'll describe these types of proposals more fully, and I'll offer some tips on how to write customer-oriented proposals. First, however, I'd like to discuss the nature of proposals and their function in the acquisition or procurement process typical to government, business, and industry.
The Nature of Proposals—Or How Organizations Buy Products and Services
I mentioned earlier that proposals are sales tools. Yet the product or service being proposed is often technical. That places proposals in the uncomfortable middle ground between marketing and engineering. They are technical documents, yet they differ from most other technical documents in at least four fundamental ways: purpose, audience, organization, and reader intent.
|
Purpose The purpose of a proposal is to persuade readers to accept your offer to sell a product or service. Most proposals are written in a competitive environment, so a further purpose of the proposal is to convince readers that your offer is superior to (or more beneficial than) your competitors' offers. A proposal is an offer that can be legally accepted, so the ideal proposal is one that closes the deal and results in a contract. Audience The audience or readership of a proposal usually consists of a number of technical and nontechnical readers. Most other technical documents have a narrower and more technical audience. But a proposal must be written for a wide array of readers, including many who would not understand highly technical discussions. Organization Most other technical documents are organized according to the logic of technical and scientific reports:
In contrast, proposals are usually organized according to the customer's need for information. Most often the request for proposal (RFP) dictates what topics will be covered and in what order. This order often reflects the way in which the customer's reviewers will look at the proposals and evaluate them. In fact, proposals are often torn apart, and evaluators receive only the portion of each competing proposal they will actually evaluate. Reader Intent A final fundamental difference between proposals and other types of technical documents is the reader's intent. Readers of proposals do not read for professional enlightenment. They do not read simply for information, nor do they read out of curiosity. They read proposals in order to make a decision. If it's a competitive situation, as it usually is, they read to differentiate between two or more providers of the product or service being proposed. So proposal readers are evaluative. They differentiate between competitors based on evaluation or selection criteria, which may be formal or informal, stated or unstated, objective or subjective. Interestingly, even when the criteria are formal, stated, and objective, decisions are usually also based on informal, unstated, and subjective criteria. That's why it pays to know the customer well. You want to influence those hidden factors. |
|
To write an effective proposal, you must know and address the customer's |
How Buying Decisions Are Made
One of the most important of the customer's selection criteria is price. In federal government procurements, the selection of any vendor other than the lowest-priced vendor must be justified profusely. In business purchasing, lowest price is not mandated by law or regulation, but good business sense dictates that lowest price be a significant factor in supplier selection, and this indeed is the usual practice.
When price is not an issue (for instance, when several competitors' prices are close) then other factors play an increasingly significant role in the selection. Knowing this, most bidders try to promote the added value they bring to the product, service, or business relationship. This concept—value added—is extremely important in today's highly competitive business environment.
The importance of value-added sales stems from the fact that so many competing firms are technically equal. It's rare nowadays to find one firm technically head and shoulders above its competition. The leveling of technology has occurred for a variety of reasons:
- Scientific breakthroughs and technical innovations are rapidly communicated via the media, professional publications, trade shows, etc.
- Talented engineers and scientists transfer among competing firms.
- Internal R&D and widespread reverse engineering are used to assimilate the state of the art as it develops.
- Many companies use benchmarking or related tools to reach state-of-the-art with their competitors, which has the effect of eliminating or reducing differentiation among competing companies.
So we face a constant struggle in writing proposals: how to help the customer differentiate between us and our competitors. To do so, we must show that our firm adds value to every aspect of a project. I'll say more about this later, but let me point out now that value added is a customer-oriented concept. For us to even address the added value we bring, we must look at the project from the customer's perspective. That, in itself, is an achievement.
Who Are The Buyers?
To appreciate the importance of writing proposals oriented toward customers, we need to ask ourselves who makes the selection decision and what they look for in an offer. In the several hundred proposal efforts I've been associated with, the buyers and evaluators have included the following types of people:
- Technical Specialists and Mid-level Managers —An important part of the evaluation team, to be sure, but generally not the real powers.
- Purchasing or Procurement —Generators and reviewers of the terms and conditions. Although dealing with a narrow range of issues, they wield considerable influence.
- Pricing —Their areas of concern are pricing, discounts, life-cycle costing, compliance, cost estimating methodology, warranties, payment schedules, and other critical business issues. They're generally more influential than the contracts people.
- Senior Executives —These individuals include the general manager, vice presidents, functional directors, and other land barons who often either have nontechnical backgrounds or have become too far removed from technical issues. Here is the real power. I have been involved in a number of sales efforts in which a single one of these individuals soured a deal that everyone else up the customer's chain of command approved and supported.
What They Are Looking For
It should be clear from the foregoing list of people who typically participate in the customer's selection decision that a purely technical presentation of an offer is doomed to failure. A review of the questions an evaluation board usually asks indicates why:
- Will this supplier deliver on time (so that we, in turn, can meet our deliveries)?
- Will this supplier have any labor, safety, or other problems that could threaten us? Similarly, could this supplier have (or have they already had) environmental or legal problems that could embarrass us?
- Will this supplier's products or services meet our quality standards?
- Will there be any hidden costs in doing business with this supplier? Could any unforeseen problems raise the life-cycle or support costs of our products?
- Will this supplier provide adequate and timely project management?
- In summary, how will it be to work with this supplier? Will it be a good business relationship?
This last question is the proverbial bottom line. Remember that in today's marketplace, most customers can find several competent suppliers who can meet their technical requirements. So if you're the buyer, the key question becomes, Which supplier would you prefer to do business with?
As some of you may have noticed, my list of selection criteria excluded technical issues. I want to correct that oversight now. Technical issues do play an important role in buying decisions, but notice the kinds of technical questions buyers are asking these days:
- Is the product comfortably state of the art? Products on the far reaches of technology are usually unproven and potentially full of bugs. Most customers today are wary of the performance risks of too much innovation.
- What is the growth capability of the product? How much flexibility does the product have? Can it be grown without significant retooling or additional cost?
- How can we protect our investment? An increasing concern among buyers is protecting their existing investment in hardware, software, and systems.
- How easy will the product be to maintain and support? Logistical support has been one of the fastest growing fields in the last two decades, today it falls under the rubric of supply chain management. Why? Because, like all of us, today's budget-conscious firms are trying to get more for their money.
- Can the product or service be customized to meet our needs? Here's another wave of the future. more customers are demanding customized products or services, and more suppliers are building customizing into their offers. Today, customization is added value; tomorrow, you won't get a contract without it.
Customization, ease of maintenance and support, protection of investment, growth capability, proven and reliable hardware—all these are technical and design issues. But notice that not one of them favors you, the seller.
Unless you are that rare and endangered species—the altruistic seller, defender of the innocent—you would rather not see buyers protecting their investment in existing hardware. No indeed. And unless you are independently wealthy and don't care whether you're paid, you favor growth as a design feature only if the growth requirements occur regularly and you're the sole-source supplier.
Today, even the technical criteria reflect customers' concerns with the long-term usefulness of products and services; with the reliability, supportability and life-cycle cost of every product; and with the kinds of business relationships that result in long-term equity for both parties.
In an article for the Harvard Business Review, Theodore Levitt argued that all products are to some degree intangible. From the buyer's point of view, said Levitt, "the product is a promise, a cluster of value expectations." Further, "The way the product is packaged (how the promise is presented in brochure, letter, design appearance), how it is personally presented, and by whom—all these become central to the product itself because they are elements of what the customer finally decides to buy or reject."
I can almost see Elmer now, standing by the grill, the rich aroma of broiling steak wafting through the air. Over the loud sizzling, he says, "See! That's what I mean. Customers buy intangibles, not dead meat. Sell 'em aroma! Mouth-watering taste! Sizzle!"
The "Me" Proposal
A remarkable number of proposals not only don't sell the sizzle, they try to turn meat-eaters into vegetarians. The customer says, "I'd like a sirloin steak," and the proposal offers spinach quiche. Let's look at an example from an actual RFP and proposal response in the telecommunications industry. The customer wanted a statewide telecommunications system. In the RFP, the customer specified a number of features this system should include. Here is one such requirement:
RFP Requirement
The system shall provide the ability to program a minimum of 20 different stations to each automatically dial an individually programmed telephone number upon going off hook on the station. At a minimum, the number dialed may be programmed to be "0" for an attendant, an unrestricted PBX extension, or an outside number that may be either local or long distance. The responder shall state the maximum number of stations that can be programmed as Hot Line/Ring Down stations and any limits on the numbers that can be automatically dialed. Here is how one bidder responded:
Proposal Response
The Model 1066 PBX allows up to 64,528 Hot Line numbers, with up to 24 digits stored per Hot Line number. This number is reduced by the number of individual and group Quick Dialing numbers assigned for purposes other than Hot Line. Included in the numbers that can be called
using Hot Line service are all required numbers.
Even this short example demonstrates several of the worst abuses of "me" proposals:
- They ignore at least some of the customer's requirements or requests for information.
- They often redefine the problem in the writer's terms.
Note that the proposal response fails to address the customer's primary concern: How many stations can be programmed as Hot Line/Ring Down stations? (The number of Hot Line numbers allowable is a different issue.) "Me" proposals often have the following additional problems:
- They often confuse complexity with sophistication and are consequently unclear.
- They are often organized according to the writer's perspective or conception of the problem, not the customer's.
- They often include options the customer hasn't asked for.
- They are often arrogant and unresponsive; they solve the offeror's problem, not the customer's.
The following example shows some of these problems. The left column contains an outline of the customer's RFP; the right column shows the table of contents of one bidder's response, which, incidentally, was a loser. Can you see any correspondence between the RFP and the proposal?
|
Customer Order Fulfillment System
1. Introduction |
Customer Order Fulfillment System 1. Introduction 2. Application Design 2.1 Backbone Systems 2.2 Personality/Technical Editor Design 2.3 Table Maintenance 2.4 Application Controls 2.5 System Enhancements 2.6 Future Enhancements 2.7 Additional Design Documentation TECHNICAL DESIGN & IMPLEMENTATION 1. Technical Design 1.1 Technical Architecture Definition 1.2 Hardware/System Software/Network Overview 1.3 Database Design and Distribution 1.4 Application Program Architecture 1.5 Performance, Security, and Controls 1.6 Development Approach 1.7 Product Descriptions 2. Conversion 2.1 Training Approach 2.2 Documentation Approach 2.3 Conversion Approach 3. Operations and Support 3.1 Operations 3.2 Centralized System Support 3.3 Hardware/System Software Support 4. Implementation Plan 4.1 Implementation Plan 4.2 Implementation Schedule 4.3 Project team Organization and Staffing 4.4 Resumes 4.5 References 5. Cost Estimates |
Admittedly, organizing proposals so that they are consistent with the RFP and also allow you to present a clear picture of your offer is sometimes difficult. Nevertheless, the proposal outlined on the preceding page appears to have little correspondence to the RFP. I read both documents thoroughly and could find little correspondence myself. They might have been dealing with two different projects.
Reading the Customer's Mind
I once received what I think must be the ultimate compliment for a proposal writer. My company bid to McDonnell-Douglas Astronautics Company (MDAC) for the contract to train the proposal team MDAC was assembling to write its proposal to NASA for the Space Station program. After we won the award, I had the opportunity to meet with the MDAC representative who wrote the RFP and read and evaluated the proposals. Not knowing that I had written our proposal, he remarked on its quality and comprehensiveness. Then he said something intriguing: "When I read it, I had the uncanny feeling that I was reading my own thoughts."
Though gratified by his remarks, at that moment I felt more like a scientist who had stumbled upon a major discovery. As much as anything, I was startled at having, in effect, read the customer's mind. It occurred to me then that that is the real secret to writing good proposals—reading the customer's mind, making the customer feel comfortable with your grasp of the issues, presenting a conception of the problem and solution that precisely matches the customer's conception of the problem and solution. Now the questions were, What had I done? and Could I do it again?
The "You" Proposal
Later, I reflected on what I'd done in writing that proposal. In retrospect, the steps seemed simple (too simple to constitute a major discovery, but for me that's what it was):
- I had followed MDAC's RFP to the letter. I proposed that we provide precisely what MDAC asked for.
- I organized our proposal precisely as the RFP was organized. I made a checklist of the points they wanted covered, and I covered them in that order.
- I used MDAC's terminology. When our terms differed from theirs, I used their terms.
- I explained, throughout the proposal, how what we were offering would benefit them. I was careful to state how our design was the right design for MDAC.
- When I didn't understand a requirement, I called and asked them what it meant. In short, I never allowed my ignorance to turn against me.
- I used every trick up my sleeve to make my message clear and easy to read and evaluate. More on that later.
I incorporated what I had learned into the training we subsequently developed and conducted for MDAC. I would like to think that what we taught them about customer-oriented proposals helped them win that NASA contract worth hundreds of millions of dollars.
Characteristics of a Customer-Oriented Proposal
Since the MDAC proposal, I have written or consulted on hundreds of proposals. That accumulated experience has helped me refine my concept of the customer-oriented proposal, which I think has these characteristics:
- It responds to the customer's real issues and problems.
- It addresses all of the customer's requirements and requests.
- It reflects the customer's conception of the project by mirroring the RFP in organization and coverage of topics.
- It uses the customer's terminology.
- It is clear, easy to follow, and easy to evaluate.
- Lastly, it emphasizes the benefits to the customer of your offer, particularly the intangible benefits of doing business with you.
These points are the heart of this paper, so I will address each of them in more depth.
Responding to the Customer's Real Issues and Problems
This is a subtle but significant factor. The requirements stated in the RFP rarely reflect the whole truth about the customer's needs. Underlying the requirements are the issues that caused the customer to specify those requirements. Even deeper are the problems that gave rise to the issues. The situation looks like the following illustration. In an RFP, you generally see only the requirements.
In one actual procurement, the customer specified a rapid electronic mail system to be installed between its regional offices and its headquarters. Of particular concern to the customer was the speed of transmission and turnaround the system would allow. Specifically, they wanted direct routing of messages to addressees so that "same-day response" to messages was not only possible but routine.
Upon analyzing this opportunity, we discovered several issues underlying the requirement. First, their existing electronic mail system was configured such that incoming messages entered a queue. When traffic was heavy, these messages could remain in the queue for days. Second, their existing system had no means of sorting messages by priority; routine messages were treated the same as important queries from customers.
Those issues gave us insight into their real problem—loss of business to competitors because they were not resolving their customers' problems or complaints in a timely manner. That was the real problem.
Devising an Effective Proposal Strategy
Understanding the customer's real problem allowed us to develop a more effective strategy, and that's the purpose of analyzing the issues and problems underlying the customer's requirements. We would have given them the same electronic mail system regardless, but knowing they needed faster resolution of queries and customer complaints told us how to sell it.
Understanding what the customer is trying to solve helps us develop an effective proposal strategy. I can't emphasize this point too much. The issues and problems underlying the requirements are the customer's hot buttons. They are the reasons the customer is procuring a solution, and they form the basis for the selection criteria. By pushing the customer's hot buttons, you show that you understand their problems in depth and that your offer is going to meet their real needs. Now I want to point out several things:
- The issues and problems underlying the requirements rarely appear in an RFP in toto. The RFP may state some of them, but you won't know them all unless you work with the customer and ask probing questions.
- A proposal that shows an understanding of the underlying issues and problems is a "you" proposal—it is oriented toward the customer, not the offeror.
|
For every requirement in an RFP, ask "Where did this requirement come from? |
To uncover the issues and "hidden" problems, ask the questions above. These questions signify both a technique and an attitude. They help you identify the customer's hot buttons, discover the appropriate technical solutions, and then sell those solutions in the most effective manner.
Addressing all of the Customer's Requirements and Requests
It goes without saying that a proposal should respond to every customer requirement and request for information. Yet a surprising number of proposals aren't really responsive. In one major proposal I reviewed, over half of the 260 sections in the proposal failed to address topics required by the RFP. That sort of unresponsiveness is nothing short of reckless. No wonder they lost the bid. Here is my prescription for total responsiveness:
|
When the customer asks you to address topics A, B, C, D, and E, |
To help ensure total responsiveness, I recommend a simple tool called the compliance checklist, which is illustrated on the next page.
The Requirements Checklist
A requirements checklist is a rewritten form of the RFP in which each specific requirement is listed as a separate item and each item begins with a verb indicating what the proposal writer must do. Here is the RFP paragraph we examined earlier and a requirements checklist based on it:
|
The system shall provide the ability to program a minimum of 20 different stations to each automatically dial an individually programmed telephone number upon going off hook at the station. At a minimum, the number dialed may be programmed to be "0" for the attendant, an unrestricted PBX extension, or an outside number that may be either local or long distance. The responder shall state the maximum number of stations that can be programmed as Hot Line/Ring Down stations and any limits on the numbers that can be automatically dialed. |
Create a compliance checklist for every paragraph in an RFP that requests or requires information. Then follow the checklist while writing your response. Address every requirement.
|
Reflecting the RFP in Organization and Coverage
The compliance checklist gives you a plan for responding to the requirements in order. Here's an example:
|
Our Model 1066 PBX offers the most extensive and versatile Hot Line/Ring Down capability in the PBX industry:
|
Using the Customer's Terminology
Quite often, the terms the customer uses to signify events, activities, or operations differ from the terms you would use. "Hot Line/Ring Down," for instance, originated as one company's terminology for describing a particular feature available on a PBX system. Eventually, that term gained wider, generic use within the industry, much as "Coke" generically refers to any cola beverage and "xerox" is often used as a verb to signify the act of copying.
If your company sold PBXs, you might call your "Hot Line/Ring Down" feature something else, such as "Direct Access Dialing" or "Off Hook Dialing." However, if the customer asks for "Hot Line/Ring Down" service, use that terminology in the proposal. If you switch terms, you risk alienating the customer and confusing the discussion. I have read proposals that complied with the requirements but didn't seem to because the writers had switched terms.
|
Use key words in the RFP to cue readers to the fact that |
To write a customer-oriented proposal, treat the RFP as a list of key words and phrases. Repeat those key words and phrases in your proposal as a way to cue the reader. In the example on the preceding page, for instance, the RFP asks offerors to state "any limits on the numbers that can be automatically dialed." Limits is the key word. Notice how the proposal response not only repeats that key word but emphasizes it (with italics).
Emphasizing Benefits
One of the long-standing truisms in proposal writing is that people do not buy features, they buy benefits. In other words, they don't buy the thing itself, they buy what the thing does for them. It should be clear that features, per se, are a "me" concept, whereas benefits are a "you" concept. A feature is what I have to offer. A benefit is what my offer does for you.
In his book The Marketing Imagination, Theodore Levitt states that "people buy products [and services]...in order to solve problems." According to him, everything you sell is a problem-solving tool. What you propose to a customer is a solution. Thinking of it in these terms helps us understand the relationship between features and benefits.
A benefit is a goal or end state; features are the means to that end. Thus, when I propose to network a customer's microcomputers, for instances, I am essentially promising a set of features (protocol support, synchronous interfaces, etc.) that will result in the following kinds of benefits or goals:
- Protection of the customer's investment in existing hardware
- The ability to communicate across incompatible micros and operating systems
- The ability to share files and applications without time-consuming conversions.
The customer's situation prior to accepting my proposal and implementing my solution is a problem state. The benefits I offer represent the solution state. The features of my offer are the difference between problem and solution.
If my proposal discusses the features of my offer but not the benefits, then I am citing actions that have no purpose, and the customer—who is seeking a solution—will have no reason to choose me. Conversely, if I discuss benefits without identifying the features leading to them, I'll be describing utopia without explaining how to get there.
An effective proposal discusses both. In fact, it links features and benefits so that customers understand both what I am proposing to do and how what I'm proposing will solve their problems. Here's a simple way to analyze the features and benefits of your offer.
|
For every feature in your offer, ask "So what?" For every benefit in your offer, ask "How so?" |
Now the real key to writing an effective proposal is to identify the benefits of every feature and the features responsible for every benefit. Link them in the proposal, and emphasize the features and benefits that are unique to you—the ones your competitors cannot or will not offer. That uniqueness is your competitive edge.
Summary
In proposals, marketing and writing are synonymous. All the issues I've been discussing are related to sound sales writing:
- Knowing and understanding your readers
- Writing so that the document meets the reader's needs
- Thoughtfully organizing the document for clarity and impact
- Using such techniques as headings, lists, and visuals to emphasize important ideas
These are a writer's concerns. Yet in proposals they apply in a unique and sometimes unsettling fashion. If you're an engineer and not a seller, you may be uncomfortable telling readers that your offer will benefit them; that it's the right approach to the problem; or, heaven forbid, that it's the best solution. To many engineers, that kind of self-promotion can seem like the worst kind of hype.
I used to feel that way. Then I met Elmer Wheeler. Remember what he said: "Customers buy the sizzle, not the steak. They buy solutions, benefits, results, bottom lines, business relationships, and the added value that offerors bring to the table."
The most effective way to sell that cluster of values is to write a customer-oriented proposal—one that's oriented toward them, that meets their needs, addresses their problems, reflects their conception of the project, uses their terminology, and presents the offer in terms of how it benefits them.
I can't stress that last point too much: benefits, benefits, benefits. Tie them to the features of your offer and make them tangible. That, in any kind of proposal, is how you sell the sizzle.
Copyright 2001 by Lore International Institute, Inc. All rights reserved. No part of this website may be copied or distributed to others without written permission from an officer of Lore International Institute, Durango, CO 81301 (970) 385-4955