BUILDING YOUR HEILMEIER RESPONSES

A structured framework for answering the 9 questions that define a fundable research concept

What is the Heilmeier Catechism?

The Heilmeier Catechism is a set of eight plain-language questions that former DARPA director George Heilmeier developed in the 1970s to force researchers to justify a project in terms of real-world impact rather than technical elegance alone. Broken down here into 9 questions this exercise helps to strip away the jargon and citations that work in a dissertation defense but won't survive a five-minute conversation with a program manager who's deciding whether to fund you.

Using This Worksheet

We will walk through all 9 questions together. For each one, you will see what is being asked, why it matters to reviewers, and what a strong answer requires. The Heilmeier responses are the technical core of future proposal and shapes the way you will talk about your technology and company.

Step	What you do
1. One question at a time	For each question, review what is being asked, why it matters, and what a strong answer requires.
2. Draft in the room	Use the structured prompts to write a working draft response for your concept. Aim for clarity. Polish comes later.
3. Refine and return	Bring a complete Heilmeier response set to the next session. These responses become the source document for every artifact in your submission kit.

More Than a Proposal Tool

Build it once. Use it everywhere. Your Heilmeier responses do work across the venture, not just inside a single proposal.

Use	How the responses help
Project execution & program reviews	Define what success looks like and why the work matters. Anchor progress reviews, frame go/no-go decisions, and keep the team aligned to the original mission as execution gets complex.
Teaming & partner conversations	Prospective teaming partners want to know what you are building, why it is different, and what role they would play. Give a structured, credible answer to all three.
Business development & PM engagement	Program managers respond to founders who understand and frame their effort in the mission context. Q1 through Q5 responses give a concise, credible briefing for any PM conversation, and Q6 through Q9 responses show execution credibility.
Capital raises & investor storytelling	Investors in deep tech want to understand the problem, the insight, and the evidence in the Q1 through Q3 answers. The responses serve as a first-draft investor narrative in language that works for technical and non-technical audiences alike.

The Nine Questions

Question 1 of 9

Q1. What are you trying to do? (Use no jargon.)

What reviewers are really asking

Can you state your objective clearly enough that a non-technical expert like a Hill staffer or operational end-user immediately understands what you are building and why it matters?

Strong answers

Uses plain language without acronyms or field-specific terms
Names a specific problem, not a research area
Implies a clear beneficiary and a measurable outcome

Weak answers

Opens with technical jargon or a literature reference
Describes a capability rather than a problem being solved
So broad it could describe dozens of research programs

Structured response prompts

In one sentence, what problem does your technology solve?
Who specifically has this problem, and how badly do they have it?
What exists or works differently when you are done? How do you define success?
Read it back: would a non-expert understand this without asking a follow-up?

Question 2 of 9

Q2. How is it done today, and what are the limits of current practice?

What reviewers are really asking

Do you understand the operational and competitive environment well enough to articulate why the status quo is genuinely insufficient, not just inconvenient?

Strong answers

Names specific current approaches, tools, and techniques
Quantifies the gap (speed, cost, accuracy, coverage)
Shows you have done real customer or user research, not just a literature review

Weak answers

Vague references to current limitations without specifics
Ignores the best existing competing approaches
Treats minor inconvenience as a fundamental gap

Structured response prompts

What do practitioners actually do today to address this problem?
What are the specific performance gaps, failure modes, or cost barriers of current approaches?
Why is this hard, and why have existing solutions not already solved this concern?
What would a skeptical reviewer say is good enough about the status quo, and how do you respond?

Question 3 of 9

Q3. What is new in your approach and why do you think it will be successful?

What reviewers are really asking

Is your innovation a genuine technical or conceptual advance, or is this an incremental improvement a reviewer has seen many times? Is this a DARPA Hard problem?

Strong answers

Identifies a specific, named innovation
Anchors novelty claims to prior art, not just assertions
Connects preliminary evidence to the proposed approach

Weak answers

Claims novelty without distinguishing from prior work
Relies on we are uniquely positioned without substantiation
Innovation is integration or packaging, not a technical advance

Structured response prompts

What is the core insight or mechanism that makes your approach different?
What evidence suggests this approach can work?
Why now? What makes this approach feasible today that was not feasible before?
What would have to be true for a skeptic to agree this is worth funding?

Question 4 of 9

Q4. Who cares?

What reviewers are really asking

