Why So Many NSF Project Pitches Come Back Declined

Read enough NSF Project Pitch declines and they start to blur together. Different companies, different fields, different stages of maturity, and the letters say close to the same thing: the pitch did not sufficiently articulate a new, high-risk technological innovation, and the proposed work emphasized implementation rather than investigation of a distinct, technically differentiated approach.

That repetition is worth paying attention to. In most of these cases the technology was fine, and the pitch simply answered a different question than the one NSF was asking.

What the letter does not tell you is which part of your pitch caused it. There is no reviewer panel behind the decision and no scored feedback, so there is no reliable way to work backward from the wording to the paragraph that triggered it. Revisions end up being broad, and the second attempt often comes back the same way.

Why the feedback is thin

The Project Pitch is a screening step handled by program directors, and it exists so that a company does not spend three months writing a full proposal for work that was never responsive to the program to begin with. Detailed feedback at that stage would be hard to sustain at the volume NSF receives, since writing a reviewer-style critique of every declined pitch would consume more program staff time than reviewing the full proposals does, so the response is short and drawn from consistent language.

That is a reasonable way to run a filter, but it leaves the applicant with very little. You learn that something did not clear the bar
without learning what, and since you cannot trace the letter back to a particular sentence in your own document, you are left guessing at which of several plausible problems to fix. In most of the pitches we review after a decline, the answer is that the document described something other than what the screen is looking for, which is genuinely hard to see from the inside.

The cost of guessing has gone up

A company may submit no more than two Project Pitches in any rolling twelve-month period, and no more than three in total for the same project or technology, regardless of topic or timeline. Those limits apply at the company level, and because NSF treats affiliated entities as a single company, standing up a second LLC does not produce a fresh set of attempts.

Consider a company that submits a pitch, is declined, spends a few weeks tightening the language, submits again, and is declined for the same underlying reason. It now has nothing left for that technology until the twelve-month window rolls over, which for a company that was timing a raise around non-dilutive validation can push the financing conversation out by three or four quarters.

The other thing that has changed is the pile itself. More pitches are arriving, and drafting one has become much faster, since an
afternoon and a language model will produce something confident and well organized. That was never going to help anybody, because program directors were not screening on writing quality in the first place, but it has changed what a
large share of the submissions look like. A platform gets described, a market gets sized, a set of benefits gets laid out, all of it perfectly fluent, and the technical mechanism at the center of the work never gets named. Generative tools are unusually good at producing sentences that feel specific while containing no specifics, which happens to be the precise failure the screen was built to catch.

What actually goes wrong

Five patterns account for most of the declines we read.

1. The pitch describes the product rather than the innovation. This is the most common failure by a wide margin, and it is the hardest one for a founder to catch, because the writing is usually good and the technology is usually real. The document explains what the system does, who it helps, and how much better it performs than what exists today, sometimes going
into the underlying physics or biology at length, without ever isolating the mechanism, architecture, material, or method that is actually new. A program director can finish that section with a complete understanding of the value
proposition and still be unable to say what is being invented, which is what sits behind NSF’s language about an innovation that was not sufficiently differentiated.

2. Objectives are written as a build sequence. Design the subsystem. Fabricate the prototype. Test it. Demonstrate performance against the target. Every one of those is real work that somebody has to do, but none of them tells a reviewer what the company will know at the end of Phase I that it does not know now, and an objective that cannot come back negative is not an investigation.

3. Difficulty gets mistaken for technical risk. Founders read “high-risk” and think about the hardest thing on their roadmap,
which usually turns out to be integration, or scale-up, or hiring someone with a rare skill set, or getting unit cost down to a number a customer will accept. All of that is genuinely hard and often it is the thing keeping them awake at night, but the route from here to there is understood, and understood is the problem. On every review we ask some version of the same question: if you handed the specification to a competent, well-funded engineering team, could they simply go execute it? When the answer is yes, the project is going to struggle in this program no matter how demanding it is.

4. The commercial section argues a different case. Market sections frequently read as though they were written for a different audience, and often they were, because the text came straight out of an investor deck, which is why you get a top-down market figure and a competitive grid and a channel strategy with no visible connection to the technical work being proposed. In a Project Pitch the commercial case has one job, which is to explain why resolving this particular technical uncertainty matters to somebody identifiable who will pay for the answer.

5. The four sections never reference each other. The form presents four boxes and a great many pitches read exactly the way that invites, as four separate documents stapled together. In the ones that get invited, the innovation creates the uncertainty, the uncertainty determines the objectives, and the objectives unlock something a customer wants, so that each section is doing work the others depend on. When they stand apart, what a reviewer sees is a project that was assembled to fit a funding opportunity.

A test you can run on your own draft

Take a single objective and trace five links through it: what is technically new, what remains unknown because of it, what experiment resolves that unknown, what measured result counts as success, and what becomes commercially possible once the result comes in. Then find where the chain breaks, because that break is what the program director is going to see. A innovation with nothing unknown attached to it reads as work that is already finished, an experiment that cannot come out either way is a demonstration rather than a test, and a threshold that leads nowhere commercially puts the whole pitch in front of the wrong agency.

Running that exercise will improve most drafts, but it will not tell you whether yours clears the bar, and that limit is worth sitting with for a moment. The problem in a declined pitch is rarely the technology and it is almost never carelessness. It is an argument that reads clearly to someone who already understands the technology and vaguely to everyone else, and that is not a defect you can catch in your own writing. Deep expertise in the subject makes it harder to catch rather than easier, because you supply the missing connections without noticing that you are doing it.

How we read a draft

We work from a scoring framework built around the criteria NSF screens on, weighted toward the technological innovation and the technical risk and R&D plan. It comes out of years of developing and reviewing pitches across agencies and technical fields, and out of seeing which arguments drew an invitation and which ones did not, which is enough to form a reasonable estimate of how a draft is likely to be received. It will not tell you what a program director is going to decide. What it does well is locate the weakest link in the argument, since that link is where a reviewer stops reading charitably.

The questions underneath it are not complicated. Can a technical reader outside your field state your innovation in a sentence or two after reading the opening? Is the uncertainty you are claiming scientific or technical, rather than cost, schedule, or staffing described in technical language? Does each objective ask a question with a threshold that decides the answer? Does the commercial case point back at that same threshold?

How much work follows from that varies more than most founders expect. A pitch that is already close may need the innovation stated plainly near the top and the objectives rewritten so they follow from it. More often the technical section has to be rebuilt around the mechanism, which then changes what the objectives are for and what the market section has to prove. Occasionally the honest answer is that the project as currently scoped is not a fit for this program, and that is worth finding out before you spend an attempt rather than after.

With two attempts a year and three for any given technology, there is not much room left to submit a pitch and find out what happens. Send us a draft before you use one. Early drafts are easier to work with than polished ones, since an argument can still be rearranged before the wording has set.

To have your Project Pitch reviewed before submission, contact us at sales@fedsprout.com.