Is it worth building? The question that replaced "Can we build it?"
Ask any engineering team in 2026 whether they can ship a feature by Friday, and the honest answer is usually yes. Claude drafts the plan, Cursor writes the boilerplate and the migration, and the AI reviews its own pull request before a human opens it. What used to take a sprint takes an afternoon, and what used to take an afternoon takes twenty minutes and a decent prompt.
So why do so many products feel more crowded with features than they did two years ago?
Because "can we build it" stopped being the interesting question a while ago. Almost anyone can build almost anything now. The question nobody is answering is whether they should.
Building stopped being the hard part
For most of software history, engineering capacity was the bottleneck. Good ideas died in a backlog because there weren't enough hours to build them. Product managers learned to be disciplined about prioritisation because discipline was survival. You couldn't build everything, so you had to pick.
AI removed that constraint. Teams that previously shipped four features a quarter can now ship four features per week, which is great! But it removed something less obvious along with it. The slowness in building used to act as quality control. A weak idea had to survive weeks of expensive development before it shipped, and somewhere in those weeks someone usually noticed it was weak and killed it. Nobody was being particularly disciplined about this. The cost of building did the filtering for free.
Now that building is cheap, that filter has disappeared. Ideas don't have to survive scrutiny to get built. They survive by default. Nobody has to fight for a feature anymore. It just gets built, because someone thought it "might be nice" and the AI made it trivial.
AI won't tell you the idea was bad in the first place, either. It won't push back the way a skeptical cofounder or a tired engineer might. It agrees, it tweaks, it polishes. It's a pushover, programmed to please you and agree with you every time. Ask it to refine a mediocre feature and it hands you a more elaborate version of the same mediocre feature, often over-engineered with edge cases and options nobody asked for. It executes well and edits badly, and it will never once ask whether you should, which is how you end up with a dashboard carrying forty widgets nobody asked for.
What a shipped feature actually costs
Shipping a feature doesn't create value on its own. It gives the idea a chance to prove itself. Some features earn their place though most, if we're honest, do nothing much, and a few make the product worse.
Open up almost any app today and you'll find features that took real weeks of planning, building and testing, that shipped on time, that nobody ever complained about, and that almost nobody uses. Open the analytics and the see the usage is flat, sometimes literally zero. The team that built it moved on ages ago. Nobody killed it, because killing a feature takes a decision and nobody wants to be the person who admits the work was wasted, so it sits there, still shipped, barely maintained, still doing nothing.
Meanwhile it collects "rent" from your team, whether customers use it or not. It warrants maintenance when the underlying framework gets updated and a QA pass when something nearby changes. It needs support documentation, and then updated support documentation when it changes again. It needs an entry in onboarding, which makes onboarding longer, which reduces activation for the core thing you wanted new users to reach in the first place. It adds a code path that has to be considered every time someone touches that part of the system, forever, or until somebody is brave enough to delete it.
None of that shows up in the "we shipped this" celebration. It shows up six months later as "why does this take so long," and nobody can point at the feature responsible, because it is never one feature. It's the accumulated weight of forty small yeses that each felt easy at the time.
Nobody buys a product for its feature count
People buy products that solve a problem well, ideally without making them think hard. Don't Make Me Think was published 26 years ago, and applies even more today than it did at the time. A roadmap full of shipped features looks productive in a slide deck. Whether it made the product better is a different question, and it's the one that matters.
Notion has more features than almost anyone will ever use. So does Photoshop. So does Salesforce. The complaint you hear about all three, from experienced users, is never "I wish it did more." It's some version of "I wish I could find the thing I need without digging through the thing I don't."
Every feature you add makes the product slightly more powerful and slightly harder to understand. Add enough of them and more capable turns into more confusing, usually without anyone noticing where the line was.
The constraint moved to judgment
If building is no longer the bottleneck, the bottleneck has to move somewhere, and it moves to judgment. The question that separates strong product teams from busy ones is no longer whether they can build something. It's whether it's worth building, and worth maintaining for the next three years.
That second question is harder than it sounds, because somebody has to say no to an idea that is technically easy and probably wouldn't hurt. "It probably wouldn't hurt" is how bloat gets in. Nothing that ships ever looks dangerous on its own; it's dangerous once it piles up.
A better filter sounds like "Does this solve a real problem for a real segment of our customers? Would they notice and mind if we removed it? Are we willing to own the maintenance cost for as long as this product exists?" If the honest answer to any of those is no, the fact that AI can build it in an hour no longer matters.
The case for deleting things
This is the part teams find hardest to accept. Deleting a feature can create more value than adding one. A simpler product is faster to learn, faster to support, faster to test and faster to build on top of. Every feature you remove is one less thing standing between a new user and the moment they understand what your product is for.
Nobody brags about "removed a feature" in a release note. It's still often the highest leverage thing a product team can do in a given quarter.
Where that leaves us
The best products in the world aren't the ones with the longest changelog. They're the ones that feel like someone made a hundred decisions about what to leave out, so that the thing you actually came for is easy to find.
AI made shipping fast. It didn't make judgment fast, and it never will, because judgment was never a speed problem. It's a discipline problem, and discipline gets harder, not easier, when the cost of saying yes drops to almost nothing.
Shipping "volume" won't benefit the teams that do well over the next few years. What will separate them is the habit of asking, before every feature, a question that used to answer itself, is this actually worth building?