Prioritizing Product Features
- by Robert May
A very common task in Agile Environments is prioritization. Teams that are functioning well will prioritize new features, old features, the backlog, and any other source of stories for the team, and they’ll do it regularly. Not all teams are good at prioritizing according to the real return on investment that building stories will yield to the company. This is unfortunate. Too often, teams end up building features that are less valuable, and everyone seems to know it except perhaps the product owner! Most features built into software are never even used. Clearly, not much return for features that go unused. So how does a company avoid building features that add little value to the company? This is a tough question to answer, but usually, this prioritization starts at the top with the executives of the company. After all, they’re responsible for the overall vision of the company. Here’s what I recommend: Know your market. Know your customers and users. Know where you’re going and what you want to achieve. Implement the Vision Know Your Market We often see companies that don’t know their market. Personally, I’m surprised by this. These companies don’t know who their competitors are, don’t know what features make their product desirable in the market, and in many cases, get by with saying, “I’ve been doing this for XX years. I know what the market wants!” In many cases, they equate “marketing” with “advertising” and don’t understand the difference. This is almost never true. Good companies will spend significant amounts of time and money finding out who they’re competing against and what makes their competitors successful in the marketplace. Good companies understand that marketing involves more than just advertising. Often, marketing is mostly research and analysis, not sales. Until you understand your market, you cannot know what features will give you the best return on your investment dollar. Good companies have a marketing department and can answer the next important step which is to know your customers and your users. Know your Customers and Users First, note that I included both customers and users. They’re often not the same thing. Users use the product that you build. Customers buy the product that you build. It’s a subtle difference, but too often, I’ve seen companies that focus exclusively on one or the other and are not successful simply because they ignore an important part of the group. If your company is doing appropriate marketing, you know that these are two different aspects of your product and that both deserve attention to have a product that is successful in your target market. Your marketing department should be spending a lot of time understanding these personas and then conveying that information to the company. I’m always surprised when development teams think that they can build a product that people want to use without understanding the users of that product. Developers think differently than most people in the world. They know what the computer is doing. The computer isn’t magic to them. So when they assume that they know how to build something, they bring with them quite a bit of baggage. Never assume that you know your customer unless you’re regularly having interaction with them. Also, don’t just leave this to Marketing or Product Management. Take them time to get your developers out with the customers as well. Developers are very smart people, and often, seeing how someone uses their software inspires them to make a much better product. Very often, because the users and customers aren’t know, teams will spend a significant amount of time building apps that are super flexible and configurable so that any possible combination of feature can be used. This demonstrates a clear lack of understanding of the customer. Most configuration questions can quickly be answered by talking to the customer. In most cases, if your software requires significant setup and configuration before its usable, you probably don’t know your customers and users very well. Until you know your customers, you cannot know what features will be most valuable to your customers and you cannot build those features in a way that your customers can use. Know Where You’re Going and What You Want to Achieve Many companies suffer from not having a plan. Executives will tell the team to make them a plan. The team, not knowing their market and customers and users, will come up with a plan that doesn’t reflect reality and doesn’t consider ROI. Management then wonders why the product is doing poorly in the market place. Instead of leaving this up to the teams, as executives, work with Marketing to understand what broad categories of features will sell the most product in the marketplace. Then, once you’ve determined that, give this vision to the team and let them run with it. Revise the vision as needed, but avoid changing streams frequently. Sure, sometimes you need to, but often, executives will change priorities many times a month, leading to nothing more than confusion. If the team has a vision, they’ll be able to execute that vision far better than they could otherwise. By knowing what products are most important, you can set budgetary goals and guidelines that will help you achieve the vision that was created. Implement the Vision Creating the vision is often where the general executives stop participating in the plan. The team is responsible for implementing that vision. Executives should attend showcases and and should remain aware of the progress that the team is making towards meeting the vision, however. Once a broad vision has been created, the team should break that vision down into minimal market features (MMF). These MMFs should be sized using story points so that, using the team’s velocity, an estimated cost can be determined for each feature. The product management team should then try to quantify the relative value of the MMFs based on customer feedback and interviews. Once the value and cost of creating the feature is understood, a return on investment can be calculated. The features should then be prioritized with the MMF’s that have the highest value and lowest cost rising to the top of features to implement. Don’t let politics get in the way! Once the MMF’s have been prioritized, they should go through release planning to schedule them for implementation. Conclusion By having a good grasp on the strategy of the company, your Agile teams can be much more effective. Each and every story the team is implementing will roll up into features that matter to the company and provide ROI to them. The steps outlined in this post should be repeated on a regular basis. I recommend reviewing them at least once per quarter to make sure that the vision hasn’t shifted and that the teams are still working on what matters most to the company. Technorati Tags: Agile,Product Owner,ROI
