Describing your proposal’s features

In a proposal, features are the vehicles for providing benefits to your customers. Features are tangible aspects of products that set them apart from your competitors’ versions. They’re the pieces of equipment that customers can watch you install or calibrate; the functions within a website that your customers can observe working on a screen; the physical aspects of a tool that your customers can handle and use themselves. For services, they’re the means by which customers communicate with you; the schedules and processes you follow to meet your customers’ needs; the rigor you apply when you solve your customers’ problems. Whether product or service, features are normally things that are measurable and demonstrable.

Clarifying benefits

Features are the what of your offer. But oddly, the whats don’t really convince customers to buy. Benefits — the so-whats — do, especially when you can enhance those benefits with your unique discriminators (something that we explore in more detail in the later section “Quantifying the value of benefits with discriminators”).

Benefits are the results that stem from applying features that solve customer problems. They describe the value that the customer can achieve from your solution to its problem. To claim a benefit, a feature of your offer must clearly allow the customer to realize the benefit — it’s a one-to-one relationship.

To continue with our SureGuard example from the preceding section, here’s the so-what:

Phone app: If you’re stuck in traffic and need to let visiting relatives into your house, you can disarm the alarm from your cellphone just before they arrive, and maintain your home’s security until they arrive.

Benefits help customers achieve their goals — goals that go beyond merely solving the problem — because they answer the question, “So what?” The example explains the practical benefit that the phone app’s feature supplies.

Benefit statements may be the hardest thing to write in a proposal. Many writers confuse them with features, or even with the new capabilities that result from using the features. Technical experts, who clearly understand the significance of features, have an especially hard time distinguishing the difference.

Take, for example, an engineer who claims that a product is made from 93 percent modular components. She may argue strongly that the modularity alone is a benefit. Actually, it’s a feature. It only enables a benefit, such as faster repair times and lower maintenance costs. For this reason, always ask someone who doesn’t have a technical understanding of your solution but does understand the customer’s perspective to evaluate your feature and benefit statements.

Consider the examples in Table 7-1 to help you make sense of the differences between features and benefits.

You must present your features–benefits as complementary — in parallel, in the same order — wherever you present them, whether side by side or in different sections of your proposal.

Applying the “so what?” test

When you look at the problem, pain, feature, and benefit statements side by side (refer to Table 7-1 for some examples), you see how the feature (usually written as nouns and noun phrases — for example, “encrypted transactions”) is the working element of the solution that solves the problem. You express features in terms of what they do (the what of your solution that speaks to technical evaluators). What makes features become meaningful to less technical evaluators is the benefit that combines the feature (for example, it encodes card numbers) with the business result that it enables (for example, that as a result, people can buy with confidence).

The benefit statements in Table 7-1 rely heavily on verbs. Verbs are words that answer the “so what?” question in your evaluator’s heads with actions (for example, “encodes … so they can buy …”), actively removing the customer’s pain as the feature solves the problem. The “so what?” benefit speaks to all the evaluators but especially the decision maker, because not only does the benefit solve the immediate problem, but it also implies a long-term benefit: that customers will keep on buying.

To make sure your benefits aren’t just reworded feature statements, ask yourself “so what?” after you read them. A feature statement won’t be able to answer the question, whereas a benefit statement will provide a clear answer by expressing the action that your feature performs and the results that the action achieves — which serves to address your customer’s specific problem or need.

To help customers select your offer, don’t rely on your benefits to be self-evident. Help customers draw conclusions about the value of your features with a features and benefits table. It can quickly highlight the advantages of choosing your organization based on the value you offer.

Quantifying the value of benefits with discriminators

To test whether your benefit statements truly express benefits and not just features, you ask “so what?” about each one. But to truly convince your customers of your features’ value, you need to couple the “so what?” with another question: “How well?” — that is, “How well does your benefit satisfy the customer’s most important needs?” The answer lies in discriminators.

A discriminator is a feature of your offer that the customer acknowledges as delivering a desired benefit — it quantifies the value of the feature to your customer. Proposal writers have names for the relative effectiveness of discriminators (they’re a little over the top like that). Key discriminators are those that the customer acknowledges as delivering important benefits. Weak discriminators are only distinct from a single competitor’s offer and not from the rest. Positive discriminators are benefits that only one bidder can rightfully claim; these benefits are significant enough to customers that they can justify awarding the bid to you on them alone (so positive discriminators are the ones you want!). Still, all discriminators are important — even weak ones show you in a positive light, and key discriminators can at least keep you in the running for the business because customers recognize them as important.

Well-written positive discriminators acknowledge the different roles that readers of the proposal will have and the different perspectives and motivations that each person brings to a collective decision.

Take, for example, one of the benefits from Table 7-1:

Encodes customers’ card numbers and other personal information so they can buy with confidence

Imagine that your encoding scheme is world-class, with secret-service-level security. No other competitor can compare. That will resonate deeply with technical evaluators, putting your solution at the top in their minds.

For their endorsement, you can therefore embellish your benefit statement:

Encodes customers’ card numbers and other personal information with the same technology used by government security agencies so customers can buy with confidence

