Internal Release Cadence: Monthly Feedback Loops Before Customer Release

Definition

An internal release is a delivery of working software to the organization (not external customers) that demonstrates real progress and elicits feedback from sponsors, stakeholders, and end-users. Rothman prescribes at least one internal release per month as a minimum cadence. External releases — delivering to customers — are business decisions and may occur less frequently. The distinction matters: internal releases drive learning and build organizational trust; external releases are constrained by business factors (sales cycles, regulatory approval, customer readiness) that the program team doesn't control.

In the Book

Rothman argues that internal releases create a rhythm the program can depend on and trust. If teams deliver only every quarter or less, no one understands program status. If teams release internally monthly but customers see no value until quarter-end, the organization builds confidence and the teams get continuous feedback on what they are building. Internal releases also serve the feature teams: they provide proof that the product works end-to-end, they expose integration issues early, and they make visible what is done versus what remains.

The book warns against the trap of large batches. If the program waits for "everything" to be ready before an internal release, releases become infrequent and risky. Instead, teams should size features small so that something releasable exists every month. This requires defining Minimal Viable Products (MVPs) or Minimally Indispensable Feature Sets (MIFS) for each release — what is the smallest set that provides value or learning?

Why It Matters

Internal release cadence solves a program-level visibility and trust problem. Without regular internal releases, sponsors cannot see progress and fall back on asking for estimates and detailed plans (which programs cannot reliably provide). With monthly internal releases, even if small, the organization sees tangible progress and begins to trust the program's ability to deliver. Teams also stay in better synchronization — if the program integrates and releases monthly, dependencies become visible and manageable. If releases are infrequent, integration problems pile up and become catastrophic.