Product management

How do product managers prioritize feature requests?

Rajen Sanghvi Vice President at PiinPoint

July 18th, 2014

How do product managers decide which features to build when? 
How do product managers determine which feature request is most profitable for the company? 

I hear a lot about feature prioritization being an art - is this true? I'm curious to understand how an effective product manager prioritizes between whats required for the business, and what's required for the business right now (especially when a startup doesn't have the resources for a dedicated PM in house). 

Mike Cohn Owner, Mountain Goat Software

July 20th, 2014

As Werner points out, financial prioritization is great. This does require a bit of background to understand the concepts. As much as I like financial prioritization, often non-financial approaches can be best.

I'm a big fan of a non-financial technique called Relative Weighting. The basic idea is to think of how much you benefit from each thing being consider and how much each thing costs. You can just use values like 1-9 for these. All things that cost "4" cost about the same and they cost about half as much as something costing 8. It's just relative.

You then compare the benefit to the cost. Something with a benefit of 8 and a cost of 4 is obviously a good thing.

For determining benefit you can pick multiple criteria--perhaps number of new customers is one factor, revenue is another. Pick no more than 4. Weight them if you want. (Revenue is 2x the value of new customers perhaps.) We've coded a tool on our site for doing this. It's free and all JavaScript so we don't get to see your ideas. It's at

Do the above quarterly. Here's where the art of your question comes in. Within the quarter don't use a formal approach like. Use your own expert opinion (or the expert opinion of a product manager/product owner). So, a formal, repeatable approach quarterly and the art of expert opinion within the quarter for the fine tuning of priorities within the larger things selected with an approach like Relative Weighting.

I hate just directing you toward URLs but the link here is to a conference presentation I gave on prioritizing. It includes an example of Relative Weighting, describes a few other approaches, and also shows what you'd need to know about using financial techniques:

Donald Cramer CEO - Founder at Rocket36

July 18th, 2014

Hi Rajen: As a Product Manager we Prioritized Product/feature development at different levels throughout the development life cycle. Here is an example of what we went through. First we had in place a product vision/roadmap. That was developed from a comprehensive market review. The vision roadmap took into consideration: -What were the minimum features we needed to get some early adopters into the market -What were a minimum number of features were we going to introduce to the market that set ourselves apart from the competition From their the vision/roadmap was built around the following -Feature sets that allowed us to build out a particular market of the industry (Based on competition, amount of features to develop, support, etc). The may include Feature Set 1 needed 10 features and have robust capabilities Feature Set 2 needed 3 features and minimal capabilities Our roadmaps would extend out 12-15 months- 1-3 months have a near locked in idea of what we were building (it would need to be a pretty big deal to change what we were going to be doing) 4-6 months have a good idea of those feature sets and breaking them down into features/user stories (most of the group- Sales, Business, Ops, Marketing, CSR, Dev understands this is on the near horizon) 6-12 months we know it is on the roadmap and are looking to keep tabs on this part of the plan to see if we need to make changes based on market trends, needs, etc. (all stakeholders understand what we are thinking and keep an open mind and discussion as we approach this schedule) 12-15 months aligned on what the strategic side of the business is thinking. Now off to the side there is always a feature request backlog (customer requests, tech debt, etc) We look to see what of this back log relates to the plan. There may be items such as tech debt that we need to address before we embark on part of our plan. While we have our iteration sprints coming up in the next 1-3 months, we keep back some of the development bandwidth to address some feature backlog request. Finally, most prioritization I involved a scoring method. The method took into account: Market Impact (Small to Great) Existing Customer Adoption (Small to Great) New Customer Sales (Small to Great) Customer Satisfaction (Neutral to Positive) Development Size (small to large) The prioritization involved the key stakeholders (Bus Owner, Lead Developer/Architect, Marketing/Sales Manager, Support Representatives). This way no part of the business was surprised by what was decided upon and were able to be a part of the conversation. I know there is a lot to discuss with Product planning. If you have any questions or wish to discuss, please do not hesitate to contact me at your earliest convenience. Best regards, Don Don Cramer CEO - Founder Rocket36 Dev Studio O. (702) 242.6097 M. (702) 427.6703 F. (702) 242.6089 E. DCRAMER@ROCKET36.COM WWW.ROCKET36.COM Follow us on:

Luis Avila Owner/Fullstack Architect at IdeaNerd LLC

July 18th, 2014

I've seen it be done and have done it two ways.

Assume an agile methodology... but I guess this can apply to any sdlc method.

1) Your customers help you prioritize features. Be they a group inside the enterprise or beta users or real users... You'll need to communicate with them and find out what features they want first.

2) You will prioritize based on a Use Case/Benefit/Value Proposition... Build features and capabilities that will meet that benchmark.

Beyond that... you built, test, measure.

Hope that helps.

Werner Krebs Financial & Marketing Software Developer

July 18th, 2014

Although it likely is as much an art as a science, there is a theory behind project prioritization, provided you can come up with a guess as to cost and future payouts. Project Management theory (taught to MBAs, financial analysts, and in some project management courses) says to prioritize projects with the best NPV (Net Present Value) Modified IRR (Internal Rate on Return) or payback period, and only accept projects where MIRR exceeds the firm's cost of borrowing. NPV, MIRR, and payback period are all equivalent criteria. Excel has built-in functions to compute these numbers. I've talked before (and on our corporate blog) about using analytics for things like engineering resource planning requirement (more accurate project cost): . The "art" is in accurately estimating these numbers in the absence of good data (or in approximating the result of this analysis when flying on instinct.) Happy to discuss more.