Choosing what not to build
Why it's so hard
Every request sounds reasonable on its own. The problem isn't the single feature but the accumulation: each addition brings code to maintain, a screen to learn, and an edge case that will break something else in six months. The cost of a feature isn't the week of development — it's all the years after it.
Three filter questions
Who asked? One loud customer is not a market. Ask how many users will touch this in a week.
What happens without it? If the answer is “a bit less convenient,” it doesn't go in the first version.
What does it replace? If the task list has a fixed length, every entry requires an exit. That is a healthier conversation than “let's add this too.”
How to say no
No comes with a reason and a place: “not in this version, because the metric we're chasing is handling time and this doesn't affect it. We'll come back to it after the first measurement.” Whoever understands the priorities stops arguing over them.
Keep a visible list of deferrals. It prevents the recurring question, and it's the first place to look when time frees up.
Going deeper
A product that ships with ten capabilities that work perfectly beats one with forty mediocre ones. In code too: every logical branch adds a path to test. Cutting scope isn't only a business decision — it's the cheapest architectural decision you'll make.