The most important product decision is what you don't build
Teams proudly list what they shipped, but go quiet when asked what they killed. Drawing on consumer finance apps, the author argues that document hubs and notification centres let organisations off the hook and quietly rebuild Google Drive or a bad Gmail clone. The real fix is showing the multi-year running costs, not the build cost, and being ruthless about removal — even though nobody gets promoted for deleting things.
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.
- alentred
I have visited quite a bit of small towns that were actively built I suppose in the 60-s, and often see abandoned ambitious or even grandiose projects like a park here, or a community center there - fully built but totally deserted now, often in ruins.
Every time I see those I also see the lesson - count your maintenance costs. It is a nice artificial water channel, yes, but will the city have the money to run it, clean it, supply water, etc.?
Of course I know that the original (real estate) developers did the cost analysis, but when you see those abandoned places - very much objectively you can conclude that they made an error. A miscalculation, or an error in judgement.
--
Back to software I think scope creep causes many problems: the team loses focus, can be demotivated by delivering the features no one needs, etc. - all real and serious problems. But what ultimately has the possibility to annihilate all team capacity is the ever growing maintenance cost, which so often neglected.
Everything we build needs to be maintained, and all projects should include this into their budget. Your quality can be top notch, but you still need to upgrade your software because of external factors. And growing maintenance costs only aggravate other issues cited above.
--
And that's the tragedy of being the engineer/engineering manager/CTO even. Exactly like the post says, you don't get "promoted" for stuff you reject to do. I had countless occasions of successfully convincing product teams […]
- stevoski
A chapter in my book features a company that attacks this problem with a “add a button;
remove a button” mantra.
Before they add any new UI element, they first look for something they can remove.
Self-promotional link: https://killthehippo.com/
- mmonaghan
I see posts pop up with this sentiment often and I'm of two minds:
- llms let us build exactly what we want fairly quickly nowadays, or at least a prototype and
- being able to build these features (or separate products) quickly is exactly the trap
> It’s the same test I keep applying when picking the right problems to solve — does it make the boat go faster?
Who knows this though? It's rarely engineers. Product often has a good sense within their lane. Leadership usually (at good companies) is mostly aligned, with some nuance depending on who's speaking.
It's a good sentiment but rarely a single person's decision.
As I said, I see these pop up and I'm usually annoyed because what new take could someone bring at this point, but I read them every single time :p
- djtriptych
Or as I like to say “the best way to launch is to cut features”.
As an engineering leader you’ve got to advocate for it against product/design all the time.
- SophiaVela
For me, the hard part is knowing when to stop. There’s always one more thing to improve before it feels ready.