Don’t Prioritize Features Based on Development Cost

• Product managers must decide what features and enhancements to add to an offering
• Product managers usually have a long list of ideas from a variety of sources
• They also must score each idea to separate the good from the bad and prioritize the good ideas for development

One of the key responsibilities of a product manager is to decide what features and enhancements should be added to an offering. In the context of our SiriusDecisions Product Marketing and Management (PMM) Model, we call this “enhancement prioritization.”

Product managers usually have a long list of ideas from a variety of sources – customer or sales requests, competitor products, executive “suggestions,” market research insight – and they need to figure out how to score each idea to separate the good from the bad and prioritize the good ones for development.

It’s fairly common for product managers to come up with their own spreadsheets or formulas to do this evaluation. I’ve seen dozens, if not hundreds, of different ones, and nearly all of them have one thing in common – there’s some input for development cost.

This makes sense on the surface. Prioritizing features is, at the end of the day, a cost/benefit analysis, so understanding the cost is key to that analysis. And logic seems to dictate that development cost is the only cost (or the main cost) or a proxy for overall cost.

But herein lies the problem – the cost to develop an enhancement may be only a tiny fraction of its overall cost.

Years ago, I worked with a developer who suggested adding a certain feature to our product. In fact, it was so easy for him to develop, he just added it on his own and showed it during a regular development review. Though the feature wasn’t specifically requested by a customer, his argument was that it was so quick to build that if someone got some value out of it, it would be worth it.

Unfortunately, he wasn’t taking into account a litany of other costs. Before the feature could be released, it would need to be tested. Support documentation would need to be updated. Customer service and implementation teams would need to be trained on how it worked.

Once it was released, there would be a whole different set of costs. Sales engineers would possibly have to address it in pre-sale demos, taking time away from more valuable areas of the product. Salespeople would need to be prepped in case prospects asked about it. While marketing content generally didn’t get to this level of detail, some materials would need to be updated.

More costs were involved in getting people to actually use the feature. Most products are not “Field of Dreams” products – if you build a new feature, the users do not just come. Even regular users would need to be informed that this new feature was available, and in an already feature-laden product, it was just one more option that added to the cognitive overhead of using the product.

Furthermore, the initial development cost didn’t represent the entire development cost. Future changes elsewhere in the product would potentially require more development work to update this feature. Even if incremental changes weren’t needed, this feature would become one more thing that would have to be tested every time other features were added or a new release was prepared.

The value to customers compared to the development cost was high, but the value to customers compared to the overall cost was extremely low. By explaining all of the costs, we agreed that the feature should not be released.

We were able to avoid making a big mistake in this example, but not everyone is so lucky. Here are three suggestions designed to help product teams avoid falling victim to this scenario:

• Take into account all the costs related to an enhancement. Document the various costs that may need to be evaluated for any feature or enhancement. Beyond development cost, this may include internal costs (e.g. testing, training, updating documentation) along with other factors (e.g. potential support costs, customer marketing efforts, the “cost” of this feature confusing or distracting users from other tasks they are attempting to perform).

• Use a balanced and objective approach to enhancement prioritization. Clients of the SiriusDecisions Product Management advisory service have access to our research brief on Product and Solution Enhancements: A Framework for Prioritization that outlines the criteria we recommend, along with our interactive SiriusDecisions Feature Prioritization Tool that allows you to calculate and rank potential enhancements based on these factors.

• Leverage a dedicated product management application for feature prioritization. Many of the tools covered in our SiriusView to Product Planning, Prioritization and Roadmapping applications include capabilities to calculate value and compare potential enhancements. While some tools provide fixed formulas and criteria that cannot be changed, several allow for customization of criteria and weightings to account for the entirety of costs that should be evaluated.