An SBIR Award Is a Development Program, Not Just a Grant

An NIH SBIR or STTR application is easy to treat as a writing problem.

Develop the Specific Aims. Build the research strategy. Justify the budget. Collect the supporting documents. Submit.

But if the application succeeds, those paragraphs become something very different:

a development program your company now has to execute.

That makes the better question:

If this proposal is funded exactly as written, is this actually the work we want to be doing?

The strongest SBIR programs are not grant applications with development activities attached.

They are well-designed development programs expressed in grant form.

The grant is not the product

Non-dilutive funding can be extraordinarily valuable to an early-stage company.

It can buy time, experiments, prototypes, validation work, specialized expertise, and technical progress without requiring immediate equity dilution.

But funded activity is not automatically useful development.

Problems arise when the program is optimized primarily around what looks good in an application rather than what the company genuinely needs to learn next.

An aim may demonstrate interesting science without reducing the most important technical risk.

A milestone may sound precise without actually creating a go/no-go decision.

A validation or animal study may appear appropriately rigorous while being poorly timed in the development sequence.

The commercialization strategy may describe one product while the experimental plan develops something slightly different.

Or Phase I may generate data without leaving the company in a clear position to decide what should happen next.

The reviewer is an important audience.

But if the proposal succeeds, the company has to live inside the program it proposed.

Design the development program before writing the grant

Before drafting Specific Aims, I would want to answer three questions:

What does the company need to learn next?

What evidence would make the next development decision defensible?

What work will generate that evidence with the resources actually available?

Only then should those questions be translated into aims, experiments, milestones, budgets, collaborators, and narrative.

The sequence is:

Development question → Technical risk → Evidence needed → Experiment → Milestone → Decision

Then:

Grant application.

Starting this way does not make the proposal less scientific.

Usually, it makes it more specific.

The experiments have a reason to exist. The milestones have consequences. The budget maps to actual work. Collaborators have defined roles. And the team knows what it is supposed to learn when the project is complete.

A good Specific Aim should reduce uncertainty

An aim should not exist simply because the application needs another aim.

It should meaningfully change what the company knows.

Compare:

Optimize assay performance.

with:

Establish assay conditions capable of achieving predefined analytical performance across the intended operating range.

The first describes activity.

The second begins to define a development question.

If the work succeeds, the company has evidence supporting advancement.

If it fails, the result should help identify what must change before advancement is justified.

That is much closer to how a useful development program behaves.

A simple test for any proposed aim is:

What important uncertainty will we have reduced when this aim is complete?

If the answer is unclear, the aim probably needs more work.

Milestones should create decisions

A good milestone is not merely evidence that work occurred.

It should help determine what happens next.

“Complete assay development” is not particularly useful as a development milestone.

Something closer to:

Establish a frozen method and analytical characterization package sufficient to determine readiness for formal validation

creates a much clearer decision point.

At the end, the company should be able to decide:

Proceed.

Optimize.

Investigate.

Redesign.

Repeat.

Stop.

The specific decision varies by program.

What matters is that success and failure are distinguishable before the results are known, and that either outcome produces information the company can use.

This principle applies well beyond assays.

A device milestone should change what you know about the device.

A preclinical milestone should change what you know about the biological or translational risk.

A manufacturing milestone should change what you know about scalability or reproducibility.

A milestone should not merely close an item on a grant progress report.

It should move the development program.

Phase I should create options

NIH frames Phase I around establishing feasibility, technical merit, and commercial potential.^1, 2

That is a useful definition—but for a company, I would push the thinking one step further.

Feasibility of what, and sufficient to justify what next?

A productive Phase I should ideally leave the company with an option it did not previously have.

A method worth validating.

A prototype worth verifying.

A biological signal worth investigating further.

A manufacturing approach worth scaling.

A dataset capable of supporting the next financing or development conversation.

Or, just as importantly:

credible evidence that the current approach should not advance.

Stopping a weak approach before consuming Phase II-scale resources is also a useful development outcome.

The objective is not to make every Phase I program succeed.

It is to make the result informative enough to support the next decision.

Design Phase I with the next stage visible

Phase I should not try to solve every future development problem.

But the team should understand which future problems are approaching.

Before finalizing the program, I would ask:

