The Key to Prioritizing Internal Products
Prioritization is about answering the question: Which problems do you solve first? For software, this translates to: Which feature do you ship first? It is relevant once problems have been discovered and defined, and now solutions have to be designed and delivered.
In the world of consumer-facing product management, the product epics contain features that unlock value for customers. The feature being used could have a direct proportional impact on revenue. Teams prefer to measure customer impact by using quick feedback KPIs — user engagement, click-through rate, add-to-cart rate, cart size, etc. There are models that tie them to each other and also to revenue metrics to quantify business impact.
Estimating customer impact paves the way to prioritize features, epics or themes for the product team.
RICE, RIE, Kano model and Moscow method provide the indexes to sort solutions in a logical order of importance, thereby aligning all stakeholders — engineers, designers, marketing and others — to appreciate why they are working on feature C over feature B.
The realm of internal products
In the realm of internal products, the picture is different. During product discovery, the PM interfaces with multiple internal stakeholders, each with their own ideas of what the problem is and how it should be solved — how the addition of one button would solve all their problems. It might make the stakeholders’ lives easier, but it probably will have no foreseeable impact on any business metric. Some of us still go ahead and do it. The IT project management methodology still practiced in several big organizations, disguised as internal/technical product management, mandates taking in the “requirements” from internal teams and adding them to the engineering team’s backlog.
The software team then democratically prioritizes those tickets. Or the PM, with fresh memories of shouting stakeholders, prioritizes it based on the stakeholder’s volume. The worst is when prioritization is based on HiPPO (highest paid person’s opinion). The features are shipped, stakeholders are temporarily satisfied, and the cycle repeats with no end and no purpose.
Early in my career, I was in a situation where I was expected to simply take in requirements from marketing and get a tool developed. Over time, I realized the tool would help increase the productivity of the marketing team, so they could have more free time, but it would not increase the productivity of the overall business. The marketers could create a campaign experiment in less time but would still need to wait for a significant amount of data to make decisions. Marketers now had a shovel instead of a spoon, but no business or customer metric moved.
Defining your customer and your process
The problems emerge because we try to use the same frameworks used by PMs interfacing with customers, then retrofit them into internal domains.
Prioritizing, then, becomes difficult, as identifying the customer (and thereby the impact) here is unclear. The customer is not the same as the end user of your product. The user of your product, here, is someone in marketing or operations and is not the end customer. You might ask, “Why are they not a customer?” To that I’d say, because they do not choose your product out of their free will and do not pay anything for it.
For the right impact in the right direction, we have to take a leap and say: Even for internal products, the customer is the same as the business’ customer, and shipping your tool or product improves the status quo of how the business operates, which in turn, helps the business serve the customer better. There’s no other sustainable way to operate, for any product team.
Although you share the customer with your customer-focused PM colleague, the difference is in the impact horizon. The impact that you, as an internal PM, drive will be a process. I refer to this as how the business (or a sub-team) operates to provide value to the end customer. Process is defined as follows:
The product, the user and the data it is processing are all part of a larger process that has a purpose. With a change in the tool — from paper to Excel to monoliths to microservices — there’s an anticipated impact on the process. If that impact is positive for the business or the customer, it’s a job well done.
Internal product delivery should put into motion a new, improved process that creates more value for the customer in the end.
The impact internal product teams drive is felt on a business process in either of two ways:
- Increase in efficiency of the process
- Increase in effectiveness of the process
Let’s look at an example:
When PMing for a large publication, I built a viral-video-meter, a tool/product that would help editors curate videos from the web as soon as they start to trend. If such videos were identified and published early, our followers would get good content to watch and share.
When looking at it from the vantage of business, I was driving an increase in efficiency: Videos are identified early or output is achieved in less time with the same resources. The process being affected by this tool was the publishing process. At the outset, it was essential to agree with all partners involved that the publishing process was within the impact-sphere of the release, so we could only focus on improving that. For different stages of the product rollout, we had to identify different impact spheres, and that governed the prioritization mandate. So if plugging in YouTube API allowed us to save our editors x hours a week vs. plugging in Facebook API, which saved 0.5x, we knew which one to prioritize. Most of the time, prioritization becomes easy when we look at the problem from one lens, against one ruler.
The process improvement claim is the prioritization mandate you need.
For further iterations of the tool, we aimed for efficacy: How to filter out the noise and get only the right videos through to the editor.
Assuming the business problem has been identified, and we have a solution that proposes a new process with a new tool or product, it is essential that we, as PMs, not shy away from defining new processes. As internal PMs, we should mandate this. This is the “stakeholder management” part of the skill set coming into play.
To summarize:
- Identify the process the product delivery affects.
- Measure/simulate the process with your new feature delivered.
- Measure the gain in efficiency or efficacy vs. the old process.
- Prioritize between features based on the value of the impact.
