[zsoltkacsandi]

Completely agree. There is a common misunderstanding/misconception in product development, that more features = better product.

I’ve never seen a product/project manager questioning themselves: does this feature add any value? Should we remove it?

In agile methodologies we measure the output of the developers. But we don’t care about that the output carries any meaningful value to the end user/business.

[9rx]

> I’ve never seen a product/project manager questioning themselves: does this feature add any value? Should we remove it?

To be fair, it is a hard question to contend with. It is easier to keep users who don't know what they're missing happier than users who lost something they now know they want. Even fixing bugs can sometimes upset users who have come to depend on the bug as a feature.

> In agile methodologies we measure the output of the developers.

No we don't. "Individuals and interactions over processes and tools". You are bound to notice a developer with poor output as you interact with them, but explicitly measure them you will not. Remember, agile is all about removing managers from the picture. Without managers, who is even going to do the measuring?

There are quite a few pre-agile methodologies out there that try to prepare a development team to operate without managers. It is possible you will find measurement in there, measuring to ensure that the people can handle working without mangers? Even agile itself recognizes in the 12 principles that it requires a team of special people to be able to handle agile.

[zsoltkacsandi]

I didn’t mean the Agile Manifesto prescribes individual productivity measurement. I meant what often happens in “agile in the wild”: we end up tracking throughput proxies (story points completed, velocity, number of tickets closed, burndown charts) and treating that as success, while the harder question (“did this deliver user/business value?”) is weakly measured or ignored.

Also, agile isn’t really “removing managers from the picture” so much as shifting management from command-and-control to enabling constraints, coaching, and removing impediments. Even in Scrum, you still have roles with accountability, and teams still need some form of prioritization and product decision-making (otherwise you just get activity without direction).

So yeah: agile ideals don’t say “measure dev output.” But many implementations incentivize output/throughput, and that’s the misconception I was pointing at.

[graemep]

Its also about marketing. People buy because of features.

The people making the buying decisions may not have a good idea of what maximises "meaningful value" but they compare feature sets.

[antupis]

It’s more about operational resilience and serving customers than product development. If you run early WhatsApp like organisation just 1 person leaving can create awful problems. Same for serving customers especially big clients need all kinds of reports and resources that skeleton organisation can not provide.

[zsoltkacsandi]

Yeah, that’s a misconception too based on my experience.

I’ve seen many people (even myself) thinking the same: if I quit/something happens to me, there will be no one who knows how this works/how to do this. Turned out the businesses always survived. There was a tiny inconvenience, but other than that: nothing. There is always someone who is willing to pick up/take over the task in zero amount of time.

I mean I agree with you, in theory. But that’s not what I’ve seen in practice.