Scope Is Your Most Powerful Tool

There is a belief in software that nobody says out loud but almost everyone holds: that doing less is a sign of weakness. That if you cut scope, you failed at planning. That the ideal product existed from the beginning and what you shipped is just a reduced version of that ideal.

It is a belief that destroys teams, delays launches, and produces software nobody uses.

Scope Is Not Sacred

When a requirement lands in your lap, you need to understand something fundamental: nobody knows exactly what they need until they have it in front of them. Not the user, not the PM, not you. The requirement is a hypothesis. The code you write to fulfill it is an experiment.

Treating it like an inviolable contract is a mistake.

The best engineers I know are not the ones who deliver everything they are asked for — they are the ones who identify which part of the requirement generates 80% of the value and deliver that first. The rest can wait.

TIP

Before starting any feature, ask yourself: what is the smallest part of this that would test whether we are heading in the right direction?

The Difference Between Cutting and Compromising

Not all scope can be cut. There is a difference between cutting smartly and simply delivering less.

Cutting smartly means identifying parts of the feature that:

• Nobody will use in the first 30 days
• Add technical complexity without adding clarity for the user
• Depend on assumptions you have not validated yet

Compromising the vision means removing the part that makes the feature worth building.

If you are building a notification system and decide not to implement emails because it takes time, and in-app notifications are enough to validate — that is smart cutting. If you decide not to implement the trigger logic because it is complex and send random notifications instead — that is compromising the vision.

The difference is whether what you ship can answer the question you started with.

How I Negotiate Scope in Practice

When I receive a large ticket, I do something that sometimes makes people uncomfortable: I ask what it is for. Not “what are the technical requirements” — but what user behavior do we want to change with this.

That answer gives me north. Everything that does not directly contribute to changing that behavior is a candidate to cut.

Then I split the work into three lists:

1. Must have — without this the feature does not serve its purpose
2. Should have — adds real value but the feature works without it
3. Nice to have — nobody will miss it at launch

The initial launch contains only list one. Lists two and three live in the backlog, prioritized by what you learn after shipping.

The key is that this decision gets made before writing code, not when you are three days in and realize you are not going to make it.

The Problem with “It Is Almost Done”

“Almost done” is one of the most expensive phrases in software engineering. A feature that is 90% done does not deliver 90% of the value — it delivers zero, because it is not in production.

Software does not work in percentages. It works or it does not.

When someone on your team says something is “almost done,” the right question is not “when will it be ready?” — it is “what can we cut so this ships today?”

Why This Matters More in Small Teams

In a large company, you can afford to have half-finished features sitting in the backlog. There are resources, there is time, there are people whose job is to manage that.

In a small team, every incomplete feature is debt — code debt, attention debt, mental energy debt. Every “almost done” thing takes up space in someone’s head.

Shipping less but complete frees the team to think clearly. It gives you real data on what to build next. And it teaches the team that finishing matters more than starting.

The skill of cutting scope without losing vision is not something you learn from a tutorial. You learn it by shipping things, seeing what gets used and what does not, and being honest about the difference between what you want to build and what the user needs right now.

It is uncomfortable at first. Eventually, it becomes the most natural thing in the world.