If you’re a product manager, then you know that demands for new features come from all directions.
Sometimes these demands come from key customers asking for a specific feature to support a workflow unique to them. Other times they might come from your sales team hoping for that one last feature they need to close their next big deal. Still, other times these demands might come from your general user base simply asking for more features in your product. But with all of these new ideas, how are you to decide which is the best investment for your product?
Luckily, there’s a simple way to evaluate the impact of adding new potential product features to your product by asking three simple questions. These questions will help you understand not only whether a new feature is worth pursuing, but also how that feature might contribute to your product vision.
Are you intrigued? Excellent, then let’s learn what these questions are.
1. Who is this feature for?
The first and most important question you should ask about every potential feature is which of your users are most likely to benefit from it? Is the beneficiary a persona known to be a regular user of your product? Or, would this feature appeal to a buyer who is known to influence the purchase of your product? Perhaps the beneficiary is neither a current user or buyer but instead maps to a persona you hope your product will appeal to in the future.
For example, imagine that your product is a CRM application designed to help busy sales executives track interactions with prospects more effectively. Your next feature allows sales executives to record notes from interactions with clients using only their voice. This feature likely appeals more to day-to-day users of your product rather than salesforce managers or IT administrators influencing product purchases. On the other hand, if your next feature provides oversight into a salesperson’s daily activities to help managers understand how proactively they are engaging with their prospects, it’s likely to appeal more to salesforce managers who approve the purchase of your product than day-to-day users.
In any case, if you can’t articulate exactly which of your personas will benefit from a potential new feature, or if that persona is known not to be a beneficiary of your product, then you should be wary of investing time into bringing that feature to market.
2. What capability will this feature enable?
The next question you should ask about each potential feature is what capability it will actually provide. For example, will this feature support a previously-defined initiative that your product is already pursuing, or does this feature clearly map to the desired capability already on your roadmap?
While there’s always room for a bit of unexpected inspiration, you should carefully consider any potential product features that don’t directly move your product closer to its stated direction.
Generally speaking, users tend to show more affinity to products with a tightly cohesive feature set compared to products with a large set of unrelated features. Products with cohesive feature sets tend to be better able to solve your users’ specific problems in obvious ways. That’s why you should favor features that are more likely to contribute to the direction that you’ve already chosen for your product.
3. Why are you building this feature?
The last question to ask is, why you are building this feature in the first place? Specifically, what benefits does your organization stand to gain from bringing this feature to market?
Will bringing this feature to market give your product a competitive edge, potentially opening up new market share? Or will this feature add value to an already strong product offering or generate incremental revenue opportunities? Are the benefits of this feature even more subtle, such as increasing your organization’s operational efficiency or increasing the value of your organization’s brand in the market?
Regardless of what benefit a feature stands to bring, if you can’t articulate exactly how your organization stands to benefit from investing in that feature, then you should be wary of doing so in the first place.
Starting with who
Odds are, you’ve probably already seen variations of these questions in your career as a product manager. In fact, you may have even asked these same questions about some of your own features, in the past. The difference, however, is that most teams who follow this approach start with what.
Starting with what often results in product managers first identifying a feature, and then working backward in an attempt to justify how it might contribute to the product vision. This often results in products bloated with features of dubious value. Or, products lacking a coherent vision or purpose.
But by starting with who, you take time first to understand not only who your target users are, but also what problems they are facing. As a result, you’re more likely to create features that will add value to your users’ lives and deeply resonate with the problems they face on a daily basis.
However, there’s also another, less obvious advantage. By first focusing your efforts on developing a deep understanding of who your users are and the problems that they face, you increase the likelihood that you’ll also identify additional opportunities to solve similar problems for those same users in the future. Not only does this better position your product to become more entrenched in your users’ daily lives, but it also enables you to grow your product by offering more capabilities to your current user base rather than forcing you to continuously identify new types of users and problems to solve.
Putting this to work for you
Now that you understand what questions you should be asking about each potential product feature that you’re considering, how do you put this to work with your product?
A great place to start is by looking at some of the requests at the top of your product backlog. Ideally, these should be requests that have been made by some of the parties mentioned earlier but that you haven’t yet committed to delivering.
For each request, evaluate it according to the Who/What/Why framework described here. And then, consider what you learn as a result of doing so. For example, does the priority of any of these features change as a result of being viewed through the lens of this framework, or do some features simply not seem as important to your product’s future as they once did?
Whatever the outcome, it’s likely that the Who/What/Why framework will add a new way of evaluating which features will genuinely add the most value to your product, and thus the best return on investment for your organization.
