Prioritize high-value features

If you want to be a bad product manager, first implement the features that are quickest to develop. Yes, there may be some major important things that you want in your product, but if those are going to take a lot of time, first focus on the small, quick things to do, even if they’re not as important. A bunch of small less-important features is just as good as one big important one — maybe even better, since it’s more bullet points to list on your marketing materials and extra rows to add to your table comparing your product to the competition. Plus, if something happens and funding or resources are cut, you’ll still get to keep all those little features, rather than being stuck with something big that’s halfway done.

If you want to be a good product manager, first implement the features that will provide most value to your customers and users. What good are a handful of “neat but unnecessary” features if your product doesn’t solve the main customer need it’s trying to address?

Kano Analysis is a useful tool in product management for helping to identify what features provide the most value. In his article on Prioritizing Software Requirements with Kano Analysis, Scott Sehlhorst describes the four categories Kano identified — surprise and delight; more is better; must be; better not be — and suggests asking the question, “Are our 1.0 release requirements all must be requirements?” In short, you need to satisfy the “must be” before moving on to the “surprise and delight” and “more is better.”

Note, of course, that “more is better” refers to the quantity of specific attributes — “bigger, faster, better, stronger” — not the number of features. One major feature of your product that blows away the competition is more valuable than a dozen or even a hundred small features that don’t impact the purchase or use decision or significantly improve the user experience.

As Johanna Rothman explains in her post “Implement the Most Valuable Features First,” when talking about whether to start with the riskiest part of a project or the most valuable part of a project,

that what’s most important better provide the most value. If it doesn’t, do the most valuable parts first. You might not have to do the riskiest parts. … starting with the riskiest part of the project may not actually solve the value problem. If you start with what’s most valuable, you’re more likely to succeed.

If you are using Agile product development (e.g. SCRUM, DSDM), you already know that this is a fundamental part of the Agile process. By starting with the most valuable features first, you ensure that you’re focused on delivering the highest value to customers. If something happens and funding or resources are cut, you’ll still have a product that includes the most valuable features, rather than being stuck with all those little features that may not matter much to customers.

In the post “A Product Owner’s Guide to Product Backlog,” Stacia Broderick (of the On Be(come)ing Agile blog) writes that in an Agile process the product manager needs to

work with the team to deliver the highest value features and functionality … Now you not only have to consider the customer impact of a feature, but you have to analyze that feature/functionality in terms of ROI to the business. What WILL you choose for engineers to work on that brings the highest value to the organization? What are customers clamoring for first? What technical upgrades or decisions need to be made that perhaps are more important long term for overall product stability and scalability? In fact, what is the product vision?

This is a valuable lesson even for those not following an Agile process. Focus on the value you are creating, and ensure that you are getting the maximum value for customers for the resources you are putting in to your project.