Here is this episode's question: when your proposal describes what you offer, does the customer see why that matters to them, and why only you can deliver it?
Most proposals answer the first half and stop. They list capabilities, products, certifications and years of experience, and leave the evaluator to work out the value. The APMP Body of Knowledge puts the fix in three words. Features are what you offer. Benefits are what the customer gains from them. Discriminators are the benefits that matter to the customer and that no other bidder can match. Customers buy benefits, and discriminators are what make them choose yours.
This series works through the APMP Body of Knowledge as summarized in the APMP Foundation Study Guide. This competency sits under Focus on the Customer, and it is the raw material for the theme statements, value propositions and win themes covered elsewhere in the series.
Three words, three questions
The Study Guide offers a compact way to tell the three apart, and it is worth memorizing because it doubles as an editing tool:
| Term | Question it answers | Whose language | Example |
|---|---|---|---|
| Feature | What? What do we have or do? | Ours: specs, tools, processes, staff | "A monitoring center staffed around the clock" |
| Benefit | So what? What gets better for the customer? | The customer's: cost, time, risk, results | "Problems are caught before users notice, so service interruptions shrink" |
| Discriminator | Why us? Why only us, and why should the customer care? | The customer's, compared with every rival | "Only bidder already monitoring this customer's network type, so coverage starts on day one rather than after a learning period" |
Put simply, a feature is a description, a benefit is value, and a discriminator is a reason to choose. A proposal needs all three, but evaluators award points mostly for the last two.
One clarification that the Body of Knowledge makes clear: you are not being told to stop writing about features. Features are how you deliver a benefit, and evaluators need them to believe it. The problem is stopping at the feature and leaving the customer to draw the line to their own problem. Many organizations do exactly that.
Why proposals stall at features
Proposal writers naturally start from the seller's view. They know the product, the method and the team, so those come to mind first. The evaluator reads from the opposite side, with one question running in the background: what does this do for us?
Seller's view (feature)
"We provide a 24/7 monitoring system."
True, and still unfinished. The evaluator has to guess why it matters.
Customer's view (benefit)
"With monitoring around the clock, your team sees warning signs early and service interruptions get shorter."
Same feature, now tied to an outcome the customer wants.
Three groups find this switch especially hard, according to the Body of Knowledge:
- Technical contributors and subject matter experts. They understand exactly why a feature is impressive, so it feels like a benefit to them. To an evaluator it is still a specification.
- Incumbents. After years on a contract, they can assume they know what the customer "really" wants, even when that differs from what the customer has asked for this time.
- Anyone writing about their own company. Every team overrates its own strengths. That is human, and it is exactly why the customer's view has to be checked rather than assumed.
Start from the customer's needs
A benefit is not whatever you think is good about your offer. It is value the customer recognizes as solving its own problem. That is why the Body of Knowledge begins this topic with understanding the customer, through the sales or opportunity process, long before the writing starts.
When you pursue an opportunity, you are assuming that your capabilities fit the customer's needs. The Study Guide's advice is to check that assumption rather than trust it. A simple version of the process looks like this:
- Learn the needs before you write. Meet the customer and find out what it is trying to fix or achieve.
- Map your features to those needs. Work out which of your features, and the advantages they create, could solve each one.
- Test your ideas with the customer. Share possible solutions and see which ones the customer finds valuable.
- Turn confirmed advantages into benefits. What the customer has confirmed goes into the written offer as a benefit, for example in a feature/benefit table.
- Compare with competitors. Set your benefits against what rivals are likely to offer to see which ones are discriminators.
Know why each requirement is there
The Body of Knowledge adds a point that is easy to skip: knowing what the requirements say is not enough. You also need to know why the customer put them in.
Imagine an RFP that asks for "real-time monitoring." That is the what. The why could be that outages were spotted late last year, that operators learned about problems from complaints, or that a service went down twice during peak season. Each reason leads to a different benefit, and only one of them is the benefit this customer is buying. Your monitoring feature is the same in every case; the sentence that wins points is not.
Feature, advantage, benefit
A three-column table makes the translation visible, and it is a quick way to catch statements that are still stuck at the feature stage. Here is an example written for this article, for a document-processing solution:
| Feature (what we have) | Advantage (what it does) | Customer benefit (what improves for them) |
|---|---|---|
| Automatic classification engine | Removes repetitive manual sorting | Staff spend less time per case and clear the backlog sooner |
| Standard templates | Every document follows the same structure | Reviewers find the key information faster and approvals take fewer rounds |
| Links from each statement to its source | Anyone can trace where content came from | Lower audit risk and less time spent on corrections |
The first column is internal language. The last column is the customer's language. If a sentence in your draft only fits in the first column, it is not finished.
Finding your discriminators
Turning features into benefits is half the job. The other half is working out which benefits make you the better choice, and that cannot be done by looking at yourself alone. You have to compare.
Compare honestly, from the customer's side
To find discriminators, you need intelligence about the customer's needs and about how competitors are likely to answer them. It can come from your capture or sales team or from outside consultants; either way, the Body of Knowledge asks you to analyze it carefully. Effective intelligence answers who is likely to bid, what they will offer and at what price, and most importantly how the customer views them.
A bidder comparison matrix then rates every significant bidder, you included, against what each requirement asks for and the reason it was included. The rule that makes it useful is uncomfortable: score as the customer would, not as you would. Teams that rate themselves generously end up with top marks everywhere and miss the places where their solution needs work. A SWOT analysis of each bidder adds context the matrix may miss, such as leadership changes, legal disputes or merger rumors. Competitor weaknesses become your opportunities and their strengths become your threats. (EP05, Customer and Competitor Intelligence, covers both tools in detail.)
The sweet spot
The Study Guide pictures discriminators as overlapping areas: customer needs, competitors' capabilities and your own. A discriminator lives in one segment only, where you offer something the customer cares about and nobody else does. No other combination fully qualifies.
Reading the other segments is just as useful when you plan the proposal. This table is a way of applying the idea, written for this article:
| Customer needs it? | You offer it? | Competitors offer it? | What it is | What to do in the proposal |
|---|---|---|---|---|
| Yes | Yes | No | Discriminator | Lead with it, quantify it, prove it |
| Yes | Yes | Yes | Table stakes | Show compliance briefly, or build a unique benefit around it |
| Yes | No | Yes | Gap | Close it with partners or a solution change, or neutralize it |
| No | Yes | Either | Feature without a buyer | Cut it or keep it short; it earns no points |
The second row deserves a closer look. When you and a competitor share a feature, the Body of Knowledge notes you can still make it a discriminator by wrapping it in a benefit only you provide. Two bidders may both run a help desk; only one may staff it with engineers who already know this customer's systems, so tickets are solved on the first call.
Brand, size and experience are not discriminators by default
The most common mistake here is trusting your own name. Nobody else can put your logo on a solution, but that does not make the logo a benefit. The same goes for headcount, office locations, defined processes, products and years of experience. Each is a feature that has to be tested before it counts as a benefit, let alone a discriminator.
Past performance shows the right move. A list of similar projects mainly supports your claims. Its benefit is what you learned from them: the shortcuts, the risks you now avoid, the checklists you built. Explain how those lessons let you deliver this customer's requirements faster, better, more safely or at lower cost, and experience starts to work as a benefit.
Quantify the value, and be able to prove it
A measured benefit beats an adjective. Compare two claims, written for this article, from a facilities maintenance bid:
Vague
"We provide fast support."
Fast compared with what? Every bidder will say the same.
Measured
"An engineer is on site within two hours, any time of day."
The customer can picture it, compare it and hold you to it.
The Body of Knowledge makes the same point about a common theme statement, "a safe pair of hands." It is trying to say low risk, but it is impossible to measure. To make it work, name the specific benefit and attach evidence and a number. For example, a bidder whose real promise is reliable schedules might write something like this (figures invented for illustration):
"You can count on go-live on the agreed date: our last 18 migrations of this kind all went live on schedule, and the cutover runbook we refined across them has cut weekend downtime by a third."
That sentence has a specific benefit, evidence behind it, and a number the customer can check.
Three cautions keep quantification honest:
- Only use numbers you can prove. A figure you cannot back up is worse than none: once an evaluator doubts one claim, every other claim gets a discount too.
- Expect to be held to them. When the resulting contract is performance-based, quantified benefits can become the metrics you are measured against. Quantify throughout, with evidence, and make sure delivery can meet them.
- When you can't measure, connect. Not every benefit has a number. Then tie it to the customer's mission or stated goals, and describe it in the customer's own words. Using their language shows you understand what they need.
Apply the So what? test
The simplest tool in this topic is also the most useful. After every sentence you intend as a benefit, ask "So what?" as the customer would. A feature statement has no answer. A benefit statement answers it by naming a customer problem solved or a result gained.
Run it as a chain until you reach something the customer cares about. Here is an example written for this article:
- "Our platform includes 120 ready-made connectors." So what?
- "Your existing systems can be connected without custom development." So what?
- "Integration takes weeks instead of months, so your new service launches before the budget year closes."
The first line is a feature. The third is a benefit this customer would pay for, and if no competitor can match the timeline, it is a discriminator.
Who applies the test matters. The person who designed a feature is the least able to judge whether it reads as a benefit. The Body of Knowledge suggests asking someone who understands the customer's perspective but not the technical detail. Your goal is benefits so clear that the customer never has to draw its own conclusions about what your features are worth.
Checklist for your next proposal
- List the customer's needs first, including why each key requirement is in the RFP.
- Build a feature / advantage / benefit table for your main solution elements.
- Test likely benefits with the customer before the RFP if you can, and keep the ones it confirms.
- Score all bidders from the customer's view in a comparison matrix, and be honest about your gaps.
- Mark your sweet spot: needs you meet that no rival can. Lead with those.
- Challenge brand, size and experience claims. Rewrite each as what it changes for this customer.
- Quantify where you can prove it, and tie the rest to the customer's mission in its own words.
- Run the So what? test with a reviewer who knows the customer better than the technology.
Where Contrl fits
The point of this episode is that a feature only earns points once it has been turned into a benefit the customer values and a reason that only you can deliver it. In Contrl, that translation happens before any slide is written. In the strategy interview you describe the client, your company and the competition, and each proposed win theme spells out the client need, your edge over the rivals and the benefit to the client, so a feature you mention has to show up as a "so what" and a "why us." The theme you pick is reduced into a key sentence for every section, which keeps the benefit, not the feature list, at the front of each page.
Next in the series
Once you claim a benefit and a discriminator, every evaluator asks the same thing: how do we know it's true? Episode 10 covers Proof Points: what evidence makes your claims believable, and where to put it in the proposal.
This article is an independent study companion based on the APMP Foundation Study Guide, version 4.2 (© 2025 APMP), which summarizes the APMP Body of Knowledge. It paraphrases and comments on that material and is not endorsed by APMP. The monitoring and help-desk sentences, the document-processing table, the four-segment table, the support-time comparison, the migration statement and the connector example, including all figures in them, were written for this article. For the authoritative text and certification information, see apmp.org.