How to Write a Winning SBIR Phase II Proposal

Search "how to write an SBIR Phase II proposal" and you get government PDFs. Forms. Fonts. Page limits. The rulebook.

Nobody publishes the playbook: what to actually say, how to frame the work so a reviewer funds it, how to build a milestone schedule that survives a contracting officer, and the specific moves that get a strong technical team rejected on a technicality.

This is the playbook. No one guarantees a win. Anyone who tells you they do is selling you something. A technically brilliant proposal and a winning one are different documents, and the difference is learnable. Here it is.

The one idea that changes everything

A Phase II proposal is not an essay about how good your technology is.

It is an argument that a specific government customer has a specific problem, that you have already proven the hard part works, and that a defined amount of money over a defined time produces specific reports the government will accept and pay for.

Almost every losing proposal violates this. Strong teams write a beautiful description of their technology and assume the value is obvious. Reviewers do not fund technology. They fund de-risked work that leads somewhere the government needs to go. Your job is to make that argument, not to impress.

Everything below is a consequence of that one idea.

Frame it as "proven foundation, then new build"

The single most common way capable teams lose: they describe a finished product.

Put yourself in the reviewer's chair. Their mandate is to fund research and development. If your proposal reads as "we already built this," the rational response is "then you do not need our money." If it reads as "here is a science project with no evidence it will work," the response is "too risky." You win in the narrow band between those two.

So structure the core of the proposal as two tracks, explicitly, for every objective:

• Proven today. What you can demonstrate right now, with evidence: a deployment, a named customer, a real artifact, hard numbers, dates. Past tense. This buys you the right to be believed.
• The Phase II new build. The specific new R&D the money funds. New work. A named technical uncertainty it removes. A measurable way the government accepts it.

This works whether you are a software company with a production deployment or a hardware company with a commercial product line. In dual-use programs like AFWERX / Agility Prime the same idea wears different words: "non-defense commercial solution" is your proven foundation; "proposed adaptation" is the new build. Same logic, different label.

Take a fictional but realistic example we use throughout: Halyard Systems, product Beacon, a market-intelligence platform already deployed to a government customer with a few hundred analyst users.

First draft (rejected logic): "Beacon analyzes the industrial base and generates reports."

Winning draft: "Beacon already indexes tens of millions of companies. It delivered multi-hundred-page landscape reports in production last fiscal year. Phase II builds the continuous enrichment engine that does not exist yet, resolving cross-source identity under sparse signals, accepted when the Government validates it against an expert-curated reference."

The facts barely changed. The framing changed completely. One of those gets funded.

Make every milestone a deliverable the government pays for

This is where proposals quietly die. Reviewers and contracting officers read the milestone table the way an investor reads a cap table: it tells them whether you understand the deal.

A winning milestone table has exactly these columns: number, expected delivery (Award + X months), the deliverable, the acceptance criterion, and a payment amount. Every row.

Three rules, all learned from real won proposals:

1. Make a report the accepted artifact. Even when the work is a hardware build or a test, the engineering report is what gets archived, forwarded, cited, and paid against. A prototype can vanish into a lab; a report is what the Government formally accepts and invoices. Name the artifact for every milestone and make it acceptable.
2. Acceptance is phrased as "the Government accepts X." Not "successful completion." "The Government accepts the milestone upon delivery of the validation report demonstrating the stated threshold." That sentence is what makes a milestone invoiceable.
3. Shape: small kickoff, heavy middle, small finish. Across the DoD wins we have seen, the pattern holds: a small initial milestone (a requirements/roadmap report), the bulk of the money in the middle, a small final wrap-up report. The small first milestone is the part that matters. Confirm the exact shape against your component's instructions, which can differ (NIH, NSF, and DOE Phase II pay differently).

Every milestone carries a dollar amount because the schedule of deliverables and the cost volume have to reconcile and the government pays against accepted work. A milestone with no dollar figure is the first thing a contracting officer catches.

Write like someone who has earned the room

Tone loses more proposals than you would believe. The failure is always the same: the proposal sounds like marketing.

The voice that wins is quiet confidence. Casual, professional, respectful. It sounds like someone who has spent time with the customer and knows their constraints, not someone selling at them. Specifically:

• Never name competitors or brand-name tools. Describe the capability ("a long-context model," "a multi-source retrieval architecture"), not the brand. Naming a competitor invites a comparison fight you do not need.
• Quote the government's own description of its problem once, with a date, and move on. Used once in the opening, attributed, it is credible. Repeated, it reads as contempt.
• Never tell the reviewer how to read your proposal. Sentences like "Phase II does not fund discovery, it funds X" or "what this actually buys is" are the clearest tell of a first-time writer. Describe the work. Let the milestones speak. The reviewer decides what it funds.
• Lead AI and report descriptions with content, not self-praise. "A 180-page landscape report covering 4,000 entities with capital-flow overlays" lands. "Our high-quality report" does not.

Get the boring things exactly right

A brilliant proposal that breaks a mechanical rule is not evaluated. These are the ones that end strong teams:

• The Technical Volume exceeds the page limit (depending on the solicitation, the overflow is ignored or the whole proposal is rejected; both are fatal).
• A required form is missing.
• Body font below the floor.
• An acronym used before it is defined.
• "TBD" or a placeholder role still in the document at submission.
• The foreign-national disclosure is incomplete.
• An abstract over its character limit (the portal truncates it).

None of these is hard. All of them are fatal. The fix is a disqualifier pre-flight you run before you submit, every time. We built one into a free Reviewer Scorecard and an open-source linter, because catching this should not depend on remembering.

Two more places to be careful

Commercialization is not a sell-to-other-agencies list. Government and DoD customers are legitimate parts of a strong commercialization section, and a Financing subsection covering capital raised is normal and good. What is weak is opening with an enumerated list of agencies you will sell to, or substituting "we will raise money" for a real customer story. A winning commercialization section is structured and specific: company and team, customer and competition with third-party demand evidence, sized market, IP, financing, partners, and named customers (defense and commercial). The cost-volume piece closes with the full commercialization structure.

Data rights: assert, never pre-concede. A data-rights concession cannot be made a condition of award, and any expanded license is voluntary and negotiated post-award. Do not give away rights in the proposal to look generous. Identify your pre-existing IP as retained, note the SBIR protection for new work, and stop there.

The official Q&A is your highest-leverage research

Before you write a word, harvest every official pre-submission question and answer for your topic. It is the authoritative interpretation and it routinely resolves ambiguity in the topic text. Date-stamp each ruling, mark which ones are binding, and map each to the section it changes. Teams that skip this build to the topic announcement and get surprised; teams that mine it build to what the government actually meant.

What to do now

1. Find your solicitation and pull its official Q&A. Build the intelligence file.
2. Write your §2 in the past tense: what have you demonstrated?
3. Draft the milestone table first, before the prose. If you cannot put a dollar amount and a "the Government accepts X" line on every row, you do not yet understand the work.
4. Run the disqualifier pre-flight before you submit.

The deeper mechanics each have their own piece: the milestone table, the disqualifiers, Direct-to-Phase-II feasibility, the cost volume, and what reviewers actually score.

You do not need permission or a consultant to write a strong, winnable Phase II. You need the right model of what you are doing. Now you have it. Then run your draft through the free Reviewer Scorecard, no signup, and find out what a reviewer will.