In this instructional talk, Stacy Chin explains that reviewers of federal grants and contracts are not evaluating the brilliance of an idea but the likelihood that the proposing team can successfully execute the work. Drawing on her experience as a reviewer for NIH, NSF, and DOE and on consulting founders, she outlines five recurring reasons proposals are rejected: (1) an unclear, non‑executable technical plan; (2) milestones that lack quantitative success criteria and therefore do not demonstrate risk reduction; (3) mis‑alignment between the proposal’s focus and the solicitation’s stated problem; (4) insufficient proof‑of‑concept data leading to overly large technical leaps; and (5) a team that has not de‑risked execution through relevant expertise. For each failure mode she provides concrete remedies—use detailed figures, Gantt charts, and step‑by‑step experiment sequences; turn every milestone into a measurable gate with clear success/failure thresholds; ensure the technology, stage, and outcomes match the solicitation; build logical, incremental data bridges from current results to the next milestone; and fill team gaps with advisors, consultants, partners, or hires. She illustrates each point with real founder examples (David’s nanotech SBIR, Sarah’s ARPA‑H application, Emily’s DOW SBIR, Raj’s biotech SBIR, and a DOE material startup). The talk concludes by emphasizing that a proposal’s narrative must continuously address the reviewer’s core question: “Would I bet real money on this team to deliver?” and invites viewers to comment with their thoughts.
Chapters
So when a reviewer opens your proposal, they're not asking themselves, is this a good idea? They're asking, would I bet real money on this application that this team can actually pull this off? And frankly, a lot of first-time founders, especially in biotech and hard tech, lose that bet within the first few paragraphs. And not because the science is bad, but because the risks just felt too high. And I've seen teams spend 3 to 6 months on a proposal that frankly was just not fundable from the very start. I even sat on the reviewer side for like the NIH and NSF. Based on everything I've seen, I want to share with you guys the 5 reasons why proposals just won't get funded and what you can actually do in your applications that you can get awarded. Number 1: proposals that don't get funded have plans that don't feel executable. So I was working with David, a PhD founder spinning out a nanotechnology platform for oncology from the work he did in grad school, and he knew the science cold. We could go deep into targeting pathways, binding mechanisms, and you know, all that jazz. But then we adapted into his SBIR plan, and the language completely changed. He was using really broad language, like, as if we're developing formulations, we're going to evaluate efficacy. And the moment you read that as a reviewer, something just feels off, because when you can't see the work, you just don't know what experiments are happening first, what variables are being tested, how decisions are made if something fails. So it stops feeling like a plan and it starts feeling like we're just guessing. And unfortunately, that's what happens to David's application, and the final decision was a no. So if reviewers can't picture the experiments you're going to pursue, they're probably not going to fund it. So when you prepare your R&D grant, write your technical plan so clearly that a reviewer can visualize the exact sequence of experiments without second-guessing. Use things like figures and timelines and Gantt charts because those visuals can actually take your grant a very long way. Number 2, a common reason why grants don't get funded is because even though you have milestones, they don't describe how you're reducing your risks. And I saw this pattern with Sarah when she was working on her ARPA-H full application and she was trying to translate a diagnostic platform towards clinicals. Now, on the surface of our ARPA-H federal contract, everything looks so structured, like milestones, timelines, and clear progression. But if I put my reviewer hat on and you read the proposal closely, you can see your milestones being described as demonstrate feasibility, optimize assay performance. And that's where her proposal broke down, because as a reviewer, you're not asking if progress will happen. Rather, you're asking what success actually means. For an instant, reviewers want to know, for example, after you do these experiments, is sensitivity going to increase from 70 to 90%? Is the limit of detection going to be increased by twofold? At what point does your experiment fail? And without these quantitative descriptions, frankly, your milestones don't tell reviewers how you plan to reduce your risks. They just describe motion. Emotion for these federal grants and contracts simply is not enough. So bottom line, if your milestones aren't quantitative for any federal grant or contract and they can't define success, then they don't reduce your technical risks. So when you're writing your application, make sure to turn every milestone into a measurable technical gate with clear success metrics and failure criteria. Number 3, I seen many proposals that were not funded simply because their topic was not aligned to the solicitation. And this is the one I see the most often, but it's the most subtle. Let me explain. I was working with Emily on her DOW application. She has built a really cool platform delivering lighter technology in a manner that's so futuristic. And her science, it was solid. The data looked really good and the proposal itself looked well written, but she went after a DOW SBIR topic that was completely focused in a whole other area. And that's where the gap of her proposal fell apart, unfortunately, because from a reviewer's perspective, it doesn't matter how good your technology or proposal is, if it's not solving the exact problem that matches the solicitation and what they want to fund and at the stage they need it. And unfortunately, when reviewers saw her application, it just felt like a complete mismatch. And mismatches don't get funded. So from this example, learn that alignment beats effort every single time. Make sure to match your technology, stage, and the outcomes precisely to the solicitation. Reason number 4 of why proposals don't get funded: there's too much risks and not enough proof. Let me tell you about Raj and his biotech startup. In his application, he was proposing a new therapeutic platform aiming to show in vivo efficacy in an SBIR Phase I application. Ambition made sense. Direction made sense. But when you look at the data, there wasn't any validation of proof of concept. Now you have reviewers scratching their head wondering if this is going to be doable. And it's really difficult for reviewers to fund these types of proposals because you're asking the reviewer to believe in multiple jumps at once. New systems, new models, and new outcomes without showing the steps in between or any data that any of these steps can actually work. Bottom line, there's no bridge, just a leap. And from the reviewers' perspectives, if these proposals are way too risky, just like in the case of Raj's application, they're going to be thinking so many things have to go right in order for this to be a successful project. But that's called risk and high risk in the South. And reviewers are trained to avoid this. Next, when you prepare any federal grants or contracts, make sure the leap from your data to your goal is not too big, because in that case it won't get funded. Instead, make sure to build logical progression. So exactly how your current data sets and early experimental data will lead to your next milestone step by step. Number 5, as a reviewer, I've seen many proposals not get funded because the team did not de-risk the execution. I saw this happen with a material startup applying to the Department of Energy, or DOE. Their concept was strong in the early data supported their efforts. But when you look into their application, and particularly their team, there was a missing piece. No one actually had experience in scaling these efforts or validated their type of system in a controlled environment. And that detail mattered a lot, especially in this application. And that's because even though the science worked, the question in the reviewer's head becomes, can this team actually deliver on what they're proposing? And if the answer isn't an obvious yes, the risks go up. And if you find yourself in this position, there's many ways to go about it. You can address this gap with advisors, consultants, partners, or new hires. If you don't address this effectively in your application, this just remains an unresolved gap in the reviewer's mind. Because bottom line, your team is a big component of your technical plan. So if your team doesn't clearly de-risk execution, the proposal just simply won't get funded. So if you're working on your federal grant or contract, make sure to fill those gaps early on. And most importantly, make sure it's visible in your application. So either way, when I work with lots of founders on their grants or contracts, many think about just explaining their concepts clearly, but it's more than that. It's all about how to position the narrative to remove doubt in the reviewer's mind. And when we work with startup founders trying to prepare their applications, we always go through their narratives to make sure it clearly states, can the team execute? Are the milestones meaningful? Is this the right fit for the solicitation? Are the risks controlled? And if you can answer any of those steps in your application, you're already ahead of most applicants. Because at the end of the day, reviewers aren't just funding your idea simply. They're funding your ability to de-risk and remove the doubt in their mind. And every part of your proposal should be meant to reduce that risk and doubt. And if not, it just adds to it. At the end of the day, that's how funding decisions get made in federal grants and contracts. So let me know what you think, if this is helpful, but curious to know what your thoughts are in the comments below.
