This is the first in a series of blog posts I plan on doing around product management and start-up topics and concepts.  In these posts, I plan to study and present my findings on problems that product managers and entrepreneurs can often experience. Some posts will be based on things that I encounter in my day-to-day work at a pre-seed startup company. Others will be based on things I read, with a focus on information gathers from Product Management for Dummies, The Product Manager’s Desk Reference, and The Startup Owner’s Manual.

I’ve always found prioritization to be one of the most fascinating and impactful activities that a product manager can engage in. Prioritizing the right features can mean being first to market, delighting customers and users, and shows thought leadership in the industry. Picking the wrong features can mean building products nobody wants, incurring a lot of development cost for a product that doesn’t sell or move the needle, and playing catchup to competitors without releasing anything that users view as new and exciting.

Because of the impact of this activity, I have spent a lot of time trying out different methods for prioritization. Many methods work and some are better in certain situations compared to others. Based on the type of business and organization, certain methods may be better than others. Below are two of my favorites.

Method #1 – Impact vs. Effort

My preferred method is to measure the impact and effort of a potential feature. From a blog post by Intercom and Hunter Walk, the impact vs. effort graph is an easy, simplistic way for a startup or small business to prioritize its efforts. When running a startup, feature requests and ideas can come in from all directions – VCs, team members, early adopters and first customers, etc. Typically startups don’t have a process for handling all of these requests and features just get worked on one after another in almost random order.

Measuring the impact of a feature against the effort it takes to complete is a good way to pick the right type of work. Early on, there may be a lot of high impact, low effort projects to complete and this is fine. But this type of low hanging fruit does eventually run out. After that, it is important to focus energy on high impact, high effort projects.

Determining the placement of features on the graph requires some deliberation. Executives and the product team must determine what high impact means for them. The same goes for effort. The team should spend time determining criteria that are important for determining these factors. After creating these criteria (and their relative weight), each product can be ranked accordingly. An example is provided below.

Sometimes the development team can get discouraged if all they get to work on are high effort features. It feels good to ship things regularly and to be able to show the work you have been doing. Because of this, I think it is important to select ideas to work on from each of the Impact vs. Effort quadrants (except for high effort, low impact). Once the list is created graphed, a product manager should use their best judgment to pick and choose how ideas a prioritized for work.

One consideration that is glaringly missing from this method is Urgency. In the course of business, there will inevitably be fires to put out and directives from the c-suite that have to be worked on ASAP.  Urgency can be worked into impact as a criterion — presumably, if a feature or project is urgent, that is because it will have a high impact. Additionally, I think it is always prudent to build some flex time into your development backlog. If something urgent comes up, it’s easy to work in because the team should (hopefully) already have extra time for it. If nothing comes up, then the next item on the list can be pulled in or the extra time can be spent on clean up or administrative tasks.

This method is ideal for startups and companies using Scrum for product development. The two factors can usually be ballparked pretty quickly if needed and comparing the impact and effort of two ideas can be straightforward without the detailed scoring. Estimated task effort is something that already takes place in the Scrum methodology so it may be more intuitive to measure the effort of a larger idea.

Method #2 – Cost vs. Benefit Analysis

Similar to measuring impact and effort, Cost vs. Benefit analysis is another good way to prioritize. Again in involves executives and stakeholders meeting to determine what is important when considering potential features. Consider the different levers projects could hinge on. On the benefits side, a company might consider factors like increasing revenue, customer value, and strategic value. Costs include implementation effort (amount of time resources will be occupied and unable to work on other projects), costs, and amount of risk involved with project success. The different features are then ranked for each factor (which may be weighted) and an ultimate score is determined[1]. The items with the highest score are the ones the company may want to work on first.

[1]This is a variation of the pugh chart decision-making matrix. (http://www.decision-making-confidence.com/pugh-matrix.html)

Cost versus benefit is also ideal because it lends itself directly to $ values.  In addition to somewhat qualitative criteria, the revenue and dollar cost impact of an idea can also be estimated and used to judge the value and priority of an idea. In the example above, the revenue category may be something like: 1 – <$50k revenue per year …….  5 – >$10M revenue per year.

Both methods have their pros and cons. The decision on which one to use, or the choice to use a different method, should be made based on what is best for the person and organization. Do you have another method you like to use? Share it in the comments below.