Figure 7-1 shows where your customers’ needs, your competitors’ capabilities, and your own capabilities intersect — identifying the “sweet spot.” Positive discriminators lie in the single segment where you offer something that no one else does and where that something matters to the buyer. No other set of conditions fully qualifies as a discriminator.

Although customers base their buying decisions on benefits (both tangible, like a physical feature, and intangible, like a perceived capability), quantified benefits are more compelling than those that don’t deliver a measurable value proposition. But beware: You must also be able to prove the quantification claim. If you have no evidence that your encryption scheme doesn’t beat the competition’s hands-down, find another discriminator.

You want to quantify your benefits with discriminators whenever you can. They’re especially convincing if you can convey them graphically, but at the very least, consider adding them to as many of your benefits as possible.

Using past projects to back up your claims

Customers prefer organizations that can demonstrate both relevant experience in the work that they need to have done and a track record of successful past performance. A great way to provide evidence that you can do what you say is to cite examples of how you’ve done it in the past on projects with similar goals and of comparable size, scope, magnitude, and complexity. Your examples need to illustrate your work on successful projects that you delivered on time, within budget, and to customer specifications.

What parameters of past performance should you include? That depends on your customer’s needs. In complex procurements, you may be asked to provide detailed information about a range of categories, such as the following:

• Contract name, customer name, contact name and information
• Dollar value/contract type
• When you performed the work
• Project objectives and key solution deliverables
• How the customer benefited from your work
• Scope of work performed
• Locale of work performed
• Project performance

In less complex situations, you may need to provide a customer reference, with a name and number to contact for verification. Sometimes, a mere testimonial quote from a satisfied customer can solidify your claim.

If your prior customers don’t want you to quote them or to reveal details of your work with them, you may consider providing a case study that describes your performance on a previous project, using generic language for describing the actual customer.

Some customers may place greater importance on past performance than others. But no matter what the setting, clear descriptions of past performance can help build confidence in your solution and your ability to perform.

Making your proof persuasive

Proof points must be persuasive by substantiating the features and benefits that meet or exceed customer objectives and requirements. Here’s an example of a persuasive proof point:

We know that retaining staff is crucial for this project. Our retention rate across the company is 90 percent, compared to 82 percent industrywide for similar IT positions. On helpdesk projects such as this one, our retention rate is 98 percent, because we focus on leveraging Help Desk Institute certifications and best practice processes.

The details in this example help to persuade readers that your proofs are valid.

Avoid using general proof statements that fail to provide the customer with verification. Typical generic proof points include statements (that invite inevitable questions) such as these:

• We enjoy high levels of customer satisfaction. How high?
• We have low employee turnover. Compared to what?
• We offer relevant experience. In what?

Details persuade; generalizations come off as hedges at best and smokescreens at worst. So don’t write:

Some workers will realize productivity gains.

Instead, write:

Your 28 support staff clerks will reduce their filing and follow-up time by an average of 18 percent, or 1.4 hours per day.

The second statement is much more persuasive. So don’t spare the details when you’re describing your features, benefits, and discriminators.

Making your proof tangible

Proof points must be tangible. They must provide measurable facts and figures. For example:

Our company has delivered 24 software development projects for 13 customers over the past 5 years, all of which were performed at CMMI Level 3 or higher. We are able to staff your project by drawing on 25 ITIL Foundation certified IT personnel.

Your proof points must be detailed to be believable. But these details must also be accurate. Ensure that all your proof points contain specific numbers as opposed to estimates.

To demonstrate your organization’s size and strength, you can present data that shows your locations, divisions, subsidiaries, and programs/projects, preferably through graphics, charts, and tables. If you’re the prime contractor working with a partner, pull together the data that represents the combined entities (revenues, locations, employees, projects, certifications, and so on). Merely aggregating data is not effective, however. When you provide numbers, always explain to readers what they mean.

Table 7-2 provides an example to demonstrate how you can provide accurate proof points based on aggregated data.

As a result of the data in Table 7-2, you can make the following proof point statement:

Our combined service personnel outnumber our competitors’ by 2 to 1. Our combined service coverage places technicians within 25 miles of your branches, and our fleet can arrive for repairs within 30 minutes.

To provide further tangible evidence, focus your data on objectives met and results achieved. Tangible examples include dollars saved, percentage increases in efficiency, percentage increases in customer satisfaction, and decreased wait times.

Making your proof credible

Your proof points must be credible. They must provide verifiable information. For example:

We will meet or exceed performance expectations. For the past seven years, we have received the J.D. Power & Associates award for “Best Overall Satisfaction” and “Among the Best” ratings for Performance and Reliability.

Your discerning customer may want to verify your proof points, so make them tangible by identifying all data sources and providing specific customer references and quotes (ask for customer permission before using direct quotes).

Some potential sources for tangible proofs include

• Case studies reported by trade magazines and sources
• Citations of industry recognition of innovation or longevity
• Awards or ratings from external, unbiased third parties
• Published data that shows size or financial strength
• Comparisons to show that your solutions meet or exceed industry performance standards (which will also ghost the competition; refer to Chapter 5 for more on ghosting)

Whether small, medium, or large, all companies must develop proof points to substantiate their features, benefits, and discriminators. Without proof points, your proposal is incomplete. Customers won’t be able to verify your claims and will have no reason to believe them.