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

Join the discussion

• Hacker News
• Sometimes, sometimes not. It depends.

  My mantra is still "Don't give users what they want, but what they need."

  Product Design is a one to many relationship, while users are one to one tightly knit into their app. It isn't to discredit their input, it just needs to make sense in the whole picture:

  What if the one guy who reports 70% of all the features that would be cool and necessary to have, but 99% aren't using the product like he does? Is there another way to achieve that he wants even better, easier, faster, more reliably etc.?

  What if a a/b test showed, that they outright ignore or complain about such new features?

  Not building sounds so cool and rebellious, but it isn't about the not to build but overall product strategy and product itself that is the decision maker so to say. Because, you build a product in the first place, didn't you?

  Product Design and improvement is brutally hard. Backwards compatibility is the one thing you have to take into account all times. This can create the greatest friction there is and kill products.

  So how do you introduce a better way, that breaks with old traditions? Don't build it or use brainpower to solve the puzzle?

  Heads up to all the Platform Leads, Founders, Product Designers - tough world, but if it works it is heaven on earth. :D

  by _the_inflator
• Saved countless sprints by killing features that sounded cool but didn't solve core problems. Less code, less maintenance.
  by Prydown
• I sometimes have a hard time figuring out what shouldn't be built.

  The next best thing is to rapidly build the crappiest thing that kind of works. Being a little bit bad on purpose usually helps. Getting trapped in clean code and test coverage ideological hell is precisely what we want to avoid.

  I've found that the more aggressive you make your time constraint, the less likely you will wind up committing to some kind of engineering decision that ruins the whole pie.

  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.

  I've turned multi-month product roadmap expansion packs into single day tasks by building the right things at the right times in order to discover what not to build.

  by bob1029
• I look at product features through a lens of value adding features, commodity/basic non value adding features, and negative value adding features (commodity features done poorly).

  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.

  I like this as an example because lots of product owners try to innovate with this and then somehow botch the job and create needless onboarding friction or otherwise annoy their users.

  And other product owners try to play it safe and simply copy what others do without wasting much energy on the topic. Which is why in 2026, you still see companies insisting on good old email+password based signup processes. Because it is what everybody else does.

  Both are creating negative value for their products by either over or under engineering something that is pretty important but essentially a commodity thing. Worst case, this can result in a lot of potential users abandoning an attempt to use the product before they ever even experience the amazing feature set it has to offer.

  You see this a lot in product design. Most projects are 90% copy paste jobs with a lot of common, non differentiating and completely bland/unremarkable stuff. LLMs are very good at copy pasting. But there are a lot of decisions that when you challenge them a little bit would result in a very different and arguably better product. A good onboarding experience can make all the difference.

  And then there's the simple notion of what is the quickest way to validate that your value adding features are good enough. Which mostly boils down to finding a way where you get those in the hands of users without wasting most of your time on the non value adding stuff that is nice to have but otherwise won't make a difference. LLMs kind of allow you to compress the time you waste on this stuff and do a better job of it. Which is a different way of saying that you will create negative value if you don't use LLMs or otherwise botch the job.

  by jillesvangurp
• The one I get constantly is we want "custom reporting". Well what the hell is that really? Why, why, why do you need that? Then I just build a new feature they will actually use and defer "custom reporting" for another month.
  by swader999
• 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.

  by djtriptych
• 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

  by mmonaghan
• 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 ultimately it is the ever growing maintenance cost that has a real ability to annihilate all team capacity.

  Everything we build, however high-quality it is, needs to be maintained and all projects should include this into their "run" phase budget. And growing maintenance costs only aggravate other scope creep issues.

  --

  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 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: . I cope with it, but it never really settled with me. If anyone has the answer to how to approach this in a healthy way I am very much interested in your experience.

  by alentred