Every feature added to a product is a feature the user has to learn, navigate around, or ignore. The compounding cost is real, and it shows up as products that started lean and became bloated, abandoned by the users they were originally built for. The one-job test is the simplest discipline for keeping that from happening.
The tax is paid by everyone, not just the users of the feature. Every addition widens the navigation, lengthens onboarding, adds a settings surface, complicates every future design decision ("how does this interact with...?"), and slows the codebase. A feature used by 4% of accounts is paid for, in attention, by the other 96%. This is how products die of success: each individual yes was defensible, and the sum is a product nobody would choose today.
The test
Before any feature is built, you must be able to write, in one sentence, the single job this feature does for the user. Not what it enables, not what it adds, but the one job. If you cannot write the sentence, the feature is not yet a feature; it is a vague impulse. Wait until you can.
The sentence has a grammar worth enforcing: a specific user, a specific situation, a specific outcome. "When a founder finishes a campaign, this shows them which segment replied best so the next campaign starts from evidence" passes. "Adds analytics" fails; so does "gives users more flexibility" and anything containing "enables," "supports," or "allows," because those verbs describe capability, not a job. The tell of a failing sentence is that it needs "and": two jobs joined by an and are two features, and each must pass alone.
What changes when you apply it
Most feature requests fail the test. That is the point. The features that pass are the ones with a clear user job, and they get built. The features that fail get refined into something with a clearer job, or get dropped. The team's velocity goes up, not down, because effort is no longer spread across unclear work.
The sentence keeps working long after the gate. It becomes the design brief (every screen either serves the job or goes), the copy source (the feature announcement writes itself), and, most valuably, the success metric: a feature whose job is written down can be measured against it a quarter later. Did the users in that situation get that outcome? If not, the feature failed its own stated test, which makes the kill conversation short and blameless, and feeds the graveyard a clean entry.
The harder version of the test
Once the feature is built, ask: what would we have to take away to keep doing this one job better? Often the answer is something else you already built. Cutting is part of building.
Run that harder version on the product as a whole once or twice a year: list the top ten surfaces and write each one's job from memory, without looking at old docs. Surfaces where nobody can state the job crisply are the bloat, found systematically rather than argued about. The products that stay beloved for a decade are not the ones that added the most; they are the ones where every remaining piece still knows exactly what it is for.