I have written about the topic of prioritization before, but maybe with a title that was too oblique – “Applying Engineering Business: Binding Constraints.”  There I made the point that at any one time a startup tends to have only one binding constraint.  It’s the problem the startup needs to solve to get to the next level.  That could be the next financing, or hiring people or finishing a key project.

But what about more fine grained prioritization?  What about the long list in front of the product and engineering teams?  I often find myself surprised by how little thought goes into trying to prioritize that list.  Sure – (almost) everyone has a list that can be sorted by priority, but when you dig a bit deeper it often becomes clear that those priorities are largely subjective and at best loosely connected to strategy.  Also, generally missing is a second data point which is how easy or hard a particular item is.

So what should you do instead?  You should put projects into a matrix where one axis is impact and the other axis is difficulty.  You should only focus on high impact projects / features and have a healthy mix of easy and hard ones.  The impact threshold should be higher, the harder the project or feature.

How should you evaluate impact?  There is no one single answer here but a bunch of guidelines may help.  First, for something to be high impact it has to be “on strategy” (which of course requires a fairly clear formulation of strategy – more on that in a separate post).  Second, if it is aimed at existing users, what percentage of users will it touch?  Something that touches 80% of users is generally higher impact than something that only 5% of users care about.  If you have a feature that only 5% of users care about but you think more users should care than the high impact project is probably not trying to make that feature marginally better but rather exposing it to way more users.  Third, if it is aimed at new users, what percentage of potential new users is this relevant to?  Again, for something to be high impact a high percentage of people not yet using the product or service need to care about this.

How should you look at difficulty? As a rough rule of thumb: if it can be built and released in a couple of weeks it’s easy.  If it is between a couple of weeks and a couple of months it is medium and if it’s more than that it’s hard.   The impact threshold for hard problems should be way higher than that for easy ones with medium somewhere in between.  If you have a small team you may not want to work on more than one hard problem at a time.  In fact, picking the hard problem should probably be informed by thinking about the binding constraint.

If you haven’t done this so far, I strongly encourage you to map your projects onto the impact-difficulty matrix.  It tends to provide a lot more clarity.  One more point on impact: whenever possible use data from logs, surveys, user observation to make this as objective as possible. 

I have written about the topic of prioritization before, but maybe with a title that was too oblique – “Applying Engineering Business: Binding Constraints.”  There I made the point that at any one time a startup tends to have only one binding constraint.  It’s the problem the startup needs to solve to get to the next level.  That could be the next financing, or hiring people or finishing a key project.

But what about more fine grained prioritization?  What about the long list in front of the product and engineering teams?  I often find myself surprised by how little thought goes into trying to prioritize that list.  Sure – (almost) everyone has a list that can be sorted by priority, but when you dig a bit deeper it often becomes clear that those priorities are largely subjective and at best loosely connected to strategy.  Also, generally missing is a second data point which is how easy or hard a particular item is.

So what should you do instead?  You should put projects into a matrix where one axis is impact and the other axis is difficulty.  You should only focus on high impact projects / features and have a healthy mix of easy and hard ones.  The impact threshold should be higher, the harder the project or feature.

How should you evaluate impact?  There is no one single answer here but a bunch of guidelines may help.  First, for something to be high impact it has to be “on strategy” (which of course requires a fairly clear formulation of strategy – more on that in a separate post).  Second, if it is aimed at existing users, what percentage of users will it touch?  Something that touches 80% of users is generally higher impact than something that only 5% of users care about.  If you have a feature that only 5% of users care about but you think more users should care than the high impact project is probably not trying to make that feature marginally better but rather exposing it to way more users.  Third, if it is aimed at new users, what percentage of potential new users is this relevant to?  Again, for something to be high impact a high percentage of people not yet using the product or service need to care about this.

How should you look at difficulty? As a rough rule of thumb: if it can be built and released in a couple of weeks it’s easy.  If it is between a couple of weeks and a couple of months it is medium and if it’s more than that it’s hard.   The impact threshold for hard problems should be way higher than that for easy ones with medium somewhere in between.  If you have a small team you may not want to work on more than one hard problem at a time.  In fact, picking the hard problem should probably be informed by thinking about the binding constraint.

If you haven’t done this so far, I strongly encourage you to map your projects onto the impact-difficulty matrix.  It tends to provide a lot more clarity.  One more point on impact: whenever possible use data from logs, surveys, user observation to make this as objective as possible.