Isn't this just speculation? Why would anyone build features without any thoughts about their benefit?
In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.
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’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.
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.
* 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.
> 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.
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.
That's how you end up with: https://gcemetery.co/
tldr: agile tells you how to release, not what to release
If you follow the feature factory route, the team will just produce things they are told too. If it doesn't work, it's not the teams responsibility. They did what they were told to.
It shouldn't be external group pushing features into a team backlog.
Devs talk to customers, look at the logs, debug issues, look at the stats being logged out. As result they have far better understanding of product usage than most people higher up.
Stakeholder is anyone with an interest in a project.
Good developers either see what is happening and jump ship or just get bored and leave.
I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.
There are some features that seem like obvious wins on paper but actually do worse when you A/B test it.
They hurt business value and add needless complexity to the development process.