SBIR Proposal Writing Basics: Don’t Sell But Instead Meet a Need

Gail & Jim Greenwood, Greenwood Consulting Group, Inc.  

Copyright © 2006 by Greenwood Consulting Group, Inc.

 

A few months ago, one of the agencies’ SBIR/STTR Program Managers told us that proposal writers should not try to “sell” to the topic authors when calling or emailing them during the pre-release period.  At first, that seemed like bad advice, since we tell folks that their SBIR/STTR proposal is a sales document (versus the technical journal paper that we often see).  However, we think there is an important difference between “selling” to the topic author or reviewer versus “meeting a need.”

 

“Selling” has a pretty negative connotation.  It congers up visions of vacuum cleaner or encyclopedia salesmen showing up at your front door and using high pressure sales tactics to coerce you into buying something you don’t want.  In an SBIR/STTR situation, this might be akin to immediately telling the topic author or reviewer that you have a great innovation, telling them all the great things your innovation will do, and then trying to convince them that your innovation is just what they need.  Note here the emphasis is on your innovation and its merits—the needs of the agency or its constituency take a distant back seat.

 

In contrast, “meeting a need” suggests that you find out first what the client needs, then deciding if your innovation could fulfill that need, and then finally demonstrating that you understand the need and that  your innovation will meet it.  Do you see the difference?  Here, the SBIR/STTR proposer first spends time and effort understanding the need, and only submits a proposal if their innovation can meet that need. 

 

So how do you find out what the agency needs?  Well, start by reading the solicitation—both the topic description, general information about the agency, and probably all of the other topics (or at least the major categories of topics) so that you have as much information as possible from this primary information source.  However, chances are real good that you will have further questions about the need (or, if you don’t find such questions popping up, that’s a warning sign that you are again focusing too quickly on your innovation rather than fully understanding the need).  Write those questions down, including those that will help determine if your innovation meets the need.  Questions like minimum and maximum acceptable values for power consumption, precision, accuracy, and tolerance to vibration, pressure and temperature extremes. And what is the most important part(s) of the problem that must be solved, versus those that might be nice but aren’t critical. Then put those questions in priority order—put the ones at the top of your list that you must get answers to or you will not understand the need and/or your innovation’s ability to meet it.  Now contact the topic author, and ask your questions starting with the highest priority ones and progressing down the list until either (a) you fully understand the need and your innovation’s ability to meet it, (b) you are clear that your innovation won’t meet the need, or (c) the topic author can’t spend any more time with you. 

 

Now, based on the information you’ve gleaned about the need, honestly assess your innovation’s ability to meet it.  Will your innovation solve the most critical aspects of the need?  If so, will it do so better than competing solutions?  What drawbacks does your innovation have, and how can you mitigate them?  Why should this agency invest in your solution rather than someone else’s? 

 

If you are convinced that you really understand the need and have an innovative solution that will be among the best, NOW decide to write a proposal on this topic.  The proposal will need to convince the reviewer that you really understand the need, its most critical components, its nuances, etc.  Then the proposal will need to demonstrate how your innovation will meet the need better than anyone else will. 

 

“Ah-ha,” you say, “but I’m submitting a proposal to a grant agency like NIH, USDA, or NSF, and they fund ‘good ideas’ rather than solutions to specific problems.  Therefore, I have to ‘sell’ to the agency reps and reviewers to convince them that I have a ‘good idea’ worthy of their funding.”  Well, you’re right in that grant agencies tend to fund “good ideas” whereas contract agencies (the latter include DOD, NASA, DOC, DOT, HSARPA, and EPA) want solutions to specific problems or needs.  But “selling” still isn’t the right approach to a grant agency, either.  Why?  Because remember what we said earlier:  selling suggests that you tell the agency rep or reviewer that you have a great innovation, telling them all the great things your innovation will do, and then trying to convince them that your innovation is just the greatest idea they’ve ever seen.  This heavy emphasis on the innovation once again ignores what is REALLY important to the agency, which is the problem or need that your innovation is going to solve.  The grant agencies do fund “good ideas,” but a definition of a good idea is one that solves a significant problem.  Therefore, the emphasis again has to be put on the need or problem—show in the proposal that you really understand it, and then convince the reviewer that your innovation is the best way to solve it.