How to Run a Mock Study Section Before You Submit Your NIH Grant

Why a Mock Study Section Beats Informal Feedback

Most of us collect feedback the same way: email the draft to a mentor, a lab-mate, maybe a collaborator, and wait. The comments that come back are usually kind, usually about wording, and usually from people who already believe in the project. That's useful for typos. It's nearly useless for predicting how a panel of strangers with 10 to 15 other applications on their desks will react.

A mock study section changes three things. Readers have to commit to criterion scores before they talk, so nobody can quietly soften a concern. They have to defend those scores out loud, which surfaces disagreements you'd otherwise never hear. And they read with the same limited time a real reviewer has, so you find out what survives a skim. None of this guarantees a better score. Nobody can promise that. But in my experience it reliably exposes the two or three problems that would have shown up in your summary statement anyway.

Who to Recruit (and Who to Skip)

Aim for four to six readers. Fewer than four and one strong personality dominates; more than six and the meeting turns into a seminar. Mix them on purpose. You want at least one person who has served on a study section (an ad hoc stint counts), one who works in an adjacent field and has no stake in your subfield's politics, and one who is a strong writer regardless of topic.

Skip your direct collaborators and anyone who will be named on the grant. They know too much, so they fill in every gap without noticing. Skip, too, the colleague who gives only praise, and the one who rewrites every sentence in their own style. If your institution runs a formal internal review program, use it, but don't treat it as a substitute for readers you pick yourself.

Ask each person to take a role. Assign two as primary reviewers, one as a third reviewer, and the rest as general panel members who read the Specific Aims and skim the strategy. That mirrors the real distribution of attention, where only a few people read the whole file closely.

What to Send Reviewers and When

Send the application as it would be submitted: Specific Aims, Research Strategy, the relevant biosketch, and a short note on the funding opportunity and the institute you're targeting. Don't send a half-finished draft with "ignore Aim 3, I'm still working on it." Reviewers will ignore your instruction and spend their energy on the gap. If one section truly isn't ready, delay the mock review.

Timing matters more than most people admit. A useful rule of thumb is to hold the meeting four to six weeks before the due date, which leaves room for real experiments or reanalysis if the panel says your preliminary data don't support Aim 2. A mock review two days before submission produces anxiety and cosmetic edits, not better science.

Give readers a one-page template. List the five scored criteria under the simplified framework (Importance of the Research, Rigor and Feasibility, and Expertise and Resources, plus the additional review considerations), and ask for a 1 to 9 score on each factor, an overall impact score, and three bullet strengths and three bullet weaknesses. Collect the sheets before the meeting. Our simplified review framework guide explains how those factors map to what real reviewers write.

Running the Meeting Like a Real Panel

Keep it to 60 to 90 minutes and act as the applicant who is not allowed to speak. That last rule is the hard part. Real applicants can't jump in to explain what they meant, and neither can you. Take notes, nod, and save every clarification for afterward. If a reader misunderstands your Aim 2, the misunderstanding is the finding.

Pick a chair who isn't you. Their job is to keep time, stop tangents, and force the group to rank concerns by severity. A list of 25 equally weighted comments is hard to act on. A ranked list of five is not.

Turning Critiques Into Revisions

Within 48 hours, while it's still fresh, write your own mock summary statement. Group every comment into three buckets: fatal (would plausibly cost several points of impact score), fixable (a clearer figure, a added control, a reworded aim), and noise (stylistic preferences, comments that only one reader raised and nobody supported). Be honest about the first bucket. Authors tend to reclassify fatal concerns as misunderstandings.

Count agreements. If three of five readers flagged the same issue, treat it as real even if you think they're wrong. Reviewers on a real panel won't care that you disagree; they'll care that they didn't see an answer on the page. When a concern is about a misunderstanding, the fix is almost always to add the answer where the reader looked first, not buried in the Approach.

Then decide what you can really change in the time left. A missing power calculation is fixable. A project whose central premise lacks support may need another quarter of data, and that could mean missing this cycle. It's a painful call, but a deferred strong submission usually beats a rushed weak one, especially if you're weighing the odds of an A1. Our guide to the A0 vs A1 decision goes into that tradeoff.

Pitfalls That Waste the Exercise

Frequently Asked Questions