There are lots of bad actor reasons (putting career advancement ahead of product success), but there also structural issues that can lead teams to operate this way.

The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does.

Usually this looks something like a sales person hearing from a couple of customers “we really need feature X”. The sales person doesn’t ask what actual problem they’re trying to solve but instead reports back “the market is telling me we need X!!”. An executive picks this up, writes a business case, and then hands a solution (build X) instead of the problem (our customers are struggling with Y) to a product manager. That PM is no longer really empowered to think about the overall outcomes but rather is tasked with discovering requirements and then project managing the feature through.

At some companies this is how all product decisions are made. It’s not that there is no thought about benefit, it’s that the wrong people are the ones doing the thinking and as a result you end up with teams who spends years never delivering anything actually valuable to their users.

I hear that these situations exist, yet this is the complete opposite of what I was taught, which is that (at least !) the project manager had to have frequent and direct contact with the customers starting from trying to figure out what their real needs are - for the project to have any hope to succeed?

In software/tech world, PM's customer are often internal stakeholders, often not all relevant ones. Very rarely company's customer. PM juggles internal issues like milestones, priority, resources, budgets and even some politics.

Yes. This is a redefinition of a role though, this should be called Project manager.

Ah, yes, I don't really understand what is a "product" manager and how it's supposed to be different from a project manager ?

I've seen proposals where one of the requirements was that the developers would have as little contact with the customer as possible. What little contact was allowed was through the most junior person at the customer.

I strongly disagree with this sentiment.

I’ve seen quite a few features added simply ‘because we can’, without any thought to ongoing maintenance, support, or additional infrastructure requirements/costs.

A little bit of common sense and forethought can go a long way in preventing unprofitable or revenue-decreasing features from being added to the product.

If you keep adding features, without increasing your conversion rate or user revenue, you are simply decreasing your profitability.

Death by a thousand cuts.

You are basing your sentiment on assumptions that cannot be verified in practice without implementing/releasing the features. Nobody wants to implement revenue-decreasing feature but nobody knows beforehand whether they will increase or decrease revenue. So such statements are useless.

There are lots of ways to test and to map potential features to customer problems. Launching features because _you_ think they’ll resonate with users is a complete crapshoot. More often than not, people inside the company are way too close to the product to be able to determine which features are the right ones. I recommend “The Right It” by Alberto Savoia, “What Customers Want” by Tony Ulwick, and “The Lean Product Playbook” by Dan Olsen if Cutler’s essay doesn’t convince you.

This is not accurate at all.

Approximate costs can be estimated before hand.

You can even ask the customer if they are willing to pay a specific amount for the feature.

But, insisting you have to build and deploy a feature first, before you have any idea of its impact, that is, an expensive, and foolish way to learn.

There are a couple reasons I've seen why you'd do that. I'm sure there are others I haven't seen.

* Sometimes companies have declared focus areas, and it's advantageous to be working in those areas. If the CEO says Project Foobar is going to be the next big thing, you want your team to be touching Project Foobar even if you have nothing valuable to contribute.

* Some kinds of projects are costly to push back on. If someone comes to you and says "this is a security feature, I'm going to build it to increase security", you have to demonstrate that the system is secure without it and not just tell them no.

* In some environments, people are measured by their ability to produce lots of features. This makes it embarrassing and politically damaging to not do a feature you proposed. So once it's publicly known that you have a feature, it's too late to think about whether it's useful, you have to just buckle down and do it.

> Why would anyone build features without any thoughts about their benefit?

> In practice you never know how a feature is going to work out

Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know.

This all boils down to having or not having a vision.

Some leaders have a vision and you can see the long-term goals, others (like Google) throw things at the wall to see what sticks then shuts them down. If you're not a monopoly, that strategy will not work.

Vision is good, but any product decision is still a guess about what will further your goals. Guesses can be right or wrong -- or if they are never wrong, then you're not doing anything that every other competitor in that space won't already be doing too. (And in that case, why have product management at all? Fire them and hire more engineers so you can follow the taillights faster.)

There's a difference from a blind guess and an educated guess.

And honestly yes, you shouldn't have product management. Projects should be coordinated by product leads and their engineers. The only people that can plan a vision for software are the people who make it. You're paying these engineers for their knowledge, use it in all capacities.

Google certainly had visions for all their products. They just didn't work out, for reasons that became apparent much later (although some people will always claim they "knew" beforehand).

Those visions are not long term goals. They are spin-offs that have nothing to do with anything.

That's how you end up with: https://gcemetery.co/

That's the whole point of agility: Release working software often. Make new business decisions based on customer feedback. Remember Google Beta? Not saying it doesn't offload responsibility and potential damage to end users..

No that's not the point. The point of agile development is not to get stuck in the water with long releases and no feedback cycle. It doesn't mean you blindly follow customer feedback and guesses until something works. It means you incrementally release your vision.

tldr: agile tells you how to release, not what to release