Main idea

The profitability of a product description doesn't follow the number of cards written, it follows the completeness of a scope. An area described in full — invoicing, say — answers the questions of support, pre-sales, training and the developers working on it, and it answers them without anyone having to check elsewhere. Five half-described areas spare none of those checks: at every question, you have to reopen the code to find out whether the missing answer is really missing.

The reason is asymmetric. A partial description only adds value if you know where its boundary runs; otherwise its user always has to allow for it being silent, and the cost of verification comes back intact.

Hence the condition for putting it to use: finish one area before opening another. It runs against the natural slope of such work, which is to skim widely in order to show flattering coverage.

Why it matters

This gives a sequencing rule you can set against the pressure to show progress: the useful milestone is "this scope is finished", never "n per cent of the product is covered".

It holds for other knowledge projects — documentation, a glossary, a test base — whose use only begins the moment a user can stop doubting over an entire zone.

Nuances and limits

The reasoning assumes genuinely separable scopes. On a product where everything depends on everything, no area finishes without spilling over, and the rule becomes an arbitrary instruction to stop rather than a condition of profitability.

And broad coverage, even partial, keeps a value of its own: it serves to compare the angles with each other and to spot where the product is poorly understood.

Open questions

• How do you announce the boundary of a described scope so that a reader knows, without thinking, whether their question falls inside or outside it?