PM Q: How do you prioritize features?

As many of you know, I'm interviewing for a new job. It's going really well. Yesterday I had to write up a screening document and I thought I would share some of my answers here.

I wish I had had a few more days to polish and simplify my answers, but they are still comprehensable. I start the document out with just about my favorite Mark Twain quote: “I'm sorry this letter is so long, but I did not have time to make it shorter”

-----------

How do you prioritize features? What criteria do you use?

At the highest level: Must have, Should Have, Could Have.

Although generally worked out long before a feature list, big items like business priorities, time to market, globalization, industry laws/standards, revenue models, applied laws, and other items at this level are the first stop.

And I like a very tight vision statement or mantra that the whole company believes about a release. It needs to be so clear that it is immediately apparent to everybody on the team if a feature moves the release in the right direction or not. For example if this release is all about making sure we find every document, we would prioritize supporting the Macintosh over features that go very, very deep into specific file types.

I like the feature team itself to make this call. I like for the developer and tester to sit down with the PM and talk about the features in context and make the first stab at it.

I also like good user and market research, based on science if at all possible. Things like usability testing, experimental releases, betas, etc. Periodic customer Strategic Design Reviews are great. I want to know the other products in our market space better than most of their employees do.

I like to do feature level SWOT analysis: Strengths, Weaknesses, Opportunities and Threats. This can keep the most important issues front-of-mind even if they are not that obvious. Sometimes it a feature looks very cuttable until you remember that this feature plugs a hole that could keep the company out of trouble in Indonesia.

If I’m pulling together a team wide prioritized feature list then I typically need to do some balance between the different feature teams’ prioritization. With all of the above data, matching these up is generally pretty obvious. Then I publish the list in an easy to understand manner and gather feedback and make adjustments. If possible, I would love to do a team offsite on this and get bottom-up buyoff and feedback. The more I can get the team on the same page here the easier the rest of the journey is going to be.

And one last thing I like is to have some space at the end of the schedule for a feature to come back. I create a mini-milestone that can be used as extra buffer if needed or for the team to sort through all the postponed features and new ideas and pick a few that are implementable. This takes the pressure off any one feature cut and also gives a way for the team to be more creative or more responsive to any late breaking market pressures.


-------

More soon...