The Problem
At scrappy startups and megalithic enterprise companies alike, deciding what to prioritize with available engineering resources is always a challenge. Everyone has an opinion aligned with their own agenda. Stakeholders clamor for initiatives that will increase their visibility or will simply make the lives of the members of their department easier. All of this is well-intentioned and to be expected, but it’s often difficult to cut through the noise to find what endeavors will truly move the needle.
As a product management leader at Oracle and other enterprise software organizations, the situation was complicated. We had top-down strategic directives, collaborative partnerships with other divisions, as well as numerous product teams within our own structure vying for our attention. Without an objective measure of what to work on, the loudest person in the room often won that attention. Lack of ownership began to creep in on some engineering teams as the projects they worked on seemed arbitrary and unattached to business value.
The Solution
I set about to create a project prioritization framework to cut through the noise and apply a sensible way to evaluate project requests on their own merit. We came up with several factors to plug into a formula, each with an input rating of 1-3. We then weighted each factor based on which we wanted to emphasize. As part of quarterly planning, we gathered the initiatives on a spreadsheet and plugged in the ratings to derive an overall prioritization score.
This solved 3 problems simultaneously:
- It reduced arguments about what to prioritize as the inputs and formula were all transparent and had been agreed upon previously.
- Because the inputs were now so critical to the prioritization based on a mathematical formula, greater care was taken to prove the business case in hard numbers.
- The engineering teams working on the initiatives could more plainly see the business value we were hoping to achieve through their efforts.
When a given prioritization score wasn’t what we had expected, that spurred conversation about the relative weightings of factors, and adjustments were made to suit our sensibilities. At the end of the day, prioritizations frameworks such as this are meant to gently guide decision-making and expose competing emphases. They are not meant to be a roundabout way of forcing an agenda on a product development org.
Product and engineering leadership were able to come together and agree on what projects to prioritized based on the outputs of the framework without the drama of quarters past. It also served to align everyone around the quarter’s objectives and kept teams focused on what matters.
A Word of Caution
The goal is to make project prioritization as objective as possible. Don’t trade subjective prioritization for a facade of objective prioritization where the inputs aren’t measurable. For example, a rating for monetary impact should have well-defined, hard numerical boundaries for each rating. For best results, have a single owner make final rating determinations where objective measures are impossible or difficult in order to mitigate stakeholders overstating the inputs and thus unfairly gaming the system.
The particulars may vary, but typically such a framework should include at a minimum the 4 factors below. Each may be complex in its own right depending on the situation and may be split out into sub-factors, weighted independently if desired. There are numerous prioritization frameworks available, and still more tools to help you to utilize them. However, I would argue that any such framework which does not take into account all of these 4 factors is incomplete at best. I typically use a weighted scoring mechanism as the factors and weightings can be easily changed, and it’s fairly simple for stakeholders to understand.
Strategic Alignment
Does the project move us toward our strategic goals set by leadership? Some ideas may be great on their own merit, but we all need to be rowing the same direction in alignment with our product vision.
Monetary Impact
What’s the revenue potential if we make this change? Or, how much money can we save by making this change? Some startups are primarily focused on revenue growth over all other concerns. In such cases, revenue potential may be split out to its own category and weighted differently. This factor is sometimes used as a counterbalance to User Impact, meaning there may be projects that will be very important to fewer customers, but very lucrative for the company nonetheless.
Development Cost (Effort)
Some projects, even if very impactful, are not worth the development cost. Is the solution complex and/or will it tie up an inordinate amount of resources to accomplish? We are not looking for precision, here; just a relative ballpark rating.
User Impact (Reach)
Will the change solve a long-standing complaint by customers? Will it make them more efficient on your platform? Will it reduce calls to support or just in general make your product more delightful to use? If so, how many users / accounts will be effected by the change? Don’t underestimate NPS or similar measures of user satisfaction. While vendor lock-in can be a powerful deterrent, you don’t want a situation where your customers hate using your product.