Most products are judged at the moment someone first clicks through them. That moment matters. It is also a poor definition of done. The people who will live with the system after launch need a different path: how it is operated, how it fails, and how it is changed without fear.
The interface is the easy story
Screens photograph well. They go in a deck. They make a launch feel real. The operational path does not: a permission that was never designed, a job that only one person knows how to restart, a log that says nothing useful when something is already wrong.
- Who can do the dangerous thing, and who can undo it.
- What happens when the obvious action is taken twice.
- Where a person looks when the system is quiet but wrong.
- How the next engineer changes a rule without inventing the product again.
If you cannot hand the work to someone who was not in the room, you have not finished it. You have only launched it.
Write the path you will actually run
You do not need a novel. You need the smallest set of facts that lets a calm person operate the thing on a Tuesday. A type can hold that better than a slide.
type Handover = {
whoOwnsIt: string;
howItFails: string;
howToChangeIt: string;
};
function isFinished(release: { handover: Handover | null }) {
return release.handover !== null;
}Operate
PATH
What to refuse
Refuse a definition of done that ends at a screenshot. If the brief has no room for operation, the estimate is a guess about a different product. Put the unglamorous path on the same list as the first screen — then the work is honest.