Feature requests are one of the most important challenges a product manager has to deal with, in particular for web based products. It has a great influence on product value and could potentiality steer the product away from its set vision and strategy.
Deciding whither or not a product feature is worth development might seem like an easy straight forward task, all you have to do is get feedback on most demanded features from your users and start evaluation to prioritizing development. For products that have clear narrow goals with limited set of features and use cases this is the right way to go (for example a CRM software or a mobile app). While for complex web products that incorporate large set of interactive services and features (online networks, Saas, community hubs, social media …etc.) this light weight approach has a high potential of failure. Complex metrics accompanying complex products makes feature analyzing and evaluation a hard and lengthy process.
Creating the right feature request handling process
There is no stranded approach to deal with feature requests, with each product having its own unique features and strategy, product managers often develop their own feature evaluation techniques and process based on collective experience of what works best for their users and the complexity level of product metrics. The steps I’m presenting here are NOT “one size fits all” solution; As mentioned your product and business situation may not require to go through all the 10 steps to reach a verdict on feature inclusion. I’m providing a complete insight on the available options you might be considering for features processing in general, you can think of it as the extreme product feature request process. Accordingly, the steps can aid your effort in dealing with feature requests and expectedly, some of the steps maybe irrelevant to your product case or perhaps your resources and “time to market” doesn’t offer space for a detailed through process.
Investing in feature analysis and evaluation, how far I need to go?
Product teams will be required to put effort in feature evaluation and analysis to facilitate decision making. This investment from your product teams should be balanced and elevated to the right level where you have enough input to assist final evaluation. It is a good practice to help your teams when asking for feature evaluation, provide a guideline for feature evaluation and eliminate ambiguity surrounding metrics your targeting and describe the results your expecting. Don’t leave the door open for speculations from your team on what exactly they are required to do, the extra effort in measuring and analyzing feature elements that has little to no influence on decision making is lost investment you’ve wasted resources on.
From my prospective, how deep you need to go into analyzing and evaluating a feature (invest in the process) depends greatly on:
- Proposed feature expected impact on product value, users satisfaction and development plans : The higher impact you expect the more you need to invest in feature analysis and evaluation.
- Product users resistance to changes: Do your product users have heigh resistance barrier to changes? are they loyal enough to withstand the change and take time to adapt and learn the new feature. With more loyal users that show low resistance to changes you will feel comfortable experimenting a new risky feature without heavily investing in analysis and evaluation process.
Now lets get to business and take a look at the Feature Request Processing list:
Don’t introduce a feature just because you’re competitor has it!
Decision to build a feature should not be influenced by competitor behaviour. It is harmful to assume that a feature must be available in my product just because a competitor product has it! The driving force behind delivering a feature is the need for it; it solves a problem for my users or makes it easier to use my product, or my users see value for them in this feature and not satisfied by product alternatives. Of course, we are not closing the doors on new ideas! new ideas are welcomed to drive innovation, it should be considered only in the context of users expectations on what the product can do more for them aligned with product vision and strategy.
Feature Request Processing Summery
- Examine feature primary qualification: Is feature already planned and prioritized in production pipeline?. Dose it fit in the context of current product vision and strategy?.
- Analyze feature product value proposition (first look): Dose the feature has innovation peak (solves users problem or/and increase users productivity)?. Does it only provide UI improvements?.
- Opportunity assessment: Analyze feature user value proposition.
- Feasibility assessment: Determine Feature requirements. Requirements within available resources, budget, and time scope?.
- Risk assessment: Analyze feature impact (weigh positive and negative expectations).
- ROI assessment : Expected growth in site traffic, listings, registered user, page views, user interaction, and site ads performance. Expected cost of engineering and design effort, deployment and integration, testing and QA, SEO and marketing.
- Plan feature production: Create plans for Development, design, QA, testing, marketing and launch.
- Prioritize feature production: Prioritization based on lower investment to higher return ratio. Estimate shipping date for feature in reference of its set priority.
- Compile respond to users.
- Add feature to “watch list” (if feature is held back).
Next we’re going to take a closer look at each of the steps. Follow in next post (part 2).
If your looking for software pricing detailed guide I recommend checking: