If you already have an experienced product manager on your team, they are probably/hopefully following some well-established product management process. But what about the early days of company formation before you have such expertise on staff? There are always more ideas (features/capabilities, new products, etc) than can be implemented in the desired timeframe. How do you prioritize the ideas to figure out which to focus on first? There’s a simple method I’ve used in the past that at least maps the ideas to various aspects of your business strategy. Let’s explore further.
Mapping to Business Goals & Priorities
The method first involves creating various categories based on business goals or current priorities and then placing each roadmap-related idea into one or more of those categories. The hardest part is coming up with the right categories but even that’s not terribly hard. Let me give you some examples and notice how I reworded a typical goal statement into a benefit statement to make the mapping easier:
- Helps us win more deals (ie – new customers)
- Improves customer retention
- Helps us scale
- Improves our profit margins
Depending on your type of business and your business-level goals/priorities, you might have totally different categories or maybe these exact ones are a good place to start. You might have a tendency to create a bunch of categories but I find that using my “So What” rule can help get to the real root category. Let me give you some examples:
- A feature that none of our competitors have = helps us win more deals
- A feature that dramatically reduces our customer’s required administrative effort with our product = makes customers happier = improves customer retention
- A new manufacturing process that allows us to reduce our price = makes us more competitive = helps us win more deals
- A platform rearchitecture that utilizes significantly less compute and storage = reduces our costs = improves our profit margins
- A capability that automates more of the customer on-boarding process = improves our efficiency = helps us to scale
You get the idea. Try to simplify the ideas to their root benefit to the company. Those are your candidates for the categories. And if you can also decide which of the categories are most critical for your current planning horizon, then you have prioritization among the categories. For example, in the graphic above, winning more deals is the most important category and improving profit margins is the least important (see the number of stars that designate relative importance).
This doesn’t mean you should choose to implement everything in the category with the highest important and totally ignore the things in the lowest priority category. It’s just another visual tool to help with decision making. In fact, notice in the graphic above that Feature 3 helps accomplish two different company priorities. Again, just seeing your product roadmap list in this visual manner can serve as a great tool.
Trade-Off Grid
Another approach is to think about criteria that can be used to create a 2 axis grid (x, y) that can be used visually to decide on priorities. I typically use this method in conjunction with the prior-mentioned method. They shed light on different aspects of the decision and can greatly complement each other.
Each roadmap idea is assessed against both criteria and placed appropriately on the grid. The grid visually communicates the trade-offs of the various options. It’s also possible to create two different grids in order to incorporate a third criteria (A versus B and A versus C) or fourth criteria (A versus B and C versus D). Here are some common criteria that I’ve used before:
- Value
- Could mean competitive differentiation or revenue potential (good for new products, not as clear for features that don’t carry a separate charge)
- Effort Required
- Could mean manpower or time needed to complete
- Risk
- Of being able to build to the desired specification
- Cost
- Could be the same as effort but in some cases is different
Above is an example that plots Value versus Effort (very common exercise). Here’s how to think about the results by quadrant for this particular example:
- Top-Left Quadrant: These are a slam dunk to prioritize high because they give the biggest “bang for the buck”. Unfortunately, you’ll be lucky to have something land here.
- Top-Right Quadrant: These are the tough debates and where you will spend most of your time discussing.
- Bottom-Right Quadrant: Why bother with anything that lands here?
- Bottom-Left Quadrant: I call items that land here “icing on the cake”.
Since items in the top-right quadrant present the toughest debates, consider creating a second X-Y grid just for those items. This second grid would introduce a second variable or perhaps use two completely different variables. It’s amazing how sometimes this additional perspective makes for a much easier debate.
Regarding the “icing on the cake” goodies in the bottom-left quadrant, you’ll want to be careful not to include too many of these because each feature you add to a product release carries at least some risk to the project. For example, have you ever added a “simple” feature to your product and it ended up causing something else to not function properly? After prioritizing high value items, look here for any easy things that can be “thrown in”.
Side Note: There are numerous nuances to assessing things like expected value delivered and effort required. One of my favorite business strategists and authors is Jason Cohen. He wrote a great article about fixing the ROI metric, including the use of some methods from scientist Enrico Fermi. You can read the article here and apply the concepts accordingly to your product roadmap prioritization.
Must, Should and Nice to Have
Regardless of which approach you decide from above, the next thing you need is a particular vocabulary to describe how critical each product, feature or capability is. I like to use the phrases “Must Have”, “Should Have” and “Nice to Have” because they are well understood. It usually works out that the Must Have features are the hardest ones to develop and/or take the longest. So it’s often the case that at least some of the Must Have features get deferred to a future release/version. What’s most important about this is the use of the common vocabulary amongst the team. Defending your recommendation that a feature be classified as Must Have is an important part of the prioritization process.
Accompanying the priorities is usually a timeline. But in the early days when much of your planning is directional (versus specific), you might not need to be precise about the timeline for the phases of your roadmap. Instead, use what I call “planning horizons”. I’ve got an article on that exact topic titled “Strategy Horizons Versus a Timeline” if you want to give it a try.
Time for Some Sanity Checks
Functioning Product?
If you just scoped your first release (MVP or V1.0) and you only deliver the features you prioritized using the above exercises, will your product be functional?
Logical?
Whether you just scoped your first release or an enhancement release (ie – v2.0), will the new features make sense if released together? There might be some features that didn’t rank high on the priority scale but, if combined with a feature that did, make for a much more impactful marketing story and customer experience.
Cycle Time
After selecting your list of prioritized features and doing the above two sanity checks, determine how long it will take to deliver everything on the list. Assuming the answer is longer than you can afford to wait, decide if anything can be dropped from the list for this particular version. This is a common dilemma that every product manager and/or engineering leader goes through.
Summary
Give these approaches a try. Find what works best for your company and your particular decision at hand. In fact, try doing the Priority Categories first and then create one or more Trade-Off Grids and use the two exercises to complement each other and provide additional conviction behind your decisions. Then consider visualizing the final results using something like the Strategy Horizons I describe in an article titled “Try Strategy Horizons Versus a Timeline“.
Also realize that product roadmap prioritization isn’t a one-time exercise. On the contrary, it’s something you should revisit on at least a quarterly basis. And during your startup phase you probably need to revisit it monthly because of all the validation activities and fresh inputs that enter the picture.
Remember that one unfair advantage you have against larger companies is your nimbleness and flexibility (see related article titled “ Unfair Advantage All Startups Have Against Big Companies“). Just be careful not to whipsaw the company by making dramatic changes every time without thinking a few steps ahead. That’s a topic for another article but in the meantime you might check out my article titled “3 Tools for Maintaining Focus“.
[/vc_column_text][/vc_column][/vc_row]