The word “feature” is used in very diverse ways in the companies I work with and means different things to many. In some companies, it represents the key differentiation that we offer to customers and that helps us stand out from the competition. In other companies, a feature is a nice-to-have but rather irrelevant chunk of functionality that we should only add to the product if we have copious amounts of slack in the R&D organization — meaning never.
Features, however, represent the key, atomic unit or scope that a product manager deals with. Although there are many definitions of the term, we’ll use it as a unit of functionality that’s identified by the customer as an atomic, separate slice of functionality. The feature scope is only one of the scopes that product managers work with. We may, among others, focus on components, subsystems, products, portfolios, business areas, the company as a whole and the ecosystem in which the company operates.
The challenge with these scopes is that they aren’t orthogonal but rather interdependent. It’s easy to think that the company level should dictate the portfolio level and so on, but in practice, there are upward influences as well where features influence products and products influence the company. Also, inward influences from outside the company can affect all levels. In the upcoming posts, we’ll discuss three scopes: features, product and ecosystem.
As we’re focusing on the second dimension of our series on product management, which is concerned with the scopes in which a product manager operates, it’s good to start at the lowest level. One reason is that in the normal state, when the product has been released and we’re entering the periodic software updates stage, it’s typically the features that are the unit of discussion and prioritization.
Most companies allocate R&D budgets as a percentage of company or product revenue. Once the budget for the product or offering has been defined, we need a governance mechanism where we can prioritize the various activities we could do and focus on the highest-priority ones. The process of selecting these is where the challenges start.
In general, R&D organizations need to deal with three types of development efforts: building new functionality (features), managing and fixing defects and refactoring the system to reduce technical debt. Each of these is prioritized based on predictions of what the impact of the effort will be. This is where the problem starts as, so eloquently stated by the infallible Yogi Berra, prediction is hard, especially about the future. Those involved in prioritization activities have two main options: going binary or going unreasonably optimistic.
There are three ways of going binary: using regulatory or compliance arguments, claiming that the functionality has already been sold and threatening that we lose the customer or many customers. Regulatory or compliance arguments are used to claim that unless certain functionality is included, the product isn’t allowed to be offered to customers. This automatically puts the functionality at the top of the list, which is of course the intent in the first place.
The second tactic used especially by people in sales looking to influence the R&D agenda is to claim that certain functionality has already been sold to customers. As customer focus is key for any company, this leads to the functionality too often being promoted to be included in the next release as “we can’t break our promises to our customers.”
The third tactic is where some in the company, often sales but it can also be others, claim that we’ll lose some or many customers unless we build certain features or functionality. Similar to the other tactics, the intent is to get the functionality prioritized for the next release.
The second main approach is to go unreasonably optimistic and make outrageous claims about the impact some functionality or feature will have on the company’s competitive position. The idea is to create in the heads of everyone in the company an idealistic vision of the outsized impact this functionality will have. Humans are very susceptible to the “promised land” syndrome where we create a shared illusion that we’ll reach some fabulous place if we only deliver on this set of features and functionality. In this case, the best storytellers will typically be the most impactful. Especially those who can repeat the same performance release after release by making people forget the promises of the last time.
When reading the above, it must be obvious to everyone how destructive these behaviors are. By focusing on local optimization for individual goals and priorities, very often the global optimum is negatively affected. Although everyone has their own prediction on the impact of development activities, the prioritization process will become highly politicized unless we find effective ways to make rational and objective decisions. The key strategies to do so are short feedback cycles and quantification.
Short feedback cycles allow us to rapidly measure the impact of development activities. If we have yearly release cycles, we can’t afford to test the impact of new functionality. However, if we use DevOps and can measure that impact in a few weeks, we can adopt approaches such as the Hypex model to conduct iterative development of new functionality while measuring that the intended impact is indeed realized.
Second, it’s not sufficient to make qualitative statements about the impact of new functionality as it’s too easy to redefine success once the feedback comes in. Instead, we encourage companies to quantify the impact of features and new functionality before deciding to build it. That allows us to make more balanced decisions about the required investment and the expected return, which then allows us to maximize the ROI of development.
Product management operates at multiple, interdependent scopes, ranging from features to the company’s ecosystem. Here, we discussed the feature level where traditionally we can identify several less-than-constructive behaviors in prioritization that tend to cause the process to turn political. Instead, we recommend that companies focus on short feedback cycles and quantification as it decreases the amount of uncertainty that needs to be incorporated into the prioritization process. In a digital world full of data, you can’t afford not to use it!
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).