Have you identified the real decision-makers and end users, and can you show that they actually want this, not just that they should want it?

Strong answers

Names specific customer types with specific use cases
Distinguishes between who uses it and who pays for it
Grounds who cares in conversations or data, not assumption

Weak answers

Too broad to be credible (for example, everyone who works in X)
Assumes government interest without agency-specific grounding
Describes a market size instead of a specific customer need

Structured response prompts

Name specific types of people or organizations who need this, and distinguish end users from program sponsors.
What would they stop doing, do faster, or do at all if your technology worked?
Have you talked to any of them? What did they say?
Who within a funding agency would champion this, and what drives those decisions?

Question 5 of 9

Q5. If you are successful, what difference will it make?

What reviewers are really asking

Can you articulate impact at a scale that justifies the investment? Can you connect your technical outcome to an operational or mission-level change?

Strong answers

Connects technical outcome to a mission or operational change
Quantifies impact where possible beyond the generic improved performance
Addresses near-term and longer-term implications

Weak answers

Stays at the level of better technology without downstream effect
Uses generic impact language (transformative, game-changing)
No connection between research output and real-world adoption

Structured response prompts

What changes in the world, operationally, economically, or strategically, when this works?
How does success in this project enable follow-on funding, transition, or deployment?
What is the counterfactual: what does not happen if this does not get funded?
How would you measure mission impact, not just technical performance?

Question 6 of 9

Q6. What are the risks?

What reviewers are really asking

Do you understand what could go wrong, technically and commercially, and have you thought seriously about mitigation?

Strong answers

Names specific, operationally grounded risks
Distinguishes technical risk from commercial and transition risk
Proposes concrete mitigation, not just awareness

Weak answers

Minimizes risk or presents trivial concerns to appear more fundable
Lists risks without any mitigation strategy
Ignores the possibility that the core technical approach fails

Structured response prompts

What are the top 2 to 3 technical risks that could cause the approach to fail?
What are the reasons an operator might not use, or a customer might not buy, this even if it works (transition and commercialization risks)?
For each risk, what is your mitigation strategy and what is your contingency?
How do you know it is not working, and what is the trigger point to pivot the approach mid-project?

Question 7 of 9

Q7. How much will it cost?

What reviewers are really asking

Is your budget a credible reflection of the proposed scope of work and not simply a function of funding limits?

Strong answers

Budget reflects the actual scope of work, not just the award ceiling
Major cost categories are explained, not just listed
Cost is internally consistent with team, timeline, and deliverables

Weak answers

Budget matches the program limit suspiciously exactly (less of an issue for SBIR specifically)
No rationale for labor allocation or equipment costs
No cost realism: scope and budget tell different stories about what will be done

Structured response prompts

What are your major costs for labor, equipment, materials, consultants, and subawards?
Does your budget align with the team size and timeline you have described?
What is the cost per deliverable or milestone?
What are you not funding in this award, and why does that make programmatic sense?

Question 8 of 9

Q8. How long will it take?

What reviewers are really asking

Is your timeline realistic for the scope of work described, and does the schedule reflect how this kind of work actually gets done?

Strong answers

Timeline is grounded in the actual tasks in the work plan
Milestones are specific and evaluable, not just dates
Schedule risk is acknowledged and buffers are reasonable

Weak answers

Timeline matches the period of performance without task-level justification
No dependencies shown; everything appears to run in parallel
Milestones are activity-based (conduct research) not outcome-based

Structured response prompts

What are the major phases of work, and how long does each realistically take?
What are the task dependencies, what can be done in parallel, and what is incremental?
What tasks are most likely to slip, and by how much?
How does your timeline align with the funding mechanism's phase structure?

Question 9 of 9

Q9. What are the midterm and final "exams" to check for success?

What reviewers are really asking

Is success defined precisely enough that a reviewer could determine whether you achieved it without asking you to interpret the results?

Strong answers

Metrics are specific and independently verifiable
Midterm and final criteria are meaningfully different
Go / no-go decision logic is explicit: pass means X, fail triggers Y

Weak answers

Success criteria are activity-based rather than outcome-based
Metrics are self-reported and unverifiable
No distinction between midterm checkpoint and final deliverable

Structured response prompts

What specific, measurable outcome demonstrates midterm technical success?
What specific, measurable outcome demonstrates final technical and operational success?
Who will evaluate these, and how?
What happens at each decision point: what does a pass enable, and what does a fail trigger?