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.

This post is the first from a three series posts where I will be taking you through a complete detailed walkthrough of feature request processing. Hopefully you will find some good practices you can deploy in your own process.


Read the rest of this entry

A few months ago I set on a search for the best product and project management software to get all my product/project activities and processes streamlined while at the same time meeting all internal teams requirements.

I have used many tools in the past:  Asana, Basecamb, and Jira to name a few; all of which have their pros and cons, some are very Agile focused others are great for productive communication and team collaboration. But none actually covered all the product activity spectrum requirements and I always had to go with additional tools and software to satisfy teams needs for internal processes management such as development team bug tracking, tasks distribution and logging, Or documentation and product development cycles digital assets management even on some cases integration with client internal platform for collaboration. All the mentioned challenges when coupled with a Scrum – Agile product development process results in massive decentralized workflows that a product manager is required to deal with and follow through successfully.

Read the rest of this entry

This post is final part 3 of my series on feature request processing. Be sure to check the end summery with extra goodies  😉


This step denotes a critical point, here we take the final verdict for building and shipping of feature X.

To reach this step both of step 4 and 5 must give yield positive results:

  • Feature X is feasible within our current resources, time and budget scope.
  • Feature X has low risk (benefits outweigh the risks).

The only thing left to look at is ROI: are we going through all that trouble to ship feature X just to generate a total revenue increase of 0.02%, is it worth it? Or perhaps feature X costs almost nothing so whatever profit it makes is good! That is not the correct way of looking at things. Financial value is essential, where as we are here looking at a different type of value; the value for our product can be measured through social impact, user loyalty, brand trust, brand reach and awareness, viral effects…etc.

ROI = gain from investment/ cost of investment.

Gain from investment can be measured through marketing and sales metrics like for example: expected growth in site traffic, listings, registered user, page views, SE ranking, reach, user activity, and site ads performance, sales leads, social media activity…Etc.

Expected cost can be calculated from step 4 which includes engineering and design effort, deployment and integration, testing and QA, SEO and marketing…Etc. Read the rest of this entry

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). Read the rest of this entry
Get every new post delivered to your inbox
This is a feed burner subscription Only!! no concerns on privacy.
Powered By WPFruits.com

Additionally you can follow me on Facebook and Twitter
Twitter Facebook