The most important product decision is what you don’t build - Liam Nugent

The most important product decision is what you don’t build

14 Sep 2026

Ask a team what they shipped this year and you’ll get a list. Ask what they killed and the room goes quiet.

There are two things I’ve tried to take a hard pass on when working on consumer-facing financial services apps.
A “document hub”.
And a “notifications centre”.
You can picture both without any help from me. To my mind they’re both examples of letting the organisation off the hook at the expense of the user. Although it’s fair to say that plenty of users have now been trained to expect these things, and to know roughly how they work — even though they’re crap.
The problem underneath is real enough. The business has legacy systems that produce PDFs — letters, statements, that sort of thing — because originally they’d have been sent out in the post. Compliance experts will also talk to you about “persistent communications channels”. So you need somewhere in the app to put all of that.
The lazy solution is a document hub. A list of files you can select and open.
Seems simple.
Except every stakeholder involved wants to do a Columbo and add just one more thing. By the end you’ve essentially rebuilt Google Drive, with tagging, archiving, printing and sharing across several channels, each with its own quirks. Not to mention clearing the security and authentication hurdles so the right person sees only the right documents. And so on, and so on.
And that is just to build the thing.
Never mind the overhead you’ve created to maintain it, month after month, year after year, as each iOS release cycle comes round and some foible you were relying on to prop up a piece of functionality gets removed unilaterally by Apple. Or Google, or Microsoft, or Amazon.
The notifications centre is the same story with a different opening line. A stakeholder asks whether we could just have a bell icon with a little red dot in the top right corner of the screen. Give it a few months and you’re building a bad Gmail clone.
Showing people the bill
I’ve come up against both of these several times now. It is not easy to get people to let go of a mental model they’re holding in their head, particularly when a customer focus group goes some way to validating it. The cliched old Henry Ford line comes to mind — if you’d asked people what they wanted, they’d have said faster horses, not a motor car.
What I’ve found actually works is illustrating the running costs. Not the build cost. The running costs, laid out over years. That tends to bring people back from the brink.
But killing the platform doesn’t make the original problem go away. How do we communicate with our customers in a way that suits them and meets the legal obligations on our side?
The answer I’ve come back to every time is to take each use case on its own merits. Be rigorous about what actually needs to be said, and when. Then be ruthless about whether it needs a whole platform built first. It’s the same test I keep applying when picking the right problems to solve — does it make the boat go faster?
Most of the time — not always, to be fair — the answer is to use something simple, or something that already exists, even if it isn’t perfect.
Resist, resist, resist the temptation to build a one-size-fits-all.
I’ve even seen the notifications centre idea get built, and then the intent of the original message couldn’t be met by the thing that had been built to carry it.
So my advice comes in two parts. Be extremely choosy about what you let be added to your system. And be militant about taking things out.
Nobody gets promoted for deleting things
The second part is much harder than the first, and it isn’t simply cowardice. Gerry McGovern has been saying this for a long time:

Those who create and launch are the people who are rewarded and looked up to because we still have a culture that rewards the production of things over everything else. To review, to maintain, to remove—this is all seen as lesser work.

His Top Tasks work found that stripping roughly 80 to 90 per cent of a site’s content made companies sell more, cut their support calls and helped people find what they were after faster. Removal as the improvement itself, not the tidying up afterwards. I’ve made the small-scale version of this argument before, about deleting the FAQ page.
And it runs deeper than the org chart. Klotz and colleagues, writing in Nature, ran eight experiments and found that people systematically overlook subtractive changes, even when removing was obviously the better move. Additive ideas arrive quickly and cheaply. Subtractive ones cost real cognitive effort. So we are hard wired for this.
Which means spending the brain power to work out what success genuinely is. And success is usually something out there in the world of the customer, rather than something in here, in the world of the organisation.
But building is nearly free now, isn’t it?
DHH is thoroughly delighted about endless execution — in the age of agents, every idea, every hunch and every experiment is within immediate reach.
I think it’s easy to misunderstand that as an argument for making more stuff all the time.
Using agents to do the pruning seems like the smarter move to me. To do the maintenance. To remove things judiciously, and more carefully than anyone is going to manage by hand.
Stewart Brand’s Maintenance of Everything sits on the paradox that maintenance is absolutely necessary and also entirely optional.
Optional until it’s essential, more like.
The elephant in the rollneck
The elephant in the room, wearing a custom-made Issey Miyake black rollneck, is of course Steve Jobs’ 1997 matrix. Two consumer products, two pro products, and one stellar product in each box.

