Writing Winning Proposals

A request for proposal response is a persuasion document disguised as a compliance exercise and most proposal teams write it as if only the compliance half matters. They answer every question the buyer asked, in the order the buyer asked it and assume thoroughness will carry the argument. Evaluators read differently. They skim for a recommendation, check whether the vendor understood the actual problem and look for evidence before they look for enthusiasm. Consulting firms have spent decades refining how to write for exactly that kind of reader, distilling the discipline into a handful of structural tools: state the conclusion first, organize the narrative around a specific complication rather than a generic pitch, anchor every claim in verifiable proof and let the executive summary carry the whole argument in miniature. None of these tools require new content. They require reorganizing content that most proposal teams already have, so the structure itself does persuasive work the prose alone cannot.

The pyramid principle: answer first, then prove it

Barbara Minto developed the pyramid principle during her years at McKinsey, where she noticed that reports crossing her desk consistently buried their conclusions under pages of analysis the reader had to wade through before reaching the point.1 Her fix, still taught at nearly every major consulting firm, is to state the answer at the top, group the supporting arguments beneath it into logically distinct clusters and let evidence sit at the base, available but not blocking the reader's path to the conclusion. Applied to an RFP response, this means the opening pages should tell the evaluator what the vendor recommends and why, not what the vendor is or how long it has existed. Minto herself described the underlying discipline this way.

The pyramid is a tool to help you find out what you think

That framing matters because a proposal built pyramid-first forces the writing team to know its own argument before drafting begins, rather than discovering it somewhere around page nine. Sections that follow the recommendation should each answer a single question a skeptical evaluator would ask next, staffing depth, delivery risk, cost justification, in an order that mirrors how the evaluator's doubts actually accumulate. A proposal organized this way reads as a chain of reasoning rather than a stack of independently written sections, which is usually the difference an evaluation committee notices without being able to name it.

Situation, complication, resolution as the narrative spine

Where the pyramid principle governs how an argument is structured, situation-complication-resolution governs how it is told. The situation establishes facts the buyer already accepts about its own circumstances, the complication names the specific obstacle standing between the buyer and its stated goal and the resolution positions the vendor's proposed approach as the direct answer to that named obstacle, not a generic capability overview. The discipline forces specificity. A vendor cannot write a compelling complication paragraph without having done the diagnostic work to understand what is actually blocking the buyer, which is precisely the work many proposal teams skip because it is easier to describe products than to diagnose problems.

Buyers reward that diagnostic work more than proposal teams often assume. Forrester's 2026 research on business buying found that the typical purchasing decision now involves thirteen internal stakeholders and nine external influencers, a buying group large enough that a proposal failing to articulate a shared, specific problem statement gives that group nothing to rally around internally.2 A situation-complication-resolution narrative gives that group a shared vocabulary, the complication statement, that internal champions can repeat to colleagues who never read the full document. That repeatability, more than any single turn of phrase, is what makes the narrative structure earn its keep across a long, multi-stakeholder evaluation process rather than only on first read.

Win themes that survive contact with an evaluator

A win theme links a specific vendor strength to a specific buyer priority, expressed as a benefit rather than a feature and backed by proof strong enough that an evaluator cannot dismiss it as marketing language. The Association of Proposal Management Professionals recommends limiting a pursuit to three to five win themes, developed by identifying buyer priorities, restating them in positive language and attaching quantified evidence before drafting begins rather than after.3 The discipline of limiting the count matters as much as the themes themselves. Proposal teams under deadline pressure tend to accumulate claims, adding a new differentiator every time a subject matter expert contributes a section, until the document argues a dozen loosely related points instead of five sharp ones an evaluator can actually remember.

The strongest win themes also survive translation across sections. A theme built around implementation speed should appear, in consistent language, in the technical approach, the staffing plan and the pricing rationale, not as three unrelated claims that happen to touch on similar ground. This is where many proposals fragment: technical writers, pricing analysts and staffing leads draft their sections independently, each introducing their own framing of the vendor's strengths, so the evaluator receives what reads like three different vendors' answers stitched into one document. A proposal manager who enforces theme consistency across every contributor is doing structural work that no amount of individual section quality can substitute for.

Proof points: turning claims into evidence

