Something that’s always challenging for product managers is to know what to spend time on building and when. What will provide the best user value at any given time? There are a number of ways to make a determination but there’s also the pit falls to avoid, for example many development teams love the complex projects that cause them the greatest challenges, however these projects often provide low value for the end user. So what must be done is to estimate complexity and value that the feature will deliver.
It seems pretty obvious at first on how to determine priority, obviously the upper left quadrant should always be developed first. Low in complexity and high in value… No brainer right? Right. The second priority is somewhat less easy to identify; I personally would argue that the lower left quadrant (2) should in most cases be pushed out second, then moving to the more complex but higher value projects/features (3). With the fourth quadrant (4) being avoided until an easier way to deploy can be realized, with changes in technology and manufacturing processes this may well happen so keep these features documented and on your radar. I’ve also marked a section that may lend itself to further discovery such as conducting focus groups or IDI’s to determine priority.
In the future I’ll write more on this topic and show how I use more in-depth analysis to determine priorities using a Feature Prioritization Matrix.
Filed under: Build Priority
