A useful release can still be incomplete

You can release something useful before it does everything you intend. The people using it need to know about omissions that would change their decision to rely on it. That is the responsibility this principle places on the person handing over or releasing the work.

The missing attachment

Imagine a project-management application adding an export feature. It can download the rows in a project table. Uploaded documents and images aren’t included yet.

For a user who wants to analyze task counts, that export may be enough. For a user planning to close the account and preserve the project, it is incomplete in a consequential way.

If the button says “Download complete archive,” the application has made a promise it doesn’t fulfill. A technically successful download can lead the user to delete the originals, believing the attachments are safe. Calling the feature a beta elsewhere on the site doesn’t explain this particular omission.

A sound release makes the actual boundary clear at the point of use: “Export table rows. Uploaded files aren’t included.” The team checks that the included rows and fields export correctly. If users need a complete archive, the interface directs them to the steps necessary to preserve their files, or explains that a complete export isn’t available.

The release can proceed for the use it serves. The unsupported promise cannot.

Disclosure has to reach the decision

A note deep in a project log is useful to maintainers. It does little for a person deciding whether to delete an account. Put a consequential limitation where the affected person will encounter it before acting.

The same reasoning applies inside a team. A colleague who hears “migration finished” may retire the old service. If only the test migration is complete, say that when handing over the result. The colleague shouldn’t need to infer unfinished work from a private conversation or an open ticket with an unclear title.

The useful test is whether knowing about the omission would change someone’s use of the work, their timing or their next step. That keeps attention on material gaps. A release note listing every task in the backlog can obscure the limitation a person most needs to see.

What the principle doesn’t require

“Nothing ships silently incomplete” cannot mean describing every feature you might build. An agreed purpose gives completion a boundary.

A paper prototype shows where the literal wording goes wrong. It may deliberately lack storage, permissions and error handling because the exercise is about whether a proposed sequence of screens makes sense. If participants understand that they are examining a prototype, listing every missing production feature would distract from the work. Make the purpose clear and conduct the exercise; don’t build or document a full product to justify showing a sketch.

Unknown defects create another limit. No honest release note can enumerate problems nobody has found. The obligation is to disclose known material gaps, make claims supported by the checks performed and correct the record when new information changes it. “We didn’t know” should describe a real knowledge boundary, rather than excuse a check the team had agreed to perform.

Disclosure also doesn’t make every release acceptable. If an omission prevents the work from serving its stated purpose safely, a warning alone is insufficient. Change the release boundary or finish the missing work before asking people to depend on it.