From last week's post, you probably took away that the proposal theme (see The Proposal Theme: A Rhetorical Infrastructure for Selling) is not just some fluff language. It is a necessary construct that gives writers a map to coherently address topics and concepts throughout their proposals. So, next time people roll their eyes when you start underscoring the importance of being 'on theme', just know that you are absolutely correct in stressing the point; don't worry about other people's opinions regarding this. They only have half the understanding you do - OK, I feel like being generous - of how proposals really work.

So this week, I want to cover another topic that people around you seem to grasp at a gut level but have difficulty weaving into their contributions to proposals. I want to discuss hot buttons.

Hot buttons are those things that keep your customers up at night. They are the reasons why your customers are putting work out to bid; these are problems they are trying to solve with your solution. Don't confuse these with SOW requirements. For example, training may be a requirement, but it isn't usually the need for training that drives procurement or keeps people up at night. Hot buttons may not even be explicitly stated in the solicitation. Sometimes, it's the kind of thing your customer would have trouble admitting, in writing for example, that it takes 24 hours to close high priority trouble tickets or the tools we bought last time where based on the imperial measurement system as opposed to the metric system.

Hot buttons should be presented in the executive summary and should be the refrain of your proposal. They can be anywhere between 2 and 7 in number and should be easily described in sound bite format e.g. write tight code without incurring outsized cost. The refrain should be repeated throughout the response and in support of particular points you are trying to make. So, with the "write tight code without incurring outsized cost" hot button, a point about code management could read something like this. "We propose to reuse code to the maximum extent possible. Our primary objective will be to keep developer time down while at the same time developing robust and resilient components. When architected this way, the components assure users a positive interaction with the application because of the speed of function execution. We propose to maintain a code library that has check out capabilities. This library will store the various modules that support the application. Using a modular construction of the application components assures that our code is reusable and that it executes its particular function efficiently."

Note two things about this paragraph. One, benefits are discussed first; features second. Two, and to remain on the theme of this week's topic, the hot button is not explicitly stated. If you read between the lines, the sentences scream out 'write tight code without incurring outsized cost!' So, hot buttons are used to support the discussion of your points and demonstrate that you understand the motivation behind the procurement. Hot buttons are the drivers of the procurement, and you want to let your customer know how your approach solves the problems or derives the benefits that are tied to them. As people read various sections, and you tie these in to the hot buttons, they should be thinking "these people get it."