The following blog post summarizes the seventh chapter of the Product Roadmaps Relaunched book by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors. Published on November 28, 2017. The seventh chapter is reviewed and summarized using my best judgment of the most essential information.
Product teams often risk getting sidetracked and turning into feature factories that churn out features without purpose. That’s why prioritization is crucial. It helps us stay focused on what matters. Otherwise, we might work on several small projects that seem useful at the time but don’t contribute much to the bigger picture. Ultimately, we would have wasted our attention and effort on things that don’t truly help the current goals.
“Opportunity cost is when you never get the chance to do something important because you chose to work on something else instead.”
You might think working on multiple small projects simultaneously is a good idea because they seem easy and won’t take much effort. But that’s what we call “Opportunity Cost.” You can’t do everything at once; spreading yourself too thin will drain your energy. Conversely, you can’t keep changing priorities whenever something new and shiny comes along. That’s what we call the “Shiny Object Syndrome.” That’s why it’s crucial to focus on a few things that matter and give them your full attention.
“Always assume you may have to stop work at any time.”
How Not to Prioritize
- Your or someone else’s gut
As much as your gut usually is correct, it’s not the point, don’t prioritize based on your gut, or someone else’s gut for that matter! This is recommended because this type of prioritization affects team productivity and morale. Because decisions are made that aren’t justified (because they’re gut feelings) to other team members, which can lower confidence in that decision. Take your gut feelings, evaluate them and bring them forward as an idea with justifications to back it up!
- Analyst opinions
Similarly, don’t prioritize solely based on an analyst’s opinion. Definitely do consider their point of view and any information they bring forward. But don’t take their answer as the be-all-end-all answer.
- Popularity
Letting your customers tell you what to build may seem like a fantastic idea. At the end of the day, they’re the ones paying for your product and making you money! But customers and users don’t always know what they want. Chat with customers about their experience with the product and understand their struggles and pain points. Use this information to inform the direction of your roadmap. But do not let the customers decide what should be built next.
- Sales requests
Like the last point, avoid prioritizing based on features to close the latest sales. Unfortunately, this happens occasionally; trying to land a big client and promises are made to secure the contract. But, with this scenario, you’ll prioritize a ton of your effort on features that only a handful of businesses truly need.
- Support requests
Avoid prioritizing based on support requests too. There is a thin line between what is considered “usable” or a “good user experience” and what bugs must be fixed to satisfy that, but not everything has to be fixed. The pros and cons must be weighed against all of your goals to understand better if it’s necessary.
- Competitive me-too features
Last but not least is the competition. Avoid prioritizing based on what the competition is doing. You’ll create a “commodity market” where you or your competitor will offer the same product and features, competing for the lowest price. Your competitors’ market share may seem significant enough to invest the time, effort and resources into cutting into their market share. But that means lower margins and lower revenue for the product. Instead, carve out your niche, understand what market you genuinely target with your product and go after them! Offer a separate set of features that may not include everything your competitor has, but include what your customers truly need.
Prioritization Frameworks
- Critical path (for new and existing products)
One way to prioritize is based on the critical path. The critical path is the absolute minimum needed to satisfy the user. To outline the critical path, user journey maps are created to understand better the steps the customer takes to accomplish their task. From there, you can narrow down what steps are necessary and which steps/features can be waived until later.
This method also holds true for existing products. Many product teams fall into the trap of never revisiting their critical paths. But as your product becomes established and your users become comfortable with your product, their needs will change, and your product must change with it.
- Kano
The KANO prioritization framework can also be seen as a categorization model. Once you have a list of features or themes your product could address, you can use KANO to categorize them into one of three categories: expected needs, normal needs, and exciting needs.
Although, it’s important to remember that to one customer or user persona, a need could be classified differently. For example, in a home, air conditioning could be labelled an expected need for someone who lives in a hot climate. But, for someone who lives in a warm-cold climate, this may be a normal need but not expected. It can be relative, and it’s important to remember this when categorizing.
- Desirability, Feasibility, Viability
The Desirability, Feasibility, and Viability prioritization method is a scoring method. For each feature, you score based on these three factors, tally their score and use the numeric value derived to inform your prioritization decisions.
- ROI Scorecard
Similarly, the ROI Scorecard is also a scoring prioritization method. This method can be customized to what suits your organization the best. You can include factors for value, effort, confidence, risk, or any other relevant factors. These can be scored on any scale (1-5, 1-10, decimal values), but typically, a t-shirt sizing (1 – x-small, 2 – small, 3- medium, 4 – large, 5 – x-large) is used to keep the estimate scores used generically but still relative to one another.
The standard formula used for the ROI scorecard is (value factors)/(effort) X confidence = priority score
- MoSCoW
Lastly, the MoSCoW method is usually paired with another prioritization framework to outline each item’s priority better. In MoSCoW, you would label each item one of the following “Must have”, “Should have”, “Could have”, or “Won’t have”. They are broad categories of where each item falls in the critical path. So, if an item scores very highly on your ROI Scorecard but is a “Won’t have”. Then it is easy to determine that it should not be your focus over an item that may have a lower score but is a “Must have” item.
There are many other prioritization frameworks above and beyond what is mentioned here. Still, these are a few that you can use to give you different perspectives on the priorities of the items on your roadmap. But use the guidelines mentioned above and the prioritization framework that works best for you and your organization to create your roadmap.