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

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

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.

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.

Been there. Wasted months building features nobody wanted, all because we didn't prune the roadmap aggressively enough.

Saved countless sprints by killing features that sounded cool but didn't solve core problems. Less code, less maintenance.

Part of the question may be how do you change the users expectations.

If you are building a product the user already knows, that might not be difficult.

We work in the sleep space, where everyone expects a hypnogram and a sleep score. Even though these things don't actually tell you anything real. They are of little value to most people, but that is the expectation.

I would go one step further. Instead of 5 low impact features, build the one high impact one. Instead of a cheap notifications hub, fix the need for why you need one.

I feel this in my bones. 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.

One time it was user profile avatars that took a site down. I work in line of business software, nobody needs avatars.

It’s hard decision, but it has to be made.

I’m not building space elevator.

Building the right thing > building/not building anything

Yes. Don't succumb to featuritis. Destroy the barnacles.

I would say that 'what not to build' is the second most important decision.

The most important decision is what limitations and constraints you are prepared to accept. There are always limitations and constraints but they are rarely identified up-front.

The most difficult, hard-to-revert decisions are those related to hard constraints imposed by the systems and/or data you have to rely on. Maybe it's not physically possible to obtain the data you need to solve the problem you need to solve for the price you need for it to be viable. Maybe you need to be able to process large files which may take many hours to complete. Or your input data grows father than you can process on a single CPU core. Or the security requirements of a particular piece of data means that you can't efficiently connect it to some external piece of data as you need.

[flagged]

[flagged]