How to Read an RFP

Most proposal teams read an RFP as a checklist: requirements, evaluation criteria, submission instructions, deadline. This is the most expensive possible way to read it. An RFP is not a neutral document. It was written by someone who had a problem, who had opinions about how that problem should be solved, and who chose specific language to describe both. Every word is a signal.

The team that reads the RFP as a text to be decoded — not merely a checklist to be satisfied — writes the response that wins.

1. Read for Incumbent Signals RFPs written to favor an incumbent vendor are the most common form of a rigged competition, and they are usually obvious in retrospect. Signals: overly specific technical requirements that match one vendor's architecture, evaluation criteria that weight experience with specific proprietary tools, impossibly short timelines that only a vendor already familiar with the environment could meet. If you see these signals and cannot neutralize them, the bid is not worth pursuing. If you can neutralize them — by demonstrating equivalent capability on different architecture — you have identified your competitive opening.
2. Read the Evaluation Criteria as a Weighting System The evaluation criteria tell you exactly how to allocate your writing effort. If technical approach is worth 35 points and price is worth 20 points, your proposal should proportionally invest more craft in the technical section than the pricing section. If "demonstrated experience with regulated industries" is a weighted criterion, that case study you were going to put in an appendix belongs in the body. Read the criteria and allocate your prose accordingly.
3. Read the Questions for What They Do Not Ask RFP questions are often drafted to prevent the issuer from showing favoritism — they are designed to be neutral. The signal is in what they choose to ask and what they choose to omit. An RFP that asks detailed questions about implementation methodology but no questions about change management is telling you something about where the issuer's expertise and anxiety lies. A response that addresses the unasked questions — where other respondents do not — signals that you understand the problem more completely than anyone who only answered what was asked.
4. Read the Background Section as Discovery Notes The background section is the issuer's self-diagnosis. Read it as you would read a prospect's discovery answers: what do they say the problem is, what have they already tried, what did they learn, and what do they want the solution to look like? If the background section says "our previous implementation was delayed by integration complexity," your response should address integration complexity specifically — not in an appendix, but prominently, with evidence that you have managed exactly that failure mode before.