When someone asks me what I do, my answer is fairly simple. I try to influence my company to do the highest value things first.

The classic product manager is tasked with deciding what features and enhancements will make the product better. There is a ton of work and time spent simply identifying features and writing descriptions of the processes providing value to your organization. The examples can get fairly complicated, mostly in describing the assumptions of the state of the systems and data prior to the start of the process, as well as documenting the alternate cases based on different workflows. These descriptions can be done in different ways depending on your management style, but most product managers write user stories, user case documents and there are plenty of product managers out there still writing requirements documents.

SprintBacklog

Writing use cases and user stories takes up about 70% of my daily time but the act of simply creating and formulating this process documentation is not where product managers provide value to the organization. A good product manager delivers the highest value features first and determining the value of features to the organization is key to delivering software and projects in a productive manner. Without some metrics around valuation of features, it’s guessing. There are numerous ways to determine feature value. Here are some of my favorites.

Operational Expense Reduction

To use a simple example, take a piece of software that requires your team of DBAs to provide ad-hoc support to the tune of about 4 hours every week. Take that cost and multiply it by 52 and you have a yearly cost (~200 hours a year at $100/hour) and a rough value, around 20k. Using a simple case like this does not do justice to the fact small software changes and process updates could reduce thousands of people’s workload by something as simple as 30 minutes a day. Take the same piece of software and add in a feature reducing the average user’s work by 30 minutes a day. Let’s say you have 1000 users. That’s a reduction of 500 hours a day! At $20/hour, the feature is potentially worth $2.5 million.

Increased Revenue

“If your software had that feature, we’d buy it”. Usually this is a statement heard in almost any sales cycle. Sometimes it’s a ploy to start negotiations with leverage on the buyer’s side, especially if there are other products on the market with the desired feature. There are other times when the statement is used to begin the judgement on the availability of the software provider to respond to your organization’s needs. Quite frankly, there is a reason for the stereotype of having a highly responsive organization who disappears after the check clears and watching the organizational behavior prior to the sale is smart for any buyer. Finally, there is an actual legitimate request for the feature.

How do you value a proposed feature for increasing revenue? Obviously, your company has some metrics around profitability of similar clients or past sales, so depending on the size of the sale (one license versus 1,000 licenses), then the feature value could be enough to push the priority up for this one sale to close. Most of the time, that’s not the case because it’s not only about the feature to the single potential client, but the thousands of other clients in your target segment. If a feature could add 200 new clients, then do the math on profitability per new client to determine value.

However, be wary of two additional realities of using this as a valuation method. First, you must also take a look on how the feature may or may not be accepted by your existing client base. Is this feature, which might be a significant enhancement to an existing workflow, going to cause waves with your existing users? It’s always cheaper to keep an existing client than it is to bring on a new one so if there is a potential for any lost clients, the costs of the risk must be valued into the feature. Secondly, how you ever heard a salesperson say a new feature or enhancement wouldn’t boost sales? Neither have I. Make sure to put actual metrics or past performance in the decision, not the gut feel of your sales force.

Reduced Organizational Risk

Every day your company is at risk. Your contractual obligations and regulatory requirements, depending on the type of your company, could put your daily risk into the millions of dollars. Some of the energy regulatory bodies, such as FERC and the CFTC, can put some serious weight on your company if you do not follow their rules, especially if your compliance gap is around worker safety.

Product features in your backlog could be tied directly to one of these potential risks. When I worked for Enron in their natural gas transportation division, we were engaged in the full rewrite of their entire contacts and capacity release systems for three big pipelines. This project was years in the making and while this project was happening, the maintenance on the existing system had to be brought down to bare bones. Along the way, there are regulatory changes which require system changes, whether it’s operational changes or something as simple as changing the way volumes are aggregated, those mandates have penalties as well as due dates. While doing the system rewrite, these changes were introduced as features and while some of the due dates were given extensions, eventually the time came for us to get the project into production or face fines. Needless to say, those were some long months for us but we were successful on the delivery.

When you are trying to value features associated with risks, there are two ways you can do it. First, there is simple example of a feature that is absolutely required by a certain date and if it’s not there, you will get fined. The potential fine in question is only the baseline of the actual value. There are certain cases where the increased scrutiny into the organization will cost you even more. When there are data requests and audits, the time and expense associated with them can be very painful, not to mention the costs associated with the negative publicity. No company wants to be associated with non-compliance because your clients will view these gaps as potential hazards to their operations.

The really difficult area for valuation of features for reducing risk exposure comes from development of features replacing existing, brittle processes. To use an example from energy trading, if you are running your end of day calculations to determine the cash needed for margin calls, and that process can sometimes “break”, then the number may sometimes be wrong but not cause your organization any harm. For example, if it calculates you need 100k but you only need 80k, then the only value lost is opportunity costs for the extra 20k in cash which could be used in other parts of the organization as working capital. But let’s flip those numbers around and the story changes. Falling 20k short on a margin call could spell disaster for companies, causing not only regulatory scrutiny but could result in a full liquidation of position at a huge loss. To create valuations for these features, the calculation is based on real options analysis, taking the probabilities of these complliance events happening and multiplying by the potential losses.

Technical Debt

Every project accumulates technical debt along the way as decisions are made regarding the architecture of a software project. Some of the decisions creating this debt are caused by external pressures to deliver at all costs, causing developers to hack together solutions quickly with the promise of being able to go back and refactor out the bad code (which rarely happens). In addition, there is also technical debt accumulated as the product requirements change. The ORM decision made during the first month of a project could be a proverbial anvil around the neck of a development team three years later. These decisions are made based on the best available data and sometimes the data is incomplete.

techDebt3

Technical debt has very distinct impacts on the product, specifically inhibiting the ability to deliver value quickly. Adding a feature in one stack could take a day, but in other stacks could create a week long regression requirement and cost ten times as much. If there are pure technological debt issues existing, they need to be put on the backlog and prioritized. Much as when a company does a stock buyback because they have capital on hand and no projects on the books with a good ROI, these technological debt backlog items can (and quite often do) become budget killers adding 25% to the costs, sometimes much more, and when there is nothing else in the backlog more valuable than to refactor out this debt, then pull the trigger and get it done. Refactoring out bad code is like taking the extra minute to put on a pair of shoes before running a marathon.

In conclusion, a good product manager isn’t only someone who can write good use cases. It’s someone who can make good decisions and provide great analysis on where the product should focus. These simple feature decisions could change the bottom line and something as subtle as prioritizing one feature over another could make or break your organization. As always, a product manager is only as good as the support they have from management. Make sure to empower your managers to make decisions, but also don’t be afraid to hold them accountable as to why thing were prioritized the way they were.