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 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.
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 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.