“One More Feature” Is Usually Not a Small Change

One of the most common things you hear after a project has already started is:

“Let’s add one more feature.”

Sometimes, it really is a small change.

Other times, that same sentence quietly opens up an entirely new piece of work.

The problem isn’t the request itself.

The problem is that “just a small addition” often isn’t treated as a change in cost, timeline, or scope.

New Requests Are Not a Bad Thing

New ideas appearing during a project is completely normal.

Once you see the user flow, run a demo, or start working with real data, new needs often become visible.

I don’t automatically reject these requests.

But I also don’t automatically put every new request into the existing project scope.

Because when every “small addition” is accepted without clear boundaries, the product slowly turns into something different from what was originally planned.

I Start With These Three Questions

When a new requirement comes in, I usually look at three things first:

• What specific problem does this solve?
• Is it part of the agreed first version, or does it expand that scope?
• If we don’t do it now, will the product actually fail — or would it simply be nice to have?

If the answer is “it would be nice to have,” that doesn’t mean it’s a bad idea.

It may simply mean that it doesn’t belong in the current version.

Why “Small” Things Become Big

Adding one button, one field, or one status can look simple on the surface.

But behind it, there may be:

• new business rules
• compatibility with existing data
• impact on other workflows
• additional testing and delivery effort
• new user behavior that needs to be introduced

So the question isn’t really:

“How long will it take to write the code?”

The real question is:

“Does this change the boundaries of the system?”

That’s why when I hear “one more feature,” I look at the scope before I look at the implementation effort.

What Goes In Now, What Comes Later?

For me, a good approach looks like this:

• Protect the promise of the first version.
• Keep the core workflow working.
• Capture new ideas in a backlog instead of putting everything into the current release.

Some requests genuinely need to be done now — without them, the product would feel incomplete.

Others belong to the next stage.

Being clear about that distinction matters.

Otherwise, the project never really ends.

It just keeps getting longer.

Keeping Boundaries Doesn’t Mean Saying “No”

Maintaining scope doesn’t mean stopping the client or blocking the team.

It means finishing what was agreed upon and treating the next piece of work as a separate decision.

Otherwise, every week brings another “small” addition, while the original agreement quietly loses its meaning.

For me, a good outcome isn’t about shipping as many features as possible.

It’s about delivering a usable version that solves the problem we originally promised to solve.

Everything else can be a separate decision.

A separate scope.