The most important product decision is what you don't build
TL;DR
Liam Nugent argues that product teams should refuse generic platforms like in-app document hubs and notification centres. They should also keep deleting features. The cost that kills you is years of maintenance, not the build. Showing stakeholders that running cost is what gets them to let go.
The article
- In consumer finance apps, a document hub or a bell-icon notification centre starts as a small fix for legacy PDFs and compliance rules. It grows as each stakeholder adds one more thing. Soon the team has rebuilt a bad Google Drive or Gmail.
- Nugent argues that the build cost doesn't persuade people to drop such projects. Laying out the running cost over years does, including breakage from every iOS and Android release.
- Killing the platform still leaves the communication problem. So Nugent takes each use case on its own. He usually picks something simple or already existing, even if imperfect. He has also seen a notification centre get built that couldn't carry the message it was built for.
- Organisations and human cognition both undervalue removal. Gerry McGovern found that cutting 80 to 90 percent of a site's content raised sales and lowered support calls. In Nature, Klotz et al. showed that people overlook subtractive fixes even when they are better.
- Cheap building with AI agents is no reason to build more. Nugent would point agents at pruning and maintenance instead.
- Nugent's model is Steve Jobs' 1997 cut of Apple down to four products in a two-by-two grid. The point was pooling engineers on a few things, not a permanent cap on the product count.
Why it matters
Short and readable in five minutes. Product managers and engineering leads fighting a document-hub or notification-centre request will get the running-cost argument. They also get the McGovern and Klotz sources to cite, which the summary only names.
The discussion
A friendly thread of people who already agree, so most of it is war stories and tactics rather than debate. The live arguments were about why saying no goes unrewarded and how to make a rejected idea stay dead. Some also asked whether one of the article's two examples was a bad pick.
Nobody is on the hook for maintenance
The most-developed point was that maintenance, not scope creep, eats team capacity, and the people who add features rarely pay for them. alentred compared software to abandoned civic projects in 1960s towns and said rejecting work makes engineering look like a buzzkill. bunderbunder blamed short tenures, citing a product owner who said outright that upkeep would be some junior PM's problem after launch. piker and bmitc doubted the town analogy, blaming textile jobs moving to Asia and the decline of small-town America instead.
They’d have questions to answer if they yanked features that had already been prototyped, and besides, as soon as the product ships they would move on to a new initiative and any ongoing maintenance burden would be some less senior PM’s problem.
I had countless occasions of successfully convincing product teams and boards to abandon or rescope the project, and although I am convinced it did good for the companies in the end - the engineering department ends up being a buzzkill :shrug: .
"Custom reporting" is the classic vague request
The biggest subthread took one example, customers asking for "custom reporting", which most read as a sign the app misses a specific question. The fix is to ask what the question is and build that. Terr_ said reporting can stand in for product design, like logging a field so support can restore old values instead of building revisions. Others said it just means "give us the raw data for Excel" and suggested an API.
He said that a majority of the time people are asking for custom reporting tools, it’s because the app’s built-in tools for sorting/filtering/aggregating data aren’t answering the questions they are asking.
Once we did all this after a few months, come to find out the PM requesting all this missed that what users wanted was one number in hundreds of rows, and sorting so it would show on top...
Who gets to say no, and how to make it stick
mmonaghan doubted any single person knows what "makes the boat go faster", and Retric said programmers make these calls anyway, since nobody else cares. A PM asked how to kill an idea that keeps coming back through brainstorms, sales calls and sprints planned while they're on vacation. A former PM said to close it as a ticket with the reasoning attached, and merge repeats into it. Then offer the feature's cost and blame to whoever pushes it.
I can say no, and explain why, but the idea will keep coming back. Brainstorming session? They raise it again.
If you as the PM is responsible for the product, it's market fit and its cost, but they want to add something, turn the cost and responsibility over to them.
Build it cheap to find out what not to build
Several readers argued that fast prototypes, now cheaper with LLMs, are how you learn what to drop. bob1029 builds a deliberately crappy 90-minute version and says it has shrunk multi-month roadmap items to a day. Others saw cheap building as the trap itself and asked what they would actually want to maintain. Timeboxing came up as the fix for never knowing when to stop.
If the 90 minute rapid prototype doesn't make sense, you didn't waste that much time. It's a lot easier to prove things to stakeholders this way too.
Today, was thinking about 1) what do I actually want to build AND maintain?
User expectations and commodity features
Some comments complicated the "just don't build it" line. pedalpete said sleep-tracking users expect a hypnogram and sleep score that tell them little, so the question is how to change expectations. jillesvangurp said features like sign-in add no value but subtract plenty when done badly, and _the_inflator called "not building" a pose without a product strategy. Pxtl backed the article with outages caused by a hastily added document store, notification system, and once user avatars.
I've literally had to fix outages in products where the failure was a "document store" or a "notification system" haphazardly slapped on by a student under direct supervision of a PM with no experienced technical leadership.
A good example is sign up and sign in functionality. You have to have it. It doesn't do anything valuable. But if you do it poorly it removes value from your product.
Consensus
Saying no and removing features pays off, and the main reason is the long tail of maintenance. Organisations reward launches, so the people who cut scope rarely get credit.
Dissent
Some argued that the problem is building the wrong thing, not building at all. They added that a no only works as part of a product strategy. Others said who decides is murkier than the article suggests, and that user expectations can't simply be ignored.