Steve Jobs’ 1997 product matrix
A two-by-two grid. The columns are Consumer and Pro, the rows are Desktop and Portable. Consumer Desktop is the iMac, Pro Desktop is the Power Macintosh, Consumer Portable is the iBook, and Pro Portable is the PowerBook.

Consumer
Pro
iMac
Power
Macintosh
iBook
PowerBook
Desktop
Portable

Four boxes. One product in each. Everything else cancelled.

He then shut down all the other product lines people were working on. That pooled the engineering talent instead of spreading it thin. It was a brave move, and it did the trick.
Apple are up to something like 52 different products and services at the last count, so the end game was never to only sell four things. The point was to focus the organisation on the most important ones, so they didn’t misspend the opportunity cost that allowed them to become one of the biggest corporations in the world.
One thing at a time. Une chose à la fois.
(I’d have written a shorter post, but I couldn’t work out what to take out.)

Tags:

product management
strategy
Digital waste

← All posts

About the author, Liam Nugent has spent the last 15 years building digital products — as a founder, inside large enterprises, and now leading product across millions of users at a tier-one UK bank. He's interested in how organisations make good decisions, why simplicity is harder than it looks, and what happens when strategy actually meets reality. He lives in Glasgow and recently released Lanark, a typeface inspired by Alasdair Gray.

Navigation

Home
Archive
Side Projects
About

Search:

Copyright © 2018–2026 Liam Nugent.
All rights reserved.
Accessibility Statement
Privacy Statement
Back to top

The most important product decision concerns what is deliberately omitted from a system rather than what is built. The author argues against creating complex, monolithic solutions, citing examples such as a document hub or a notifications centre, suggesting these are instances of allowing the organization to evade responsibility for the user experience. The idea behind these examples is that building these features often leads to significant maintenance overhead, as external dependencies, such as operating system updates, constantly necessitate upkeep, creating long-term costs that are ignored in favor of perceived immediate gains.

The core conflict arises when trying to implement necessary functionality. For instance, a document hub requires functionality far beyond simple file listing; achieving necessary features like tagging, archiving, printing, sharing across multiple channels, and robust security demands rebuilding complex systems akin to Google Drive, which developers must then maintain against external platform changes. Similarly, trying to provide simple notifications results in building complex clones of existing applications rather than solving the underlying communication requirement. The author posits that attempting to validate mental models through user focus groups often fails because users prefer familiar patterns, much like the observation that people prefer faster horses over motor cars, suggesting that solutions must align with perceived user needs rather than internal organizational desires.

A more effective approach is to focus on illustrating the long-term running costs of a product over years rather than just the initial build costs to motivate change. The author advocates for a strategy based on assessing each use case on its own merits, demanding rigor in determining exactly what information needs to be communicated and when. This involves being ruthless in determining whether a comprehensive platform is necessary before proceeding with development, testing this principle by asking if the proposed action makes the overall objective move faster. The guiding principle is to resist the impulse to create a one-size-fits-all solution.

This philosophy extends to the process of refinement. The author introduces a second, harder challenge: the cultural and cognitive aspect of subtraction. While building is often easy in the current environment, removing elements is often obscured by organizational incentives, as reward systems typically favor production and maintenance over review and removal. This addresses the observation, noted by Gerry McGovern, that leadership often rewards creation over the vital tasks of review, maintenance, and removal. Furthermore, research indicates that people systematically overlook subtractive changes in favor of additive ideas because removing something requires significant cognitive effort, whereas adding something is quick and cheap. Consequently, success should be measured by genuine customer outcomes rather than internal organizational metrics.

To manage the inevitable maintenance, the author suggests leveraging modern execution capabilities, such as agents, to handle pruning and maintenance judiciously rather than relying on manual oversight. This relates to the paradox of maintenance, which is necessary but optional until a system reaches a critical stage. Ultimately, the strategy calls for extreme selectivity in what is added to a system and militant discipline in what is removed. This is framed by the example of Steve Jobs’ 1997 product matrix, which demonstrated that focusing engineering talent on a limited, highly differentiated set of products—rather than spreading resources thin—was essential for achieving organizational focus and avoiding misspent opportunity cost. The overarching instruction is to pursue a singular focus, "une chose à la fois" (one thing at a time).