Warning: the ideas below are a bit raw as this concerns a currently on-going situation keeping me occupied enough that it’s tough to find sustained time to reflect; feel free to weigh in with suggestions if you have them. And thanks for understanding; I’d love to only share fully polished ideas but in truth it’s not that simple.
Something no one wants to face, but a key reality in developing great products that get to market quickly. A good product leader helps the team – and the wider group of stakeholders – understand trade-offs and make informed choices. I’m helping one team I work with wrestle through this fact currently.
The team works on a legacy product with a mountain of technical debt and an ever-evolving set of requirements based on user demands and changing regulations in the market. The team also has some disappointed and even suspicious stakeholders who are afraid that changes will mean the loss of workflow steps they have gotten used to. New people have joined the team in leadership roles to bridge the gap between what the designer and coders thought the product needed to do and what the detail-oriented subject matter experts are now articulating as core functionality. And there are clients expecting new features in the fall.
Although I’m not on this team myself, I am working closely with some of the product leaders on the team to develop buy-in for the concept of trade-offs. What has to be done now versus what can be done in a later phase of the project (for some people even the idea of a phased approach to development and delivery is a new concept since they are used to getting everything upfront)? Given time constraints and a fixed team of developers to work on the product, what is the highest priority for both internal users and external ones – and who’s needs are more important to satisfy in the short-term? How much time can be spent now digging out of the existing technical debt to make future development smoother? How can the team balance the desire from external users to have a simple and easy to use interface to handle common workflows with the needs of internal users for a system that supports incredibly complex exception processing – all without complicating the code base? And how can these conversations take place productively and in a timely manner when there are a lot of internal people feeling that their concerns have been under-valued and a host of external users who’s input has rarely been sought?
This can be a tough time to introduce the concept of making trade-offs, but this is a core principle for Agile product leaders to bring into these discussions. Everything can’t be done as a ‘top priority’ and someone has to help the team decide together what to work on first. There’s no quick fix because in truth it’s not that simple.
Image from: https://www.learnevents.com/blog/2016/01/12/decision-making/