Fire the Feature You Shipped Last Week If Nobody Reuses It

Shipping is not proof that a feature deserves to stay

Indie roadmaps have a predictable problem: almost everything moves in one direction.

A customer asks for something. You build it. The changelog gets longer. The navigation gets busier. Eventually the product becomes harder to explain than the original idea.

The missing habit is deletion.

A feature that was used once may have been a useful service request. A feature that people repeatedly use without being reminded is part of the product.

Those are different outcomes.

A launch is only the beginning

Founders often treat a merge or launch as evidence that an idea worked.

Users do not.

A customer might request an export, use it once to finish a report and never return to the screen. The feature solved a real problem that day, but that does not necessarily mean it belongs in the permanent product.

Compliments are weak evidence too.

“This is amazing” can simply mean “thank you for fixing my problem.”

If you only add features, the product eventually becomes a museum of old emergencies.

Define reuse before you ship

Give every feature a simple success condition.

For a weekly workflow, repeated use within a month might be enough. For a monthly workflow, use a longer window.

The exact number matters less than having a definition before the feature launches.

Also describe the job in the customer's words.

“Send the Friday exception report to finance” is measurable.

“Advanced insights” is not.

Watch three signals

You do not need a giant analytics dashboard.

After shipping, look at:

1. How many paying accounts tried the feature?
2. How many used it again without a prompt?
3. How many still use the old workaround?

The answers tell different stories.

High trial with low reuse usually means the feature was interesting but not habitual.

Reuse from one customer may mean you built a custom tool.

If customers keep using the old workaround, the new feature probably did not actually replace the job.

Give features a probation period

Do not give every new feature a permanent place in the navigation on day one.

Start it quietly. Give it a settings link or place it inside the workflow where the need appears.

Then put a review date on the calendar.

At that date, choose one of three outcomes:

• keep it because several customers repeatedly use it
• hide it because one customer still needs it
• remove it because nobody came back

Hiding is useful. You can support an existing customer without teaching every new user that the feature is part of the core product.

Do not let one customer redesign the product

The most dangerous feature request is often attached to a customer you really want to keep.

Their request may be completely reasonable for their business and still be wrong for the product.

If the request is valuable, treat it as paid setup or custom work first.

If several unrelated customers ask for the same thing, you have stronger evidence that it belongs in the core product.

Keep the exact language customers use. Similar words are not necessarily the same problem.

Remove features with a replacement path

Deleting a feature does not have to mean abandoning the person who relied on it.

If an export disappears, document the alternative way to get the data.

If a dashboard disappears, keep the important numbers visible somewhere simpler.

If an integration goes away, document the manual process and offer help when appropriate.

Tell the customers who actually used the feature. There is rarely a reason to announce a dramatic farewell to everyone.

And remove the feature from your sales copy at the same time.

Use the recovered time well

The point of deletion is not to have fewer features for the sake of it.

The recovered time should go toward the work customers already repeat.

Make the first successful run faster. Improve an empty state. Remove a step from a common workflow. Fix something that causes support tickets.

That work may not produce a launch announcement.

It can still make the product substantially better.

Try a two-week cleanup

Start with everything shipped in the last 60 days.

Mark each feature as:

• reused
• one-off
• unknown

If you cannot measure it, investigate it before assuming it worked.

Then hide or remove a couple of weak features and simplify the navigation around the jobs customers actually repeat.

This is product work even though nothing new appears on the homepage.

The goal is not to build less because ambition is bad.

It is to stop last week's favor from becoming next year's complexity.

Practical playbook

For Fire the Feature You Shipped Last Week If Nobody Reuses It, turn the main idea into a small operating decision. Identify the customer or user, the problem being solved, the signal that proves progress, and the next action that can be tested.

Decision map

problem → evidence → smallest action → result → next decision

Checklist

• Define the problem in one sentence.
• Use evidence instead of assumptions where possible.
• Start with a small test.
• Measure the result.
• Document what changed and why.

Editorial note

This practical section turns the article central idea into something a founder can test, measure, and revisit. It is deliberately separate from the main argument so readers can distinguish the article analysis from the implementation checklist.