How to use features and benefits tables to enhance your proposals

People sometimes struggle with addressing benefits when they write proposal copy. They stumble over what words to use and how to say things. One way to overcome this is to do away with most of the words. With a features and benefits table you focus on the key items and not sentence construction. And because they are visual and less wordy, they are friendly to the proposal evaluator as well. 

A features and benefits table itemizes the key elements of your approach or offering, and turns them into reasons why the customer should select your proposal. At first glance, they appear to be simple. They can consist of just two columns, one for the features and one for the benefits. All you have to do is list your features and then write a corresponding benefit to the customer for each. Sounds easy, doesn’t it?

It sounds easy until you try it. At some point when writing your benefits, you’ll start to realize that they sound like features. Or vice versa. And how many features should you list? How granular should they be? Should you add other columns? Should it be "Issues, Features, Benefits, Proof?" Should you include RFP references? Behind their deceptively simple appearance, features and benefits tables can lead to mind-numbing confusion.

Just simply deciding whether something is a "feature" or a "benefit" can be challenging. So before you hurt your brain over whether something should go in the features or benefits column:

• Start by defining what a “feature” is. Features are attributes of your offering. They are typically the things you do or offer to fulfill the customer's requirements. The best features are also differentiators, or things that no one else is likely to do or offer.
• Then define what a “benefit” is. A benefit in a proposal is what the customer gets as a result of the feature. While customers need to have their requirements met, the reason they issue a procurement is because they are seeking certain benefits. Once the requirements are met, they make their decision based on the benefits. If the word benefit troubles you, then think about what the impact of a feature will be or why it matters. Why does your approach or offering include that feature in the first place?

Note that some things can be both a feature and a benefit. Speed is an example of something that can be a feature or a benefit. A new computer may have a faster processor. The new processor is a feature with the benefit being that your computer will be faster. But a faster process can also be a feature, with the benefit being that you’ll be more productive. What you include as a feature is less important than that the benefit, impact, or reason why it matters and is compelling to the evaluator.

What best determines whether something should be a feature or a benefit is whether it is a requirement or whether it is a result that makes your offering better than your competitors’ offerings. Customers make their decisions based on what an offering will do for them. When they shop for features, it is because they know those features will meet their needs. If something fulfills a customer need, you should explain how or why in the benefits column. To make the right decision you have to understand the customer’s needs. It helps when you are responding to an RFP with written evaluation criteria.

In the example above, if the customer is buying a computer and making their selection based on the specifications, then the speed goes in the benefits column because that is what the customer is looking for. If they are seeking to improve their overall systems and your approach might be better because it’s faster (making it a feature), then what the customer will get out of it is improved productivity (the benefit that is the reason they are interested in a new system).

In addition to the basic two-column approach, there are other ways to format a “features and benefits” table. And sometimes, they make it easier to understand what goes in each column.

• Reasons to Select Us/Features of Our Offering. There’s no reason why you should limit yourself to the words “features” and “benefits.” You could also substitute words like “Results” or “Benefits to You.”
• Features/Advantages/Benefits/Proof. A feature is the attribute, an advantage is what it does, benefit is what the customer gets out of it, and proof is how you substantiate that.
• Requirements/Features/Benefits. You can include RFP references in the table to demonstrate compliance. This helps link your features and benefits to the RFP, making things easier for the RFP evaluator. It can also help make evaluating RFP compliance as simple as a checklist. You can even expand this one to be Requirement/Features/Benefits/Evaluation Criteria, to show the customer that you are not only compliant, but deserve to receive the best score according to their own criteria.

Features and benefits tables (in whatever variation you choose) work best for proposals where you determine what to offer. If you are bidding a solution or a design, then features and benefits tables can make it easy to see the key aspects of what you are proposing and why they matter.

However, when the customer tells you exactly what to propose and is seeking to compare apples to apples, the primary difference between bids tends to be price. However, if there are important differences between you and your competitors, such as in how you will deliver what the customer is asking for, then a features and benefits table can help call out the differences and why they should impact the customer’s selection.

In some proposals, you might only have one features and benefits table, typically at the beginning. In others, you might have one in every section. Where you use them, or how often, should depend on what the customer has asked for in each section. If a section contains multiple features or presents multiple reasons why they should select you, a features and benefits table can help summarize them. If you have multiple features and benefits tables, you may need to establish a hierarchy and have high-level features identified in the introduction, with each item expanded into multiple more detailed items in each section.

In the end, features and benefits tables become more of a thinking and presentation tool than something to make things easier. They help you puzzle through figuring out what you have to offer and what the customer will get out of it by focusing your thoughts like a laser. You can even use them as a pre-writing tool, then convert them to a narrative response and throw away the table. As a presentation tool they help summarize and make things stand out.

What you want to avoid is having a features and benefits table just because you think you’re supposed to. If you load it up with unsubstantiated claims, or make RFP compliance the primary benefit, then what stands out is that you are not competitive. When in doubt, focus on differentiators, and don't forget the proof points.

When you use them regularly, features and benefits tables end up being something that reinforces the importance of everything you do before you start the proposal. If you are having trouble completing your features and benefits tables, it’s a good indicator that you started the proposal unprepared. When this is the case, features and benefits tables can be used to drive recognition in your company about what information needs to be brought to the start of a proposal. The deceptively simple features and benefits table can become a tool of change management and process adoption.