This is part two of  “10 Steps to Successful Feature Request Processing”. In  Part one we touched on the challenges of product feature processing, how to scope the analyzing and evaluation effort for your team, presented a list summery of the 10 steps with an operation flowchart of the feature request process.

In this post I’m going to cover in details the first 5 steps of feature request processing, leaving the remaining 5 steps to part 3 of this series.

STEP1: Examine feature primary qualification

  •  Check to see if feature already planned and prioritized in production pipeline: Is feature already planned for production, hence has been allocated and prioritized in the production pipeline? If so then our reply to users asking for the feature would be to gently wait for it to land on the scheduled date reasoning feature prioritization (See step 9).
  • Does the feature fit in the context of current product vision and strategy?: Feature could be out of scope for what the product is currently targeting. It’s not on the path of achieving goals and vision set for the product and it would break the harmony of the product set features, or it might not blend successfully with other product mix. To add such a feature only to satisfy like vision of some users is a big mistake, in this case the best response to those users asking for feature would be to diplomatically apologies for not providing the feature with explanation why this feature is not considered for production and a commitment to reassess feature inclusion in future development following product strategy revisions (See step 9).

STEP2: Analyze feature product value proposition

Now with feature having primary qualifications, we want to see what value it brings to the product? What potentials it has? Where is the innovation in adding this feature to our product?  here we evaluate feature value from product prospective. This is early stage evaluation (first look) that we do not want to invest heavily in before we take decision to move forward with further processing steps. We don’t want to waste resources on a feature that has yet to be examined against other metrics before proving itself as a winning feature; Therefore we will be focusing on two indicators:

  • Innovation peak (solves users problem or/and increase users productivity): Input from UX lead and marketing lead for a initial assessment of feature is essential at this stage; their focus will need to be on overall feature value, which is mainly on feature ability to solve a problem we are aware of or have feedback from users on, or if feature makes it easier to accomplish certain tasks (improving user productivity).
  • UI improvements: It is possible that feature might not be a functional feature that directly effects user interaction with the product, but rather a UI improvement recommendation that effects color schema, page design and layout, content areas distribution or any other visual element of the product. In this case it also deserves attention as it eventually has its projection on UX.

At the completion of this step if we arrive at a conclusion that declares feature having no potential or innovation or even positive UI changes that can improve our product, then there is no point to pursuit further analysis and assessments.

STEP3: Opportunity assessment

Great! the feature has been identified as bringing value to the product. Now let us see if users actually find value in this feature as well? .When we place our hands on a feature that users consider very important to have while at the same time they are not satisfied with the alternatives currently provided in our product then we hit an opportunity, the opportunity to present a feature that makes a great difference to users and raises their satisfaction on product offerings. Opportunity = High Importance for users + Low Satisfaction with provided alternative Opportunity is defined through the Kano model.

Kano model

Kano model (Source wikipedia)

Our focus at this stage is on finding what users think of this feature?, what is the value from their prospective ?  in other words: Analyze feature user value proposition. One of the tools to assist in opportunity assessment is the statistical and analytic data on user-product interaction (like Google analytics, and social statistics tools) these tools help in examining the right metrics for marking level of feature importance to users  and where frustrations and satisfaction is coming from . If you think the data is not solid enough to build upon and are willing to invest further in this feature evaluation,  you can go combine this data with direct feedback from users , with the assistance of marketing and UX teams, plan and execute a multiple choice survey asking users to rate for a set of features that already planned for production in addition to the feature in question. Here is an example of how the survey might look:

Current site operation

Are you satisfied with this operation? (1 to 5)

New Feature added to operation

How much Importance you give this feature? (from 1 to 5)

Placing a new order using provided site forms.

3

Your last order input will be used to pre-populate your new placement form to make it easier to just change the fields you want and make new placement process faster.

2

My Searches list page

4

A Search box to search inside the list with filtering options.

5

My Watch list page

3

You can select items you wish to be email notified when they become on sale or their price drops.

2

The survey will require a small development window from development and design teams guided by marketing and UX. With the survey results we can now plot a diagram that reflects weight of opportunity for feature compared to other features currently planned or in development. Looking at the results, If feature shows high importance with low satisfaction then we are looking at a great opportunity to improve product offerings and hence we are ready to take feature to the next level, while if feature shows low importance with high satisfaction then there is no need to hurry its development and we need to reply to users about it (See step 9).

STEP4: Determine feature feasibility.

Ok, feature is an opportunity but can we really build it? Do we have the required resources?

  • Defining requirements within available resources, budget, and time scope.

We don’t want to go over the fence just because feature X is really  awesome! If you’re going to spend great deal of resources and budget to build this feature crippling the rest of the product line then you’re gambling with all your assets. We need a good metric that reflects feature budget and time consumption. feature feasibility means we can take it to the next step, not passing this stage will require us to reply to users asking for the feature with explanation (See step 9).   Here is a list of metrics to help in feasibility assessment:

Resource metric stakeholder Estimated time Estimated budget
Engineering effort (development) Work hours and number of developers Engineering lead    
QA effort Work hours and number of testers QA lead    
Design effort work hours and number of designers UX lead    
Hardware infrastructure Server and network requirements System Administrator + Engineering lead    
Marketing requirements SEO, SEM, content optimization. Marketing lead    
Legal and licensing requirements  Third party licensing, legal qualification. Business consultant    
External resources Outsourcing, training, other. PM    

Time overlapping and parallel processes should be considered when evaluating total time to deliver feature.(Scrum –Agile implementation).

 

I will continue the discussion for the remaining 5 steps in part 3.

Tagged with:

Filed under: Product Managment

Like this post? Subscribe to my RSS feed and get loads more!