One of my favorite sayings is that you can do anything in life, but not everything. This is sometimes hard to accept as it requires choices as to what not to do. And if there’s one thing most people prioritize, it’s optionality. Making choices that close off paths that were available to us up to now isn’t a popular activity for most.
Companies are, in many ways, similar to humans in that many leaders, when confronted with a choice between A and B, will say that they want both. These leaders don’t want to make the hard choices that are required for a good outcome but instead focus on maintaining optionality. Although understandable from a human nature perspective, this brings many companies in trouble.
In my experience, there are at least three main problems caused by not making decisions on priorities: low-quality solutions, random prioritization by individuals and the nothing-to-no-one syndrome. First, when asking a team or R&D department to take on more work than they have the capacity for, they’ll look for ways to deliver on these requests, however unreasonable these are. The typical result will be that only the most basic aspects of the functionality are built. Quality assurance will often also take the back seat, leading to low-quality realizations of all requested functionality due to late and limited testing.
Second, when an R&D organization is loaded with too much work and a lack of clear priorities, the prioritization falls on individual engineers. So, as each individual has too much work anyway, people can easily start to cherry-pick what they think are the most interesting tasks, what they deem most important for the company, and so on. As each individual sets their own priorities, the overall result will be a mishmash as the end-to-end integration of new functionality and features will be impossible.
Third, the lack of willingness to make choices often originates from wanting to serve all customers and segments equally well with all functionality that’s asked for. The hope to be everything for everyone easily results in being nothing for nobody. The outcome is simply subpar for everyone. No stakeholder, customer or segment will be happy with or even willing to use the resulting solution.
For product managers, this is very hard as they’re beleaguered by everyone. With lots of responsibility and little authority, there’s constant pressure to give everyone what they asked for. However, doing so will result in the aforementioned challenges. In my experience, three tactics can help in such contexts: comparative selection, group-based governance and DevOps.
One of the techniques that proves to be surprisingly effective is to offer two options and ask the other party to select one. The idea is that even if they’d prefer to have both options, the way the question is phrased forces a selection of one. Product managers can use this as a mechanism to compel choices where leadership is loath to do so. There are many more advanced versions of this game, but the essence is to use pairwise comparison to force prioritization.
Especially in organizations with multiple business units and a central R&D department, product management often is under a lot of pressure from each business unit to prioritize ‘their’ features. As individuals from the business units often are unaware of the requests from others, it’s easy to create a perception that central R&D is slow and useless. One strategy that I’ve used is to establish a governance board with representation from all business units where all the requests are discussed and prioritized. If done well, it ensures that R&D resources are optimized for the best outcome for the company overall. In addition, it allows for effective alignment between business units where a feature can be used by multiple BUs.
Finally, when product releases are infrequent, eg yearly, everyone is fighting hard to get their features in the specification that forms the basis for the next release. This can become quite contentious as everyone realizes that if they don’t get prioritized, they have to wait a full year for the next opportunity. As a result, the release content will be overloaded to begin with. And as we’re generally poor at predicting required effort for such long periods, content will likely need to be cut anyway. However, when the organization adopts DevOps and starts to release every couple of weeks, we see a much healthier behavior. On the one hand, business units are much more willing to delay their functionality by a few weeks as it’s not a lot of time. On the other hand, the predictability of R&D is much higher when asked to estimate sprints.
Recognizing trade-offs is another key principle of product management. There are trade-offs between different scopes, between stakeholders, between time scales, and so on. Failing to prioritize and trade off between various options leads to problems, including low-quality solutions, random prioritization by individuals and the nothing-to-no-one syndrome. To address this, there are tactics we can deploy such as comparative selection, group-based governance and DevOps. Product management will never be able to create a mathematically optimal solution, but rather we need to focus on continuously balancing a variety of forces to end up in a close to optimal position. To quote Michael Porter, “The essence of strategy is choosing what not to do.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
