Subject matter experts (SMEs) are necessary to almost every proposal. They are the ones who design and build the product (or provide the service).
They most likely work on contract for your customer, so they know what to do, how to do it, when and where to do it, and who is responsible for it. They can provide lessons learned to improve your methodology, identify reasonable quality metrics and measurements, and make recommendations for continuous process improvements. SMEs often know the real decision makers and have insight into their preferences.
What they likely can’t do, though, is write effectively for your proposal. Here are two reasons for that:
1) Because of their deep product knowledge, SMEs “know too much.”
They know there is no simple answer; everything depends on the customer environment, system configurations, SLAs, other vendors involved, and so on. They often struggle to respond only to what the RFP requires.
2) SMEs may not actually write frequently, but if they do, it’s probably in a style very different from what proposals require.
For example, user manuals are dry, short, and to the point, providing precise, logically organized instructions. Technical specifications are heavy on jargon and metrics with little prose. Conversely, scientific and research papers provide heavily detailed theories, methodologies, rationales, and results leading up to conclusions.
These experts are ill prepared to work within a stringent compliance-driven proposal outline, which makes a hash of any lengthy technical discussion and imposes ridiculous page limits. Closely related material may defy logical order and be split into multiple sections, with seemingly unrelated material stuck in the middle. Asking your SME to learn to write in this fashion will be frustrating at best, and is not the best use of his time or expertise.
Still, there is another, even more germane reason not to task SMEs with writing proposal responses: a proposal is not a technical document. It is a customer-oriented response to specific requirements. SOWs and SLAs and technical volumes notwithstanding, a proposal must above all persuade the evaluator that your solution is the best combination of not only technical, but also management, security, customer support, cost, and other factors.
Precisely because SMEs are experts on product design, features and benefits, they write from that perspective. They often “push their product across the table,” trying to sell what they already have. Proposals, meanwhile, are all about solving the customer’s problem. The product is merely part of the solution, and may need substantial modifications to meet requirements. A well written proposal inspires the customer to “pull the solution to their side of the table.”
So how do you get the most value from your SMEs?
Bring in a seasoned proposal writer to turn your SME’s data into “proposalese.” Proposal writers start with the RFP requirements to understand what the proposal must provide. They absorb or even help develop win themes, discriminators, and value propositions. Then they work with the SMEs through interviews, Q&A sessions, and read/review/edit cycles, to craft a compliant, compelling response to the convoluted RFP requirements.
So what is “proposal style” writing, and why does it require dedicated proposal writers?
Essentially, it’s very much like what I learned a lifetime ago in Journalism 101. In that class the basic assumptions were:
- Few people read past the headlines
- Even fewer people read past the third paragraph
- Only diehards ever read to the end
To satisfy a newspaper audience then, a journalist must put the most important points up front. Backup data comes later. Think of a triangle, point down, or a funnel: at the top, the broadest point, is where your conclusion goes – the most important material that you want the reader to remember. After that come the proof points or substantiation for those who continue reading. Additional details and background information follow, to satisfy the diehards who want the whole story.
This is pretty much exactly what you need to do in proposals: assume the audience (evaluator) will spend very little time with your proposal, so put all the most important information right up front so the evaluator can find it with little effort. Proof points, like references to similar successful efforts, should follow, as validation for your approach. Extensive details can bolster your argument, especially when summarized effectively with a features/benefits table or similar device to reinforce your solution.