Agile Product Owner Tips On Feature Prioritization

As a long-time software developer and development team leader, I’m passionate about working with high-performing software development teams. For anyone in our industry who has worked with a great development team, you understand the difference in productivity can be tremendous. So, the goal of helping teams improve their performance has always seemed to be a righteous (though often elusive) goal.

High-Performance Teams

When we think about the unicorn tech startups we’ve seen in the last decade, it seems the ultimate high-performing team normally consists of a couple of smart founders in a dorm room, basement, or garage. So, it’s worth asking what those teams have that the average development team does not.

Obviously, we are talking about some of the most intelligent and motivated people in the software industry. Assuming that the baseline is the same and you have all the things they do (a great product, intelligence, and motivation), what is the next most important advantage other teams can emulate?

It’s a tricky question for sure. My experience leads me to believe that the secret lies in the fact that these small teams served as both the development team AND the product visionaries. This creates a single source of input (what most of us know as “requirements”) for the development team and streamlines the efficiency of communication enormously. As product managers, product owners, and stakeholders, this example gives us a tangible area where we can positively influence the productivity of our software development teams.

Empower the Right Product Owner

Agile software development best practices acknowledge the importance of communication between the business and the technical team. Probably the most significant evidence is the existence of the product owner role. Having been in this role a couple of times, I can tell you that there is no easy day as a product owner. The ideal product owner is one person with the experience, authority, and bandwidth to make all decisions regarding what features go into their product, as well as the priority with which they are added. Development teams that have had the luxury of working with a product owner that meets all these criteria will tell you that this helps their efficiency tremendously.

However, having a single product owner is often impossible or impractical for a variety of reasons. Perhaps the company culture is one where a committee makes decisions. Maybe the product footprint is large enough that one person can’t understand it all. Possibly, the product has such a broad range of users and business goals that having multiple stakeholders makes sense to represent different users’ interests. In these cases, it is critical to get clear on how the collective group assigns value and priority to a particular feature.

The reason a single product owner is a best practice is because that person only has one way to measure the value of a feature. They have their understanding of what is important, and might occasionally be swayed from that by other stakeholders. But generally speaking, they just decide what to do next and communicate that to the development team.

Too Many Cooks in the Kitchen

When multiple stakeholders become active participants in deciding feature priority, things get complicated. This can result in unclear or ambiguous direction to the development team. The reason this occurs is because now you have different perspectives feeding the priority. Something as simple as one person valuing new customer obtainment, while another values maximizing revenue from existing customers can cause major inconsistencies in how importance is conveyed to the development team. Throw in other common themes of software product enhancement such as usability, performance, new market penetration, competitive threats, lowering maintenance costs, integration with new business partners and keeping up with technology platform advances and you have a majorly complex value system that is driving priority.

Feature Prioritization Matrix How-To

How can you cut through the complexity inherent in a situation with multiple vocal stakeholders and competing priorities? I recommend a simple tool  to help with prioritization and ultimately provide the development team what they need to stay efficient and productive.  How does it work? The idea is to score each new feature with a weighted average system to create a numeric priority.

Let’s say the group of stakeholders agrees upon the following three primary business drivers for their new mobile app:

1. Attract new users
2. Retain existing users
3. Lower support costs

Further, the group agrees that they are currently focusing on growing the user base as the primary goal and that, while lowering support costs is important, it should be considered the least important of the three. So, they could assign relative weights as follows:

1. Attract new users – 50%
2. Retain existing users – 30%
3. Lower support costs – 20%

Creating this definition of how to measure value of a feature is a critical discussion. If you can get the group of stakeholders to agree to this, then you can have this discussion one time instead of having it every time a new feature is being considered. Take as much time as you need in order to drive alignment on this measurement system. It’s important.

Now with the measurement system in place, as a group you can consider each feature and rate the feature’s value on a scale of 1-5 (1 = least, 5 = most) against each of the criteria. So for a feature such as, “add chat capability to the app,” the group produces this:

1. Attract new users – 50% weighting : Group score (1-5) 4
2. Retain existing users – 30% weighting : Group score (1-5) 5
3. Lower support costs – 20% weighting : Group score (1-5) 1

This allows you to generate a numeric score for this feature. You’ll find that instead of discussing how valuable a feature is as a group (which can be an emotional and complex discussion), you’ll be discussing to what extent a feature can “attract new users” on a scale of 1-5. This is a much easier discussion to have, and compromise comes quickly by using the 1-5 scale.

This exercise can be done with dozens (I’ve even done it with hundreds) of features relatively quickly. Once completed, every feature has a numeric priority that considers the primary business drivers that everybody agrees on. Order the features in descending order and you have a prioritized backlog that was collaboratively created by a team of stakeholders.

The best way to accomplish this is to create an Excel document with the features listed down the left side and the business drivers listed across the top. Then, fill in the matrix for each score and create the formula to compute each feature’s weighted average score.

I have literally watched the anxiety leave stakeholders’ faces when the list is sorted. The stress they felt around having to campaign for the features they thought were most important instantaneously disappears. This can be either because these features were indeed the most important or because they were not the most important when compared to the other features in the backlog. There is great relief in knowing either case. It’s a simple but powerful tool to get through what can be a politically-charged exercise, and it will help charge your development team’s productivity by providing clear direction.

Tips for Success

Tip #1: I’ve found that many people want to include the “cost to implement” of the feature as a business driver. The idea is that if something is inexpensive to build, but has a lot of other values then we should prioritize it highly. I typically advise against including cost, or if you do, weight it very low, for two reasons. First, these features are often high-level ideas at this stage of planning and normally have not been estimated, so cost to implement is very difficult to know. Second, if you assign too high of a weight to cost to implement, it can make it difficult to ever make any significant-sized enhancements bubble up to the top of the priority list.

Tip #2: I’ve also found that many people like to include “ability to generate revenue” as a business driver. I also recommend against this. Again, the assumption is that any feature that is being talked about here has already been vetted in terms of ROI. Also, generating revenue is a by-product of most other business drivers, such as, “Attract New Users.” Including revenue generation by itself usually ends up double counting the revenue benefit that already exists in other categories.

By creating an unbiased method to rank and sort features, your team of leaders will share the accountability and responsibility of developing or revising software. When the solution product, all can celebrate equally. When improvements are needed, all are equally invested in finding a solution without blame or accusations entering the conversation.