A feature is a promise the company keeps for as long as the product lives.

Each one is paid for in every release that follows.

Durability is decided by what never ships.

Going deeper

A feature is easy to count on the day it launches and hard to count afterwards. Once customers rely on it, it becomes part of what the product promises, and every later change has to respect it.

Why it matters

Each feature adds surface area. It needs tests when the code around it changes, documentation when the product evolves, support when a customer has a question, and care whenever the architecture moves. None of that appears on the roadmap, yet every release carries it.

This is why the products that age well tend to feel focused. Their teams spend their capacity deepening the few promises that matter, instead of maintaining many that matter little.

A practical method

Write the promise before the spec. State in one sentence what the company commits to keep true for customers once the feature ships.
Name the lifetime owner. Every feature has a team that will maintain it after launch, decided before work begins.
Price the carry. Estimate what the feature adds to testing, support and future changes, alongside what it costs to build.
Keep a record of what was declined. A short list of good ideas the team chose not to ship, with the reason, makes the next decision faster.
Review usage after launch. Features that customers do not use become candidates for removal, with a clear plan for anyone who depends on them.

What it looks like in strong teams

Product reviews start with what the company is promising. Engineers can name the owner of any feature in the product. The roadmap shows removals as proudly as additions. The product feels calm to use, because every part of it is there for a reason.

Fewer promises, kept well, are what make a product last.