The Product team is used as a Project management team:
I know, I know. How is this still a thing? It’s not just a thing — it’s the culprit for many teams, especially those in big organisations. We all know that owning the product development cycle and managing stakeholder expectations is a part of the PM role but if the team is bogged down with this who is managing the product outcome? No one. The biggest problem I see is that teams spend so much time with output coordination — sprint planning, stakeholder approvals, time management — that not enough time is ironically allocated to rapid testing, learning, and analysis (market, data, user). This is an integral part of setting up your product for success. Long story short: we need to stop blurring the lines between project and product management teams. We also need to stop skipping discovery if we want to ship the right products to the right markets.
Working with little to no autonomy:
Autonomy sounds sexy. It’s constantly marketed by HR teams when they are trying to recruit PMs. Nevertheless autonomy isn’t just a ‘nice-to-have’, it’s a ‘must-have’ for a successful team. Why? Because you want the people in the trenches to shape ‘the what’ (what gets built) and ‘the how’ (how it gets built). If Product is constantly executing marching orders a few things will likely happen: 1. you’ll end up with uninspired teams. 2. you’ll end up a messy product no one believes in. The reason Product teams exist in the first place is that they are out there tackling problems that will bring positive change internally and externally. If you don’t grant them the autonomy to test, fail, learn and arrive at the winning solution collaboratively, the organisation will eventually collapse. It’s like going to the doctor wanting to feel better but prescribing yourself the treatment you want instead of the treatment you actually need. And yes, more autonomy always means more accountability.