It's a Thursday afternoon and I'm staring at three documents that don't agree with each other.
The first is a pink team draft written by a team of subject matter experts (SMEs) against a solicitation that hadn't been released yet. That seems counterintuitive, but it's a common enough practice. The second is what happened to that draft after someone ran it through an AI tool without a clear prompt, a style guide, or any real understanding of what the document needed to accomplish (a huge mistake that I'll cover in another issue). The third is the actual solicitation, which dropped over the weekend while the second document was being created.
I have four days to produce something red-team ready.
This is not a story about AI. It's not even really a story about bad writing. It's a story about what happens when smart, capable, credentialed SMEs write proposals as if their job is to write a good proposal. It isn't.
The confusion starts with the assignment
When a proposal team asks you to write a section, they're not asking you to write an essay, a technical paper, or a white paper. They're asking you to answer a specific set of questions, in a specific order, within a specific page count, using language that maps to evaluation criteria you probably haven't read.
That's a lot to ask of anyone who hasn't done it before. And even if you have, without extensive training and experience in proposal development, it's genuinely difficult to do well. I'm acknowledging that fact not to knock on anyone's technical expertise, but to offer an honest accounting of what the task actually requires.
The pink team draft I inherited was somewhere around double the page count. Right away, I knew what the problem was. I've seen this dozens of times by now. Conventional wisdom would say that it's a writing problem. Someone was a bit verbose and mistook a "describe your process" direction from the solicitation to mean "give me your standard operating procedure." But conventional wisdom would be wrong. This is a scoping problem.
The SMEs who wrote it were working without the context to know that every word competes for space with every other word, and that page limits aren't suggestions. They wrote what they knew. They wrote it thoroughly. And then someone had to cut it in half, which meant making judgment calls about what mattered, without the domain expertise to make those calls well. That's how you get rewritten.
Your job and the proposal team's job are not the same job
The proposal team's job is to submit a compelling and compliant proposal. Your job is to help them do that. Those are different jobs, and that distinction matters.
Compelling and compliant means the proposal answers every requirement in the solicitation, scores well against the evaluation criteria, and fits within the constraints the government has set. It has to be technically accurate — that's the floor. But it doesn't have to go to the depth someone would need to actually execute the work. A proposal is not a technical manual. It has to walk a careful line between communicating expertise and approach, meeting compliance requirements, and giving evaluators something they can score. That line is the proposal team's job to define.
Which means your job is to write within the guardrails you've been given — not to figure out where those guardrails should be. A good proposal team will tell you explicitly what they need from you and what they don't. Your responsibility is to deliver within that scope.
The best SME contribution I've ever seen came back needing almost no changes. Not because it was brilliantly written, but because the SME talked to the proposal team first, understood exactly what the section needed to accomplish, and wrote to that target.
That's the goal. Not a good draft. A usable one.
Ask before you write
The most effective thing you can do before writing a single word is ask your proposal team three questions:
What does this section need to prove? Not describe, but prove. There's a difference between a section that explains your technical approach and a section that demonstrates why your technical approach reduces risk for the government and gives them the value they're looking for.
What are the page limits and format requirements? Get this information before you start. Writing without it creates rework for everyone downstream.
What does the solicitation want me to write? If your proposal team can share the relevant sections of the solicitation (e.g., the RFP, RFQ, SOW, or statement of objectives), read them. Your section will be scored against evaluation criteria. Writing without reading them is like answering a question you haven't heard.
These questions do not signal weakness. Instead, they signal you understand what you're there to do.
The gap between accurate and scoreable
The problem is domain-specific. Proposal writing has conventions, constraints, and objectives that aren't obvious from the outside. An SME who has never read an evaluation matrix has no way of knowing that the phrase they chose, while technically accurate and perfectly clear, doesn't map to the language the evaluator is looking for. Proposals have to be technically accurate, but technical accuracy alone doesn't win contracts. The evaluator scores against criteria, and that's the target the writing has to hit.
Ultimately, this is a perspective issue, not a performance issue. The SME who wrote the draft I inherited wasn't doing anything wrong by their own frame of reference. They were doing exactly what they'd been asked to do, without the context to know what "done" actually looked like from the proposal team's side of the table.
I've seen this enough times to know the problem isn't SME competence. The problem is that the ask is often wrong. SMEs get handed a blank document, a section title, and a deadline — and then everyone is surprised when the output doesn't fit. That's a process failure, not a people failure.
The conversation that should have happened first
I spent four days that week rebuilding something that should have taken half that time, maybe less. The expertise was there. The solution was there. What was missing was a conversation that should have happened before anyone opened a blank document.
If you're an SME who gets pulled into proposal support, the single most useful thing you can do is ask for that conversation before you start writing. Not because you don't know your domain. You know it better than me and everyone on the proposal side of this equation. That's why we need you. But the proposal team knows something you don't: what the customer is actually evaluating, and what it takes to win.
That's the collaboration a good proposal development process is supposed to produce. When it works, it's because both sides showed up for it.
The Proposal Stack publishes biweekly for technical GovCon professionals. If this was useful, forward it to someone who's about to write their first proposal section.