One of the most obvious principles of product management, and consequently the first one we discuss here, is to maximize the return on investment on the R&D efforts that we put in. As we’re a for-profit business, the goal has to be that we seek to maximize profit. This requires us to prioritize those R&D activities that are most conducive to accomplishing that goal. In most companies, the R&D budget is allocated as a percentage of revenue and the intent is to get a return on investment. Prioritizing R&D efforts that are conducive to that goal is central to product management.
This is so obvious that it’s almost painful to write. So, why do I do so anyway? My experience with many companies is that product management in many ways becomes a victim of a host of different obligations, need-to-do’s and must-haves to the point that there’s hardly any space for new functionality that has at least some potential to move the needle from a revenue perspective.
There are three main reasons why companies fall into the trap of prioritizing R&D efforts that don’t support this first principle of product management: customization, technical debt and lack of automation, especially around testing. We dive a little deeper into each of these.
First, customization is a very natural pattern in many companies. Discussions with a new potential customer are proceeding well and we can close the deal if we’re willing to implement some adjustments or customer-specific features. Company management gives in and asks R&D to do so. Typically, this is resolved by branching the code base and providing a customer-specific version of the offering.
The initial investment in creating this customer-specific version is often quite limited. The challenge is that with an increasing number of customers all asking for their own customization, the number of branches quickly goes up. In addition, customers tend to request additional customizations over time and as we agreed in the beginning, they expect us to continue to agree. So, what started as a small branch in a small part of the code base grows over time.
The consequence rapidly becomes that any cross-cutting change requires changes in all branches. As there are customizations, this isn’t simply a matter of copying but calls for careful checking of the implications of the change in each specific branch. Any defects that are found require the same treatment. In the end, it’s not that it’s impossible to run the business in this way, but rather that it’s extremely effort-consuming, causing less and less time to be available for value-adding new functionality.
The second area of concern is technical debt. Especially on the business side of companies, there’s little understanding of the need to invest in managing technical debt. This may easily result in a situation where refactoring and paying off technical debt is always pushed off to a later point in time and all resources are allocated to building new functionality and fixing customer issues.
As we now all know, when technical debt becomes high, the cost of adding new functionality and fixing defects increases as the complexity of the software increases. When taking this to the extreme, it becomes impossible to add any new functionality as the return on investment is simply too low.
Third, despite all the talk and publications on continuous integration and test, I still meet surprisingly many companies where test automation is severely lacking. Often, some elements are in place, but these aren’t integrated to provide an end-to-end validation cycle. The challenge in this case is twofold. First, significant resources are allocated to manual testing of functionality and these resources aren’t available to build value-adding functionality. The second problem is that companies relying on manual testing tend to release infrequently due to the high cost of testing. The long release cycles cause them to build large chunks of functionality without getting feedback from customers.
To deliver on the first principle of product management, ie maximizing the ROI of R&D effort, two mechanisms can provide significant benefit: fast feedback loops and careful definition of differentiating versus commodity functionality.
Product management is to a significant extent concerned with selecting functionality that doesn’t yet exist in the offering. That means that we’re predicting the impact on users, but we don’t know for sure that the expected impact is actually accomplished. To ensure that we only build functionality that indeed adds significant value, one effective mechanism is to build thin slices of functionality, deploy each slice and measure the impact of that slice to determine whether our hypothesis was accurate. However, this only works when we have short feedback cycles, allowing us to rapidly collect feedback and make decisions. This is one of the key reasons behind the evolution of DevOps, but many companies fail to make use of the mechanism. A few years ago, I discussed this in more detail.
The second mechanism is concerned with explicitly defining what functionality in the offering is considered to be differentiating, ie drives revenue from customers, and what functionality is commodity, ie necessary for the offering to function but not driving sales and revenue. Once we’re clear on this, we can more easily reject requests for changes to commodity functionality and prioritize extensions and changes to differentiating functionality. As I discussed several years ago, our research shows that 80-90 percent of all R&D resources are spent on commodity functionality. This is of course far from optimal if our goal is to maximize the ROI on R&D.
The first principle of product management is to maximize the return on investment in R&D. Although this is painfully obvious in theory, practice is showing that many companies struggle with this. The reasons include inappropriate customization, accumulating technical debt and lack of automation. Two mechanisms that are helpful in delivering on the first principle include fast feedback cycles and clearly defining differentiating versus commodity functionality. As Kris Gale said, the value is in what gets used, not in what gets built.
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).
