Prioritization: MoSCoW and Stack Rank Methods

As a Product Manager, you have to work through prioritization at various levels of the organization.

 I've done this in two ways: the MoSCoW Method and the Stack Rank method.

Ultimately there are two major factors that influence whether or not something should be prioritized:

• Customer Value: How much more satisfied will our customers be with our product if they are given access to this feature?
• Level of Effort (LOE): What resources are required to build this feature?
• LOE should factor in everything from time needed to write requirements, create designs, complete engineering, test, and rollout the feature to users.

It’s very hard to put a good 'level of effort' on a project.  Usually it’s just a high level estimate. The Product Manager needs to be able to clearly articulate the criteria used for prioritization to the product team and stakeholders. Product Managers frequently have to inform stakeholders that their requests for the product will not implemented. Having a clear prioritization method allows others to understand how decisions are made and earns trust that they are made fairly, logically, and in the best interest of the customer and organization.
Let's take a detailed look at the two methods:

MoSCoW Method:
Rank features by classifying them as MUST, SHOULD, COULD, or WON’T, respective to whether they should be included in an upcoming product release.

• Must: In order to be classified as “must”, the feature must be absolutely essential to provide value to customers. This should be reserved for top-priority features, or features that have downstream dependencies (future features cannot be built until this one is completed). 
• Should: These are high-value features that will bring considerable value to the product, but not absolutely essential for the upcoming iteration. 
• Could: These are the “nice-to-have” features. They improve the product in a meaningful, but non-essential way. “Could” features are typically not appropriate for inclusion in a MVP, but may be prioritized once a product has achieved Product-Market Fit. 
• Won’t: The feature will not be considered at this time. Won’t is a very useful classification for Product Managers, as it sets an extremely clear expectation to stakeholders that it is not a priority. 

Remember: these classifications are not permanent. Something that is “Won’t” now could become “Must” in the future as priorities evolve.

Prioritization Matrix (aka “Stack Rank”)
The Prioritization Matrix method allows us to factor Customer Value by Level of Effort, and find the features that deliver the highest value at the lowest cost.

• When building the matrix, each feature is given two scores:
• Customer Value: Scale of 1-5, 1 is the least value, 5 is the highest value.
• Level of Effort: Scale of 1-5, opposite ranking. 1 is most effort 5 is least effort.
• Multiply the two scores together to get a composite score; the highest composite is a top priority feature.
• NOTE: If you have a large set of features, it may be useful to score on a 1-10 scale to create more separation between features.

How do you prioritize?  Have you used these methods?

References:

• https://en.wikipedia.org/wiki/MoSCoW_method
• http://www.allaboutagile.com/prioritization-using-moscow/
• https://www.quora.com/In-Agile-what-is-the-MoSCoW-prioritization-technique
• http://www.product-arts.com/resourcemain/articlemenu/1049-value-vs-complexity-a-prioritization-framework
• http://www.jamasoftware.com/blog/manage-backlog-calculated-fields/
• http://www.processimpact.com/articles/prioritizing.html - in-depth process + valuable
• http://agilemodeling.com/essays/prioritizedRequirements.htm - general prioritization feedback