Giving a regulatory update executives will actually use

Most regulatory status updates get skimmed once and forgotten, because they report on activity — what got submitted, what got filed, what meeting happened — instead of the two things a leadership team actually needs from you: what has changed, and what has to be decided now.

Report status, not activity

“We submitted our response to FDA's request” is activity. It tells a reader that work happened, not whether the program is on track, and not whether anything about the plan has changed. “We're on track for a decision in the fourth quarter, assuming FDA's review of our response follows the pattern of a typical first-cycle request; the one open risk is a testing gap our attorneys are still evaluating” is status — the same underlying fact, reframed around what the reader needs to act on. A status update earns its place on someone's calendar by naming, every time: the current milestone and what comes next, a target range with its assumption stated rather than a bare date, anything that needs a decision from leadership now, and any risk that's new. Everything else — the internal review comments, the restated history from three updates ago, the technical detail that doesn't change the ask — belongs in the file, not the update. This is the same discipline behind explaining a regulatory decision to a non-regulatory audience: the reasoning has to survive being compressed without becoming wrong.

A submission review ends in a decision, not a date

It's tempting to talk about a pending 510(k) the way you'd talk about a construction project, with a schedule that slips or holds. The review doesn't actually work that way: as the mechanics of a 510(k) review show, it runs on FDA's internal process and ends with a determination — a substantial equivalence letter issued under 21 CFR 807.100, or a not-substantially-equivalent finding — not a date FDA has promised anyone. Any timeline you give leadership is your own estimate, built on how similar reviews have gone and how quickly your team can turn around a request if one comes in. Saying that plainly, and naming the assumption the estimate rests on, is more honest than a single date and easier to stand behind when the estimate turns out to be wrong in either direction. It also means the file itself — kept the way a regulatory decision log keeps it — is what you're actually reporting from, not your memory of how the last cycle went.

None of this is about hiding uncertainty — it's about putting it where the reader can use it. An update that reports status instead of activity, names its assumptions instead of hiding them in a date, and leads with the decision instead of burying it is the kind of update that gets read the next time, too.