Writing to Win: How Strong Proposal Teams Set Writers Up for Success

Hello everyone. Welcome. Welcome to our Office Hours series and today’s session, “Writing: How Strong Teams Set Writers Up for Success.” So today is not really a session about better writing. It’s about everything that happens before the first sentence gets written. Because when a first draft comes back either generic, unfocused, or difficult to review, the instinct is often to look at the writer and what they put in. But a lot of what determines the quality of that draft was decided before the writer even opened up the document. So today I want to look at what strong teams are giving writers before they start drafting, how that can change the review process, and where technology can make that a bit more consistent. Rather than talk about this only in theory, I want to make sure, with all of these sessions, that we follow an example and I give you some actionable takeaways. So today we’re going to follow one section from a thin assignment all the way through to a draft of higher quality. Before I jump in, I want to welcome everybody. If you’ve come to our sessions or registered before, welcome back. If you’re new, welcome for the first time. We hold these office hour sessions every other Thursday. We cover a mix of topics. We talk about process, we talk about technology, we talk about the industry, and of course, we talk about VisibleThread at times. But with every session, we try to give you information that you can take away, apply, and use to improve or optimize your processes. Just to give you a preview of what’s coming up (sorry, I skipped over this), it’s every other Thursday, thirty minutes, with live Q&A, and always free replays afterward. You’ll get the slides and a recording as well. As a preview, VisibleThread 7.3 will be our next session, in two weeks. We have a big release coming up for the platform, and we’re going to dive into ownership, task workflows, new dashboards, and some of the collaborative elements of that. There are some really exciting things there. After that, we’re talking about value from review gates: habits and workflows for teams whose reviews are really working for them, and then building compliance and clarity into the first draft. So we’ll be talking about moving compliance, clarity, and consistency checks into the first draft and how we can improve on that. We’ll also be doing some product showcases. We’re going to do one today. In every session we have a five-minute video; today’s is less than four minutes, three and a half minutes, highlighting a feature that’s being promoted for the upcoming release. Just a sneak peek of what we’re up to. All that said, we’d love to connect on LinkedIn. You can register for the series if you haven’t, and we’d love to see you back. Today’s Topic So jumping into today’s topic, this is really the crux of the session. In this series I cover a lot of different topics, but it often circles back to process: workflow changes, repeatability, consistency, and so on. Ultimately we’re talking about how setting up the people downstream for success, and creating a feedback and review loop that really works, will benefit you long term. Let’s talk about how this shows up relative to today’s conversation. In this scenario, say a writer gets a thin assignment. The draft comes back generic, which is honestly the predictable outcome. A group of people get into review and start asking: where’s the strategy? Where’s the evidence? Why didn’t we say this? Why didn’t we structure it this way? And at the end of all of that, some of that blame often falls back on the writer. But if the writer never had the strategy or the evidence, and didn’t know what the section was supposed to prove, we’re asking the draft to solve problems that should have been solved upstream. This is why I think first-draft quality is better understood as a process outcome, not simply a writing outcome. That’s what we’re going to dive into. We’re going to look at five things: What the writer actually needs before drafting. Which standards are worth settling before the review starts. How we get that guidance to the contributor when they actually need it: how we communicate it effectively, and make sure it’s up to date and helpful. Where we separate deterministic work, AI-assisted work, and work that still depends heavily on human judgment. A small, practical version of some things you can try on your next proposal, not a huge process overhaul. One caveat before we dive in: this is a recommended model, not the only way to run things. Your organization may use different artifacts, review gates, and role names, and that’s fine. The decisions we’re making here matter more than the labels. I’ve used some “red team / pink team” labeling, so if that doesn’t match your process exactly, focus on the underlying decisions rather than the names. The Cycle Most Proposal Teams Recognize This is a cycle most proposal teams will recognize. The assignment comes in thin (outline, page count, and a due date), and the writer has to fill the missing context, usually with reusable content. That’s usually the safest starting point, since it’s the information that’s available. Then the review becomes a discovery process: reviewers start supplying strategy, standards, missing evidence, and sometimes even solutioning, one comment at a time, and the section gets rewritten while you’re pushing up against deadlines. A lot of the time, that foundational gap is the reason we’re struggling at the end. The problem isn’t that the review happened; the review should happen. The problem is that the review becomes the first place where people clearly state what “good” is supposed to look like. If we move more of that information to the beginning, the review conversation changes: we stop using the review to give the assignment, and start using it to test the argument we’re making. Now, before we get into the process, I want to acknowledge reality. The target model looks very clean: the capture manager hands over customer intelligence, the proposal manager builds the compliance structure, the volume lead defines the argument, SMEs provide evidence, the writer writes, and reviewers evaluate; everything harmonious. That’s the PowerPoint version of proposal development. I understand everyone in the room has different processes and different challenges, so the actual bid may look a lot more chaotic: an RFP drops, everyone scrambles, the compliance matrix exists somewhere, SMEs get assigned, and writers begin discovering the solution while they’re drafting. Capture strategy exists, but it might not be in front of the right people at the right time. There are a lot of moving pieces, and I completely acknowledge that. Pink team becomes solution development and red team becomes rewriting. This session is really about those two stages and the space in between. I’m not assuming you already run the ideal version perfectly, or that you need to in order to be successful. The question is: can we change small things and improve incrementally? Not everything needs to be perfect, since I understand there are a lot of dependencies here. Three Common Gaps Underneath that space between where we are and where we’d like to be, I see three common themes most often when working with customers: Context. The writer doesn’t know what the customer cares about, how the section is being evaluated, or what the section needs to prove. That’s very different from knowing what needs to be done. The writer needs to understand why the customer cares, how we’re being evaluated, what’s most important, and what we’re trying to prove. Standards. Things like terminology, readability, tone, and claims are being decided during the review rather than before it. Depending on your tools, some of this can be automated, but you still need governance in place, and the information being sourced needs to be accurate. If this is manual, where does the information live, and how do people access it? How do we make sure contributors have what they need when they need it? Execution. The guidance may exist, but it’s not in front of the contributor. This ties back to the second point: how do we get people what they need, when they need it, and communicate it effectively? Those are the three main problems we’ll work through over the next several slides. A Concrete Example Now let’s make this concrete. I want to walk through one fictional section, so stick with me on this example. I know it might not be representative for everyone, but it’s a generic enough example to walk through the general ideas. Let’s use Section 3.2, Transition, for an infrastructure operations recompete. Here’s the assignment as the writer receives it: Section 3.2, Transition, six pages, draft due the 14th, pull from the last task order response. That’s not unusual, it’s a fairly typical assignment. But look at how many decisions the writer now has to make before they can even shape the content: How is the transition being scored? Which requirements belong in this section? What are we actually claiming? What evidence do we have? What can we say about incumbent risk? If none of that is available, what does the writer do? They open the last proposal. Now they’re adapting an old description instead of building an argument for this customer. So often, when we’re reusing boilerplate or transitioning themes from previous proposals, we end up with an updated version of an old approach, not necessarily our best shot at it. The draft that comes back ends up describing the transition rather than explaining why this transition is the lower-risk choice. We’re not getting to the “why,” which is the important part. And then drafting becomes a strategy conversation. A simple way to diagnose whether an assignment is ready: how much does the writer have to invent before they start? I’ll draw this comparison a few times, thinking about it the way you’d think about prompting an LLM. There’s been a lot of thought put into prompt engineering and the context you need to provide. We need to think about writer briefs the same way, giving the appropriate context and structure. What I’m seeing is that people put far more thought, structure, and resource material into prompting a generative system than they do when briefing a colleague. I don’t want to get too far off track, but I’ll circle back to that. The Section Brief When I talk about everything the writer needs to know, I’m calling it a “section brief.” Your organization may call it a storyboard, annotated outline, writer package, or content plan. The name isn’t what matters; what matters is what it conveys. However you translate that information to the writer, they need six things (maybe more, maybe fewer, but generally): How the section is scored. What it must contain, the requirements. The message or discriminator it needs to prove, the point of the section. The proof available, what evidence or proof points we’re using. The expected shape of the response: structure, headings, graphics, and what the final product should look like. The limits: claims we can’t make, content that belongs elsewhere, or specific items to avoid in this section. This doesn’t need to become another giant template. I don’t want this going down that road. One page can be a useful constraint; it doesn’t have to be a rule written in stone. Think about whatever structure you already use; this is the foundation you need for a much better first draft and a better starting point. The point isn’t to turn good writers into transcription machines, to hand them everything and expect no creativity. Senior writers should absolutely help shape the structure and sharpen the argument. Nothing here dictates exactly how they present it; it just gets everyone on the same page and removes avoidable guessing. The Same Assignment, With Context Let’s look at what happens when we attach that context. Say I’m working on Section 3.2, Transition, but I’ve been properly briefed. Same assignment, but now I know: Exactly what Section M is scoring: minimizing risk to continuity of operations during transition. The Section L requirements that belong here. Our argument: phased cutover reduces transition risk because no single event can interrupt operations. Our proof: 42 migrated services with zero unplanned outages on a comparable contract. The structure and the graphic. The boundaries. This is a completely different starting point than “here’s the section, here’s what to reference, here’s the due date, here’s the length.” Providing the source material gets you to a much more actionable draft. Some of this information may already exist somewhere on the team; some may not, and that’s actually useful to know. Some teams have a mature process where all of this is in one place and easily accessible. If we don’t have that, and we find a gap, for example, if I can’t fill in the proof section, I’ve found an evidence gap. If I can’t state the message, I’ve found a strategy gap. If I don’t know how we’re approaching a requirement, I’ve found a solution gap. So the section brief isn’t just a handoff to the writer, it’s a readiness diagnostic. If we can’t answer those six questions, the section may not be ready to draft. Who Provides This, and When Who’s supposed to provide all of this? The answer varies by organization, but the dependencies are fairly consistent: customer intelligence comes first, then compliance and response structure, then the section-level argument, then proof. The timeline depends on the pursuit. A recompete within a year of capture may work through this over weeks; a ten-day task order might do it in an afternoon; a five-day response with multiple contributors might compress the brief even further. The shorter the window, the more important it is to focus on the decisions that prevent rework, which we’ll come back to when we talk about assessing progress. This isn’t an argument for more process. It’s about making the important decisions in the right order to get the best result. This also looks different depending on team size: Small business: One person may wear all the hats: BD, capture, proposal manager, and writer. You don’t need four separate people; you just need to make the same decisions. Five bullets may be enough: What are they scoring? What must we say? What’s our proof? What’s different about us? What can’t we forget? Mid-sized organization: The challenge is often inconsistent handoffs. Some specialization and process exists, but it varies depending on who’s running the bid, its size, and its importance. A standard brief and standard review criteria can make a big difference here, regardless of who’s involved. Large enterprise: The process may already exist: storyboards, working compliance matrices, style guides, color teams, established practices. The problem becomes execution at scale. The question isn’t “do we have guidance?” It’s “can we get the right guidance to fifty different contributors consistently?” The underlying information is universal, even though the challenges are unique. Think about what needs to be conveyed rather than the specifics of your process, because the end goal is the same. Standards Worth Settling Before Review The brief handles bid-specific context. Now let’s talk about standards, and why they shouldn’t be reinvented on every section. A few things are worth deciding before review: readability, terminology, tone, and claims, and, where useful, a common section pattern. If an agency uses specific vocabulary, decide that once. If you have an acronym convention, decide it once. If unsupported claims aren’t acceptable, make that clear before the writer drafts them. For measurable things like sentence length or passive voice, you can use numeric signals, but be careful: these are diagnostics, not definitions of good writing. A complex engineering response shouldn’t read exactly like an executive summary. The goal isn’t to score the prose and declare it good; it’s to flag areas that deserve a closer look before a reviewer has to find them manually. I mentioned earlier how to best communicate with LLMs; those same structures are helpful here. Be as clear and structured with your writers as you would be prompting a model. Same Writer, With and Without Context Here’s the brief and standards in action, same writer, with and without context. Without context: “Our team brings extensive experience in complex IT transitions and is fully committed to a seamless, best-in-class transition…” We’ve all read versions of this sentence, and the type of review it attracts: What criteria is this answering? What does “extensive” mean? Are we doing a phased cutover or not? Where’s the evidence? All of that comes up because we’ve given only generic information. With context: “We move services one group at a time, so no single event can interrupt operations. On a comparable logistics agency contract, this phased cutover migrated 42 services with zero unplanned outages.” Now the review questions change: Is the past performance comparable enough? Can we substantiate the metric? Would the rollback point be stronger in a graphic? Are we pushing the risk argument hard enough? That’s a much better review, and those questions drive a much more substantial conversation. Same writer, same deadline. The difference is that the second review is about whether the argument wins. The first review is still just trying to figure out what the argument is. Reviewing Like an Evaluator Think about this as acting like an evaluator, not an editorial committee. Whatever your organization calls these gates, the principle is the same. Reviewers should be asking: Did we answer what was requested? Would I score this highly if I were evaluating it? Can I see why the approach works? Do I believe the evidence? Have we assessed the risk? Can I find the answers quickly? Scarce review time shouldn’t be spent debating “customer” versus “client,” acronym conventions, house terminology, or personal preference. We should settle those things beforehand; reviewers aren’t the problem, it’s the unstated review scope that is. Getting Guidance to the Contributor Finally, how do we get guidance to the contributor effectively? Everything we’ve discussed assumes the writer can actually see the guidance, and that’s the assumption where a lot of mature processes break down, because we’re assuming things that aren’t actually happening in practice. Think about the number of steps between the sentence being written and the guidance that applies to it. If the information isn’t right there, the writer has to leave the document, find the style guide, work out which version is current, find the relevant section, and go back to writing. Under deadline, every one of those steps becomes an opportunity to say, “I’ll fix it later.” How often does “later” actually happen before the next fire needs putting out? At scale, and at volume, this becomes much harder. For a small team, this may be a folder problem; for an enterprise, it can be a distribution problem. Either way, the outcome is the same: the guidance exists, but it isn’t consistently reaching the person writing. Where Technology Fits I think “automated versus manual” is too blunt a way to think about proposal work now. There are really three categories: Deterministic work: requirement identification, document comparison, terminology, acronyms, readability, prohibited language. These are areas where repeatability and auditability really matter. AI-assisted work: summarization, reviewing content, first-pass analysis, drafting support, synthesizing SME input. AI can get us to a starting point much faster, but someone still needs to be accountable for what it produces. Human judgment: strategy and differentiation, whether the proof is credible, understanding the customer’s real underlying needs, risk trade-offs, and what we’re willing to claim. AI can help surface possibilities and poke holes in an approach, but a person still needs to own the decision. That distinction matters because we should be using technology to protect human time for the work that actually changes the score. If you apply that thinking to the pre-drafting chain, you can see where the weight shifts: requirement extraction is automation-heavy; tracing requirements into the response structure is mixed, since it still needs interpretation; setting the argument is judgment-heavy; publishing standards is automation-heavy; checking the draft against those standards is automation-heavy. Amendments are a great test of this distinction: an amendment may technically change a requirement, but sometimes that change also affects strategy. The first can be detected by software; the second requires a conversation. Think about your tech stack, how it’s applied, and where it can do the most for you, and where you still need human judgment. A Few Small Things to Try I promised I’m not asking for a big change, just a few things you could try: Tell every writer how their section is evaluated. You don’t need a new tool for this: a couple of sentences and a transition instruction is a good start. Give them the message the section has to prove, and the evidence behind it. They need to understand the “why” and what the deliverable actually looks like. Tell reviewers what they’re actually reviewing: what’s in scope, and what’s already been settled. These small changes move a lot of discovery out of the review cycle. No major process overhaul, just better inputs. The Mature Process Checklist Here’s the fuller version; you’ll get a copy of this. In an ideal state, the written brief includes: Section M criteria, Section L requirements, clear messaging, evidence, published standards, clear review scope, automated checks where things are measurable, and guidance that reaches the contributor where they’re working. That’s the direction to head in. With so many organizations adopting automation right now, we’re in a season of change from a process and approach perspective, so use that to your advantage to set new standards. Measuring Whether It Helped So finally, how do we know if this actually helped? Don’t just count review comments or time spent. Fewer comments isn’t necessarily better: ten strategic comments can be worth more than fifty nitpicks. Look at the type of rework, similar to the tech discussion: what information was omitted, and could additional context or framing have improved the draft? Tag and classify comments, missing information, compliance, strategy, evidence, structure, style, and track how that mix changes over time. If missing-information and compliance comments fall, the process is doing more work before review. If strategy and evidence comments rise, that’s actually a good sign; it means reviewers have time to focus on questions that can improve the score. Before drafting, the section brief tells you when you’re not ready. After drafting, the review comments tell you what the process still failed to solve, and where there’s an opportunity to do more work. Takeaways Before you go into the draft, look at the input; make sure the writer has the right context. The more context, evidence, and decisions we move upstream, the more valuable the review process becomes. This depends on your size: for a small team, it might be five bullets; for a larger team, it might mean standardizing handoffs; for an enterprise, it may mean making sure the process you have is really reaching every contributor. But ultimately, the same decisions need to be made. Product Showcase: Stage Gates in VisibleThread (A short feature video, roughly three minutes, previewing a VisibleThread 7.3 feature: Stage Gates.) Speaker 2 Your company’s capture or proposal process is usually written down somewhere. Whether it was followed usually is not. Every time an opportunity or a proposal moves to the next stage, someone made a call, and there’s rarely a record of what they checked before making it. With that, I introduce Stage Gates in VisibleThread. Before any opportunity or proposal moves forward, the reviewer answers the questions you’ve set for that transition. Before looking into it further, let’s see how it’s set up. Let’s go to the Settings page, then Pipeline Stages. You’re not tied to a fixed set of questions; you have full control over the stages in your own capture and proposal process. For example, you can set the stage names and the color for each stage. More importantly, you can set the questions you want reviewers to answer before they can move to the next stage. You can reorder these questions or reorder the stages as you wish. Before saving these edits, there are three gate types you can apply: Soft gate, the flexible option. Reviewers can skip the questions set for that stage, and optionally add a note explaining why. Hard gate, the strictest option. An opportunity or proposal cannot advance until every set question has been answered. No gate, opportunities and proposals move freely, with no questions at all. You can set a different gate for tracked opportunities and for proposals. In this example, soft gate is used for tracked opportunities, and hard gate for proposals. Back on the Tracked Opportunities board, there are a number of opportunities at different stages of the capture lifecycle. When you move one opportunity to the next stage, a dialogue appears with the questions set in Settings, for example, “Who is the capture lead?” Because this board uses soft gate, there’s the option to skip the questions and add an optional note. Once selections are made, click “Move to Qualifying,” and the opportunity moves to the next stage. Every answer is logged and kept for audit purposes in the activity log. You can also click the activity icon on any card to see what happened on that opportunity, including how each reviewer answered stage gate questions. There’s also an icon at the top of the board at each stage; clicking it shows the questions a reviewer needs to answer to proceed past that stage. Moving to the Proposals board to see how it works in hard gate mode: moving the “NBIS Strategic Support” proposal to Red Team Review brings up questions to answer. Because this is in hard gate mode, the reviewer cannot skip anything; every question must be answered. That’s Stage Gates: it lets you enforce your own process and gives you an audit log of who did what, and when. Thank Speaker 1 you, everybody, and thank you for staying a few minutes over. One thing about Stage Gates: it’s an excellent way to reinforce some of what we talked about today. If there are specific items that must happen when putting together the brief, or handing it over to writers as we move into the writing stage, Stage Gates is something that can reinforce that, which is why I brought it in as an example. Thanks again, everyone, for joining us today. You’ll get the recording and the deck. Please register for the series if you haven’t already. Our next session will cover VisibleThread 7.3, with exciting updates around task assignment, collaboration, more effective reviews within the platform, and other improvements for collaboration and visibility across the entire proposal lifecycle. We hope to see you there. Have a wonderful rest of the day and weekend, and thank you for hanging in there with me through a bit of a hectic Thursday. Good to see everybody, have a great rest of your week.