I know, everybody has some magic formula for setting up prioritizations in their product plans, MRDs, PRDs, Go-to-market plans etc. However, I have found most of them overly complex. This leads to more argument about what each tier really means than it is worth.

Years ago at Remedy I learned a simple system that is supposed to have come from HP. It is simple and effective. Since we all like acronyms in this industry, let’s just call it the “MHW” system.

M

“M” stands for “Must“. This means that this feature, action, etc. MUST be in the release in order to proceed. These are the things that support the key objectives and messages of the release and should only be skipped if the whole project has been re-prioritized.

H

H is for “Hopefully” as in “hopefully this will make it in”. And as Rick Page says “Hope is not a strategy”. However, that isn’t what this means. It means that the feature is budgeted for the project in terms of time and resources. However, it can be dropped if schedule or change in resources demands it.

W

“Wish” is sometimes the trickiest one to understand. A ‘wish’ feature is often on the plan simply because it is tied in some way to other things in the project. For example, you’ve always wanted to change the way Module X works but it just hasn’t made the priorty cut. However, there will be other things done to Module X in this project so the developers should be aware of the improvement that could be done if it is efficient. Most of the time Wish items don’t make it but it still is a usefull communication tool.

The beauty of this system is that it is simple and concrete at the same time. Anybody who wants to change a Must understands that this will require changing the vision of the whole project. Having hopefullies budgeted gives them a reasonable chance of being done but also gives the development team some ‘wiggle room’ in the project plan. And wishes are just about communication.

As a rough guideline, Must items should make up 50%-75% of the project because these are the things that the team has to agree is worth spending resources to get done. Having Hopefullies gives some buffer to make schedule but having too many makes the project outcome too vague.