Using a prioritization model like RICE? You’re missing one key component that can make all the difference
Ask anyone and you’ll get a different answer every time. Deciding the priority for a roadmap can be one of the toughest things in a PM world. And truthfully, no matter how many models exist out there, I don’t think it’s an exact science. And that’s okay.
But the more I grow in this profession and network with others in the space, the more I see these key factors emerge as the most important variables in the process.
My prioritization of a roadmap comes down to the following:
- Business Goals
- Business Impact
- Customer Impact
The business is the ultimate driver of the roadmap
Common prioritization models like the RICE framework act as if the product development team builds in a vacuum, with no strategic consequences, and I think this is a miss. Business goals are the real driver of roadmap prioritization, because let’s face it, we’re running a business, and that business has real metrics that we have to hit.
The obvious goal that comes to mind is “more revenue”, but your actual, drilled-down strategy offers more than meets the eye on exactly how you deliver. If your quarterly business goal is to expand cross-sell opportunities for enterprise customers vs. new marketable features for the remaining 80% of your customer base, this ultimately affects what you decide to prioritize.
There are also the other goals, like customer retention / reducing churn, and strategic slides into new verticals. All of this most certainly affects what we decide to build, and I’d say oftentimes it is the first filter for what even makes it above the cut line.
Non-negotiables: All of us have them
Let’s talk about non-negotiables. The “must-haves”. You may scoff, but we’ve all been in a situation where these are present. Depending on your industry and business maturity this could be something compliance-related, a customer deal-breaker, or adopting new tech to further scale.
I’m not saying any of this to say I condone filling your roadmap with escalated requests and “must-haves”. It’s actually quite the opposite. What I’m saying is that I’d rather not sweep them into a corner and pretend they’re untouchable when we’re building our prioritization model. Rather, I think it’s a good practice to incorporate these into the planning process and at the very least “consider” even these items.
At the very least, you should be asking why, even for your non-negotiables, and tracking these with as much detail and scrutiny as any of your other roadmap items. When you plug these into the same model you may come to realize some of the “non”-negotiables are actually more negotiable than you first thought.
Measuring the impact to your business
Now we get into the more commonly used variables. Measuring the impact of each new feature to the business can be done by honing in on the specific metric most closely aligned. While much of it ultimately ties to revenue, it may be better to get out the magnifying glass and actually focus on adoption and usage of the product and/or feature to really get a good gauge of whether it’s moving the needle.
An example for impact could be: We expect this new feature will drive 3-month adoption by 40%, resulting in a 15% reduce of YoY customer churn, and measured by the usage of the feature as represented by number of times the feature is accessed in the app.
Impact may or may not be that granular, but I think it’s good to at least know the high-level business driver you’re targeting. As we become more mature in our product org we are trying to establish success metrics for everything we build.
Simple enough. Get granular in your customer segments and understand the scale at which each segment will benefit.
Measuring the impact to your customer
Something to be considered is not only how our business is impacted, but what the difference is for the customer. Whether this makes it into your equation is left up to you, but some view it as needed alignment to ensure we are solving problems in the right ways.
It can be a good practice to compare this directly to your business goals. If our goal is to drive upsell to a new add-on, and the features we build directly complement this add-on to push it over the line for customers in their decision-making process, the expectation here would be that whatever it is we’re building delivers significant value for the customer in terms of net new functionality, improved experience, time savings, or all of the above.
An exponential business goal tied to a linear impact to customer experience can, and will, result in missed targets.
Effort is the kicker. We do our best to lean on engineering here to get real estimates of numbers. Throw this at the bottom of the equation and let your world get rocked when the simpler, less-glamorous features start to creep above the cutline.
Putting it all together
How exactly you pull these components together and score is subjective. Personally, I use business goals as a multiplier. Is the predicted business impact in line with the higher-level goals of the business? Bonus multiplier for those features! Does the customer impact not match the business expectations? Apply a deduction.
It’s rarely a perfect science, but we can get it close, and learn a few things along the way.
If you enjoy reading stories like these and want to support me as a writer, consider signing up to become a Medium member. It’s $5 a month and gives you unlimited access to stories on Medium. If you sign up using my link, I earn a small commission.