A win theme without proof is an assertion and evaluators are trained to discount assertions. Proof points, drawn from past performance data, customer references, quantified results and independent ratings, give the evaluator verifiable evidence that a claimed benefit is achievable rather than aspirational. The proposal body of knowledge maintained by proposal management practitioners is explicit that proof points must be specific and tangible rather than generic: a claim of high customer satisfaction means little without a number, a comparison to an industry benchmark and a source the evaluator can trace back if challenged.4 Vague claims like strong retention or extensive experience invite exactly the follow-up question a proposal team wants to avoid during oral presentations.

Gathering strong proof points cannot happen the week the RFP drops. It requires a standing repository of quantified past-performance data, references willing to speak on short notice and case examples mapped against the categories of claims a proposal team is likely to make, staffing depth, delivery speed, cost discipline and industry-specific outcomes among them. Where a genuinely public, named case is unavailable, a proposal team is better served by framing an illustrative scenario honestly as illustrative rather than dressing up an unverifiable anecdote as a named client result, since an evaluator who catches an inflated claim during due diligence discounts everything else in the document that follows.

The executive summary as the whole proposal in miniature

An executive summary that merely previews the document's structure wastes the section evaluators are most likely to read closely and least likely to revisit. Harvard Business Review's guidance on business writing puts the underlying discipline plainly: readers need the essential point within the first several dozen words, because a document does not generate any outcome until its audience understands the message being sent to them.5 Applied to an RFP response, the executive summary should contain the recommendation, the two or three reasons it is correct and enough concrete evidence that a reader who stopped there would still understand why the vendor is the right choice, not merely what topics the following pages will cover.

Consider an illustrative scenario: a mid-sized professional services firm responding to a technology modernization RFP drafts its executive summary as a two-paragraph history of the company followed by a bullet list of service lines. An evaluator skimming forty such summaries across competing bids retains none of it, because nothing in those two paragraphs answers the buyer's actual question. A rewritten version, opening instead with the specific recommendation, a phased modernization sequenced around the buyer's stated risk tolerance, backed by two quantified proof points, gives the same evaluator something to remember and repeat to colleagues who never read past page two. The content available to both versions was identical; only the structural discipline differed.

Structuring the RFP response body around the buyer's decision

Once the executive summary carries the core argument, the body exists to satisfy compliance requirements without losing the narrative thread established above it. This is where consulting-style structure diverges most sharply from a conventional RFP outline. Rather than organizing sections strictly by the buyer's question numbering, a well-structured response uses section headings that state a conclusion, an approach borrowed from the "action title" convention consulting firms use in client presentations, so a reader scanning only the headings still follows the full argument. A section titled Staffing Approach tells the reader nothing; a section titled Dedicated senior staff reduces implementation risk from week one states the point the section exists to prove.

Cross-references between sections reinforce this discipline further. When the technical approach references the specific staffing commitment made two sections later and the pricing rationale explicitly ties back to the complication named in the opening narrative, the evaluator experiences the proposal as a single coherent argument rather than a collection of independently authored chapters. Achieving that coherence requires a proposal manager with the authority to edit contributed sections for consistency, not merely to compile them, which is an organizational commitment many proposal teams underinvest in relative to the writing effort itself.

Common structural failures that sink good proposals

Even proposals with strong underlying content routinely fail on structure in predictable ways. Leading with a company overview instead of a recommendation delays the evaluator's understanding of the vendor's actual position until well into the document, by which point first impressions have already formed. Restating the RFP requirements verbatim before addressing them wastes space an evaluator expects the vendor to use for differentiation, not repetition of a document the evaluator wrote. Win themes introduced inconsistently across sections dilute the argument the proposal manager worked to sharpen during planning, leaving the evaluator with a blurred sense of what actually distinguishes the vendor.

The remedy for all three failures is the same discipline applied earlier in the process: agree on the recommendation, the complication it resolves and the three to five themes that prove it, before any section gets drafted and hold every contributor to that structure during review. Proposal teams that treat this planning phase as optional, moving directly to drafting because the deadline is tight, consistently produce documents that are individually well written and collectively incoherent, which is the exact failure mode a consulting-style structure exists to prevent.

• 1Barbara Minto: MECE, I invented it, so I get to say how to pronounce it
• 2Forrester's 2026 buyer insights: genAI is upending B2B buying
• 3Developing proposal win themes
• 4Proof points
• 5How to take your business writing from average to great