Why I Stopped Adding Features and Started Deleting Them

Every consulting project arrives with a feature wishlist. Year one I worked through the list. Year two I started deleting from it before writing any code. The project outcomes improved on every metric that mattered.

The Wishlist Problem

Clients hand you a wishlist because they have seen too many demos. Every competitor feature, every executive request, every old idea from a deprecated roadmap ends up on the list. Building the full list is almost always wrong.

The First Question I Ask

Before writing any code, I ask: which three features would make the core user say this is better than what they have today? Three is the number because clients reliably agree on three and reliably argue about five.

The rest of the list waits. Not rejected. Waiting.

The Deletion Meeting

For larger projects I run a deletion meeting as the first working session. We go through the wishlist line by line and ask one question: what breaks if we ship without this? If the answer is nothing, the feature goes to a backlog and does not appear in the project plan.

About sixty percent of wishlist items get deleted in this meeting. Another twenty percent get deferred. The project that ships is half the size of the original ask.

What This Does to Timelines

Cutting scope in half does not halve timeline. It produces much better timeline outcomes because the remaining work is focused. Fewer decisions, fewer integrations, fewer edge cases. I ship in thirty to forty percent of the original estimate on projects where the deletion meeting happened.

The Client Response

Clients expect pushback when you delete features. They rarely get it from you. The pushback I get is actually relief. Nobody wants a bloated project. They want the thing to ship. Giving them permission to cut is the actual service.

The Discipline Cost

The hard part is your own head. As a builder you want to build the cool thing. Saying no to your own features is harder than saying no to client features. I keep a personal wishlist of things I would build if the project grew. Most of them never need to exist.

What Survived the Cuts

The features that survive deletion meetings share three traits: they map directly to a user action, they do not depend on other features, and they produce a measurable outcome. Anything that fails one of these three is a candidate for deletion.

Basecamp's Shape Up book describes a similar approach under different names.