Estimating business value

Soothsaying from coffee grounds?

Rigorously estimating the value of a new feature was rather an exception than a mandatory part of product planning in those projects I have seen and heard about. How is it possible? How are the backlog items (e.g. user stories) prioritized? How can you determine if a work item is too costly to implement or not? Too costly compared to what?

The “oracle” product manager

Common prioritization “techniques” include making things first for the most aggressive or noisiest customer, listening to the product manager’s “guts” (I am always wondering, if there is a reason, why don’t such product managers want to rely on their brain), going to the least or most challenging/interesting direction.

(image source: Dilbert by Scott Adams)

These rather esoteric, however disturbingly often used “techniques” are usually protected by facts and circumstances that, in fact, don’t really indicate that the value cannot be estimated, but, at least, can be used as an excuse by product managers and product owners so that they don’t have to do the hard work and research to estimate the value of upcoming stuff based on data; for example:

• the product or service is free of charge, or
• it is part of a bigger product and it is not sold directly to the customer, or
• it is a consumer product and product management have no idea how people will receive a new feature (or the whole product), or
• it is a tool used internally in the company, or
• the work items are rather technical, and as such, they are not meant to deliver value to the users.

However, estimating the value of a service/product/feature is not a black magic, it does not require guts or soothsaying from coffee grounds.

A rigorous approach

The ultimate goal is to have a model, metrics, techniques, and data that can be used to estimate the value of a new work item (e.g. feature) by anyone so that you don’t need the guts of your product manager.

First of all, you need to know the business case of your product or service and how you are planning to convert it to money; or at least, you shall have an idea or some plan. In certain cases, the conversion is quite direct since the customers have to buy the product. Other cases may be somewhat trickier, since your product may only be used to increase the sales of another product. Well, then the value of your product is the sales increase of that other product.

Then, depending on the business case and the conversion strategy, you need to determine the value metrics. It can be virtually anything. For example, in case of a business software it can be the number of licenses sold, or in case of an instant messaging platform, it can be user engagement measured by the number of messages sent during a given time period.

Certain work items save development costs for the development organization. Such items can be treated similarly as those items that directly deliver value to the user, but in this specific case, the (members of the) development organization is the key stakeholder. The business case is cost reduction, while the value is the costs saved by doing the work item.

Without statistical data it is often hard, if not impossible, to quantify value, therefore, as a first step, you may use qualitative values which may be okay even for long-term. However, if there is no good reason to stick with qualitative estimates, you should still work on exploring those factors that determine the quantitative value estimate.

This approach has other benefits as well. To calculate the value you need to have a deep understanding of the user’s problem and why the new feature will offer him a solution. This rigorous approach helps to motivate development teams, involve them in the design of the solution and refine it, if necessary. Also, it allows to re-calculate the value (by anyone) that may be necessary when the scope must be narrowed for any reason.

Our case is always special — Examples

1. Internal tool for remote support.
   Since the tool is not sold to anyone, we could say that it has no value. But this statement cannot be farther from the truth! It enables the company to save huge traveling costs, allows support engineers to access remote systems fast and efficiently, and improves customer satisfaction. Therefore, among others, the value of a new feature can be measured in terms of operational costs (time needed to operate the tool), and the time it saves for support engineers in accessing remote systems. In order to calculate the time a new feature saves for the operations or support team product people must not only be familiar with their daily work and processes, but they also must have measurements, data that characterise their work (e.g. in average/min/max, how long does it take for a support engineer to log into a server of a new customer).
2. Backend team.
   The team develops functions, libraries, services for another team(s) that are developing customer-facing features. While this component team-based setup is somewhat unfortunate, the backend team need to prioritize their backlog items. Those items that are “ordered” by other teams that are developing customer-facing features are the results of the component team-based structure. These items are actually parts of the feature, but the feature’s full task breakdown cuts across the organizational structure and creates inter-team dependencies. Therefore, as a matter of fact, the value of the feature should be divided between the backlog items of the “feature” and the “backend” team.
3. Code refactoring to reduce technical debt.
   In this case, the developers are the key stakeholders, their own work shall be analyzed and characterized with data. Why do we consider a certain part of the code old? Most probably because it is costly to build new features on it, or its maintenance costs are considered high. How many times did the teams have to touch the code to fix a bug and how long did it take? How many features will be built on it in the future? How long did it take to build a new feature on it in the last few times, and how faster those features could have been implemented if we had had a refactored code? By answering these questions we can have a quantitative value that the old code costs, and we can win on re-writing it.
4. Highly complex data storage backend system packed into bigger, customer-facing products.
   Even if it is almost invisible to the customers, it is a fundamental component of other products. Again, a siloed organization makes it hard to calculate the value of a new feature in the data storage product. Similarly to the backend team for example 2, the storage product delivers real value: the value delivered by a customer facing feature is divided between the two products. If there is a dependency between a new customer-facing feature and a new feature in the data storage product, the storage product can use the value of the new customer-facing feature to prioritize the storage feature.
5. New security product with no customers yet.
   What is the business case and why would the customers buy it? We have to answer this question anyway, and having the answer, we can build metrics on it. Because it is easier to operate than other products? Then what are the operational costs of those products, and how much time would they win if they used ours? Because it is more secure? Then how much money do the potential customers lose on security incidents every year? How much money will they lose in the upcoming years if they use our competitor’s products and not ours?
6. Supply chain tool, given free of charge to the customers.
   There is a close correlation between the satisfaction and future orders of a customer. The impact of 1% improvement of customer satisfaction on future sales can be calculated from statistical data. Similarly, the impact of the supply chain on the overall customer satisfaction can be calculated, if detailed surveys and data are available (as they should be). Therefore, estimated sales boost as a function of supply chain tool and process improvements is also calculable.

Summary

The estimated value of a new feature should be calculated using a rigorous approach. The point is to define and test a reasonable metric (so that your profit is a function of it) and rely on data instead of intuition. Or, in other words:

“In God we trust, all others bring data.”
W. Edwards Deming

Liked this post?

If you enjoyed this post, please help out your friends with a *clap* or a share.