{"id":1765,"date":"2023-12-18T15:46:14","date_gmt":"2023-12-18T15:46:14","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1765"},"modified":"2023-12-18T15:46:14","modified_gmt":"2023-12-18T15:46:14","slug":"strategic-digital-product-management-trade-offs","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2023\/12\/18\/strategic-digital-product-management-trade-offs\/","title":{"rendered":"Strategic digital product management: trade-offs"},"content":{"rendered":"\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"569\" src=\"https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2023\/12\/scale-2635397_1920-1024x569.jpg\" alt=\"Image by Arek Socha from Pixabay\" class=\"wp-image-1766\" srcset=\"https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2023\/12\/scale-2635397_1920-1024x569.jpg 1024w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2023\/12\/scale-2635397_1920-300x167.jpg 300w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2023\/12\/scale-2635397_1920-768x427.jpg 768w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2023\/12\/scale-2635397_1920-1536x854.jpg 1536w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2023\/12\/scale-2635397_1920.jpg 1920w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Image by Arek Socha from Pixabay<\/figcaption><\/figure>\n\n\n\n<p>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\u2019s one thing most people prioritize, it\u2019s optionality. Making choices that close off paths that were available to us up to now isn\u2019t a popular activity for most.<\/p>\n\n\n\n<p>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\u2019t 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.<\/p>\n\n\n\n<p>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&amp;D department to take on more work than they have the capacity for, they\u2019ll 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.<\/p>\n\n\n\n<p>Second, when an R&amp;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.<\/p>\n\n\n\n<p>Third, the lack of willingness to make choices often originates from wanting to serve all customers and segments equally well with all functionality that\u2019s 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.<\/p>\n\n\n\n<p>For product managers, this is very hard as they\u2019re beleaguered by everyone. With lots of responsibility and little authority, there\u2019s 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.<\/p>\n\n\n\n<p>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\u2019d 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.<\/p>\n\n\n\n<p>Especially in organizations with multiple business units and a central R&amp;D department, product management often is under a lot of pressure from each business unit to prioritize \u2018their\u2019 features. As individuals from the business units often are unaware of the requests from others, it\u2019s easy to create a perception that central R&amp;D is slow and useless. One strategy that I\u2019ve 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&amp;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.<\/p>\n\n\n\n<p>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\u2019t 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\u2019re 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\u2019s not a lot of time. On the other hand, the predictability of R&amp;D is much higher when asked to estimate sprints.<\/p>\n\n\n\n<p>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, \u201cThe essence of strategy is choosing what not to do.\u201d<\/p>\n\n\n\n<p><em>Want to read more like this? Sign up for my newsletter at\u00a0<a href=\"https:\/\/mailto:jan@janbosch.com\/\">jan@janbosch.com<\/a> or follow me on <a href=\"https:\/\/janbosch.com\/blog\">janbosch.com\/blog<\/a>, LinkedIn (<a href=\"https:\/\/www.linkedin.com\/in\/janbosch\/\">linkedin.com\/in\/janbosch<\/a>), <a href=\"https:\/\/janbosch.medium.com\/\">Medium<\/a> or Twitter (<a href=\"https:\/\/twitter.com\/JanBosch\">@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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\u2019s one thing most people prioritize, it\u2019s optionality. Making choices that close off paths that were available to us up to &#8230; <a title=\"Strategic digital product management: trade-offs\" class=\"read-more\" href=\"https:\/\/janbosch.com\/blog\/index.php\/2023\/12\/18\/strategic-digital-product-management-trade-offs\/\" aria-label=\"Read more about Strategic digital product management: trade-offs\">Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1765"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1765"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1765\/revisions"}],"predecessor-version":[{"id":1767,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1765\/revisions\/1767"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}