This content originally appeared on Lea Verou’s blog and was authored by Lea Verou
When developing a software product[1], there are always way more ideas about what to do next than there is time to do them. This is where roadmap prioritization comes in. However, prioritization is anything but straightforward. There are so many different factors to balance, such as:
- How much overall value will this bring to users?
- How much (design/product/engineering) work is it to implement? (Effort)
- How confident are we that this will work?
Many of these can be broken down further, for example 1. can be broken down into:
- How many users will this affect? (Reach)
- How much of a difference will it make for each of them? (Impact)
Smaller or grassroots teams tend to do this kind of cost-benefit analysis with their gut, but there are actually entire frameworks and methodologies to assist with this, typically used by product managers. These are essentially a formalized way to standardize what good prioritizers do intuitively. However, even if you are intuitively good at prioritization, a standardized methodology makes it much easier to drive consensus. It’s much easier to argue with someone’s intuition than with a formula.
The RICE framework is probably the most popular. It provides a formula that calculates a score based on Reach, Impact, Confidence, and Effort.
However, there are many, many, many more frameworks and methodologies out there.
However, all of these operate on a model of engineers as a resource to be allocated, not as stakeholders with their own interests. As anyone who has tried to convince engineers to implement anything knows, it is not quite accurate.
There is a big factor that none of these frameworks appear take into account: Engineering Interest. Between two solutions, one that involves minimal engineering effort that the engineers are pushing back on, and one that requires much higher engineering effort that the engineers cannot wait to work on, guess which one would take less overall time? Unless the difference in complexity is truly massive, the latter will almost always be faster. In fact, interest makes so much difference in engineering times, that often this holds true even if only a few of the engineers are excited (and the rest are neutral). Convincing engineers to implement something they are not interested in is an uphill battle. Even when you succeed, or they do it anyway because they have to, it will take a lot longer than if they were actually invested. You might think this is only true for less structured setups like startups or open source projects, but I have seen it even in companies as big as Google. “But…”, I hear you saying, “isn’t it a PM’s job to convince engineers to implement things?” Influence without authority is a core skill for PMs, after all. Sure, and a skilled PM can indeed convince engineers to implement things they were not interested in to begin with. But they can rarely convince them to actually be excited about it; when it happens it’s more of a happy accident than a proof of the PM’s exceptional skill at persuasion.
Furthermore, making how the engineers feel about a feature a factor in the prioritization process makes them feel more seen and is all around good for morale. And it’s not a concession; just a formalization of what is already happening.
But Engineers are not the only people in a product team!
True but each product feature usually involves a lot more engineering hours than any of the other roles combined, so when release dates slip, the bottleneck is nearly always engineering. There are many opinions about the ideal ratio of PMs, designers, and engineers, but they all agree that engineers are the most numerous role. There are even companies with 50 engineers per PM (!) whereas the ratio of e.g. designers to PMs is usually 1:1 or 2:1. So, while we could also take into account the interest level of everyone in a product team, it would complicate the formulas, with little effect on the outcome. Also, the interest level of PMs inherently factors in, since they are the ones doing the calculation. Not to mention that essentially Confidence is essentially a proxy for PM interest.
I can’t help pointing out how meta it is to do cost-benefit analysis on how a cost-benefit analysis framework should be modified.
So how to take Eng. Interest into account?
We need to be careful here, because if Engineering Interest is given too much weight, we end up with the kind of prioritization that is done in a non-user centered organization. We don’t want to end up in a situation where engineers just implement whatever seems cool with no regard for use cases or user needs. Ideally, we want it to just give the overall score a little nudge in the right direction.
Let’s take RICE as an example, and other frameworks can be adapted in a similar way.
What if we replaced Effort with Complexity / Engineering Interest?
This would make the formula:
One issue is that there is not exactly consensus about what the scale is for all four RICE parameters. Let’s take Effort as an example:
- The original definition by Intercom says "Effort is estimated as a number of “person-months”.
- Some sources use a 1-5 scale
- For Others, anything goes, as long as it roughly correlates with time: “Effort can be calculated as person-hours (or days, weeks, etc) or as simply the number of days/weeks and/or sprints it will take the team to complete.”
- Some even use the same scoring system as for Impact: .25, .5, 1, 2, 3.
I’m using the term “product” here quite liberally; to include any substantial software artifact used by others. ↩︎
This content originally appeared on Lea Verou’s blog and was authored by Lea Verou
Lea Verou | Sciencx (2025-01-03T02:49:16+00:00) Engineering Momentum as a Prioritization Factor. Retrieved from https://www.scien.cx/2025/01/03/engineering-momentum-as-a-prioritization-factor/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.