What would need to be true before a Phase II program makes sense?

What will a regulatory reviewer eventually need to understand?

What will an investor or strategic partner ask during diligence?

What technical risk becomes expensive to address later?

When does the method need to be frozen?

When will formal validation become appropriate?

What manufacturing capability will eventually be required?

Which evidence generated today could be designed so that it remains useful tomorrow?

Those questions can materially change the work included in an application.

Collaborators should solve problems—not decorate applications

Academic investigators, CROs, clinical collaborators, engineers, statisticians, regulatory specialists, and other external partners can make an SBIR program much stronger.

But they should be included because they provide a capability the development plan actually requires.

For every collaborator, the team should understand:

What are they responsible for?

What will they deliver?

What inputs do they require?

Who owns the resulting data?

Who makes decisions when the work deviates from plan?

What happens to the development program if their work is delayed?

A strong letter of support is useful.

A collaborator embedded in a coherent execution plan is much more useful.

Budget the development question

The budget should follow the work—not the other way around.

If an experiment is supposed to resolve a major technical uncertainty, it needs enough resources to produce interpretable evidence.

That may require sufficient samples, appropriate controls, statistical planning, specialized equipment, outside expertise, representative prototypes, or adequate replication.

At the same time, an available budget is not a reason to perform work that does not materially advance the program.

Every major expenditure should be traceable back to something the company needs to learn, establish, build, or de-risk.

A useful question is:

If we spend this money and the experiment works exactly as planned, what becomes easier to decide?

Plan the documentation before the award

Documentation is another area where grant planning and product development can diverge.

The application describes experiments.

The eventual company needs evidence it can reuse.

That may include:

protocols,

requirements,

raw and processed data,

methods,

acceptance criteria,

deviations,

statistical analyses,

technical reports,

decision records,

and traceability between them.

If those outputs are planned from the beginning, an SBIR program can leave behind a structured development record.

If they are not, a company can finish an award with a collection of presentations, notebooks, CRO reports, and datasets that are surprisingly difficult to reconstruct later.

The goal should be more than completing the proposed work.

It should be preserving what the company learned.

Post-award execution matters as much as proposal quality

A beautifully written application does not guarantee a well-run project.

Once funded, somebody still needs to translate the proposal into:

work packages, protocols, responsibilities, timelines, vendor scopes, decision points, risks, documentation, and deliverables.

This is where grant writing becomes program management.

And it is where poorly designed proposals become painful.

If a project cannot realistically be staffed, subcontracted, coordinated, documented, or completed within its technical and financial constraints, the problem existed before the Notice of Award.

Funding simply made it visible.

Sometimes the right next step is not an application

One of the most valuable conclusions during SBIR planning can be:

We are not ready to write this yet.

Perhaps the intended use is still changing.

Perhaps the assay is not sufficiently developed to design the proposed validation.

Perhaps the central technical risk has not been identified.

Perhaps the team knows it needs an animal study but cannot yet explain what decision the study would enable.

Perhaps Phase II is being discussed before anyone knows what successful Phase I evidence would actually look like.

In those situations, forcing the technology into a grant structure creates false precision.

The more useful work may be a development roadmap, feasibility experiment, validation-readiness assessment, regulatory discussion, or technical-risk analysis.

Then the grant application can be built around a program that actually exists.

A simple readiness test

Before committing substantial effort to an SBIR or STTR application, ask:

If NIH funded this proposal tomorrow, would we be excited to execute the work exactly as described?

And:

If every aim succeeded, would we know what the company should do next?

If both answers are yes, you probably have the beginnings of a strong development program.

If not, the problem may not be the grant writing.

The program itself may need more work.

The bottom line

An SBIR application should not determine the company’s development strategy.

The development strategy should determine the SBIR application.

Start with the product.

Identify the important uncertainty.

Determine the evidence needed to reduce it.

Design the experiment.

Define the milestone.

Know the decision that follows.

Then write the grant.

Because winning an award is valuable.

Winning an award for work you actually need to do is much more valuable.

References

1. National Institutes of Health, SEED. Understanding SBIR and STTR.
2. National Institutes of Health. NIH Grants Policy Statement: Small Business Innovation Research and Small Business Technology Transfer Programs (Section 18.5).