Anti-Patterns in the Prioritization of Indirect Initiatives

I became interested in understanding why projects with indirect business benefits are often under-prioritized relative to projects with direct business benefits after experiencing frustration with this phenomenon first hand as a PM. My former college professor and I were thinking about how to apply concepts from Managerial Accounting to product management, and we decided to narrow down our focus to thinking about this problem.

During this time, I was also taking a course on Product Strategy at Reforge, and I noticed the same problem come up a number of times. The bio below of one of my fellow reforge students perfectly illustrates the pain point:

We even had a section during Reforge specifically covering tech debt, and one of the reforge leaders, Casey Winters, later wrote a blog post about this problem entitled “How to Justify “Non-Sexy” Product Investments”. One problem with these approaches is that they cling to the notion of measurement and quantification, often attempting to compare “direct” with “indirect” in apples-to-apples terms. A better approach in my opinion, discussed in Marianne Bellotti’s excellent book “Kill it With Fire” is to establish a budget for tech debt and avoid the direct comparisons altogether from sprint to sprint. Setting these budgets is more art than science, and relies on leadership with strong judgement. This exploration ended up taking me down a road mostly focused on tech debt, so I’ve also included some links on tech debt more broadly, but it is important to note that the underlying problem extends to other types of work as well.

Here is the what I wrote at the time about the problems of prioritizing indirect initiatives:

PURPOSE

The purpose of this document is to describe a problem often encountered by organizations when prioritizing between projects in the software development lifecycle. The objective is to inform the reader about the issue and its various causes, but does not seek to prescribe any solutions.

BACKGROUND/OVERVIEW

At any given point in time during the software development process, decision makers (product managers, engineering managers, executives, etc) are tasked with deciding how to best allocate a fixed capacity of resources (developer time) toward building software in order to achieve organizational goals. In the simplest representation, this is done by stack ranking initiatives by their estimated ROI or some other “score” (often based on estimates of “impact” to the team’s goals, and “cost” as measured in developer time to build the item). Effective decision making within this framework relies upon accurate estimates of impact and cost. A frequent pattern is that initiatives with ambiguous/indirect/shared impact (referred to going forward as “indirect initiatives”) are under-prioritized vs projects with more tangible and direct benefits to the organization’s goals (referred to as “direct” initiatives). Among other reasons, this is driven by challenges in effectively quantifying the impact of these under-prioritized initiatives relative to peers, and not considering the full cost of developing the direct initiatives. The sections below explain in more detail.

PROBLEMS CAUSED

The primary outcome of the prioritization anti-patterns being discussed in this document is that indirect projects are chronically under-prioritized relative to their more direct peers, leading to a cycle of indefinite postponement, ultimately sentencing these initiatives to suffer a fate of being eternally “below the line”. As a result, organizations are starved of the benefits usually derived from these types of indirect impact initiatives. Some of the impacts include: negative impacts to developer productivity/experience (sometimes leading to attrition), reducing the potential impact of the initiatives that do get built, constraining the product team’s ability to innovate and build the desired customer experiences, failing to improve insights into product data which hinders quality of decision making, degrading quality of customer experience (death by 1,000 paper cuts), increases in “hidden costs” like operational overhead and tech debt which take away resources from direct value adding work, short term throwaway work that will need to be rebuilt later, and more.

CAUSES

The under-prioritization of “indirect” projects has numerous causes, but these broadly fall into two categories: challenges estimating “cost”, and challenges estimating “impact”. Together these issues lead to inaccurate estimates of the overall net impact or ROI for a given project relative to its peers. First, on the challenges of estimating impact, it is often difficult to forecast the “direct” impacts of indirect projects in terms of the metrics that they influence (e.g. developer productivity), and then it is even harder to translate those into metrics that can be compared against the estimated impact from direct initiatives in an apples-to-apples manner. In some cases, the benefits/impacts of indirect projects may also be spread across multiple teams/products separate from the team evaluating implementation (and bearing the cost), so they are not considered.

Second, the cost estimates used to evaluate project trade-off decisions are often only reflective of the short-term direct expenses (developer time) incurred in building the feature, rather than the “true” costs taking into account lifecycle of the product and the aggregate opportunity costs. The result is that direct projects are made to appear artificially more profitable, and the indirect projects artificially more expensive. Some examples of these hidden costs include long term support/overhead costs, future re-work to fix throwaway work, reduced developer productivity (at the expense of delivering other value adding projects), etc. This idea of cost vs impact becomes cyclical as the impacts of the indirect projects also represent the opportunity cost of the prioritizing direct projects over indirect (if you compare to the list of problems in the section above). Another consideration is that indirect projects tend to be more ambiguous in terms of what is needed to execute, so they suffer from high “t-shirt” size estimates early on in the roadmap planning process to account for these risks.

Appendix: Table with examples of direct vs indirect initiatives