But the manager gets to report a new feature, a boon to their career, at the cost of the devs’ careers and satisfaction. The manager might be glossing over or just muting any product satisfaction issues, particularly if no one in their line of report directly puts a KPI on that. That’s about company culture.
> "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our product"
Maybe analyze the target audience before shipping? Also an org issue, where a the PO should put their business analyst hat on. I mean, to me it’s a question of competence if the team is supposed to ship something that must be changed (not fine-tuned or improved) - it’s about how much.
> Maybe analyze the target audience before shipping?
The problem is that there’s a risk the analysis finds out that “the product adequately fits our target market’s needs, there’s no easy way to adapt to another market, so most pragmatic approach is to stay put, cut costs and reallocate resources to marketing or other projects”.
No product/project manager and very few devs want to hear they’re not needed, so it’s better for everyone is busywork is continuously being made up, regardless of whether it’s actually beneficial for the business.
I’ve been at dysfunctional places where the winning strategy would’ve been to just give the whole team a 3-month paid holiday while higher level management figures out an actual direction for the product, rather than desperately thrashing around and causing damage/tech debt that would continuously slow down further development (I originally wrote “that would need to be fixed later”, but who am I kidding, that will never happen).