RICE, the Kano model, and other mathematical models of prioritization offer a method to boil down complex information into easy scores. What happens when we take them to their extreme - and use them as the Product Managers themselves?
So, it’s another start to another day.
You walk in the door, check your Slack, and there’s a couple enhancement requests from the support team, another feature idea from the sales team. You attend stand-up, and the engineers mention a new piece of tech debt that’ll only get worse the longer it’s ignored. When you wrap your day interviewing a user, they’ll describe all the UX issues (and that one critical bug) that makes their everyday workflows tedious and frustrating.
It’s all important to somebody, but it can’t all get done in the day, the month, the quarter. Your team doesn’t have infinite time, or people, to design, build, and sell it all. Somebody needs to prioritize those problems. And that person is you, the Product Manager.
If it feels like an intense responsibility, it certainly can be at times. Choose the wrong item, and customers churn, sales demos suffer
But what if it didn’t have to be like this? What if you could outsource?
There are a myriad of different product management prioritization formulas: the Kano model, RICE, value-vs-cost, and so on. Each offers a pleasant solution to the prioritization dilemma: instead of a flawed human
Let’s try thinking about this a little more a
requests from Sales, Customer Success, and customers themselves,
We might formulate the work of Product Management by dramatically simplifying the tasks, then adding consequential layers of complexity on top.
Product Managers live in an environment where they receive a boundless number of enhancements, requests, and ideas from a variety of stakeholders, customers, and prospects. These may come in the form of bugs, enhancement requests, features on a roadmap, or individual user stories. In essence, all of these might be seen as an array of problems (P), which may later in the process be paired with a specific solution (S). We simplify by assuming that for each prescribed solution suggested from a stakeholder, customer, or prospect, the Product Manager will conduct the work necessary to retroactively understand and describe the problem, and focus on solving the problem in general.
In this framework, the job of the Product Manager is, in essence, to decide the small number of Problems to be given a refined solution. In the majority of situations, Product Managers also collaborate with a team of designers and engineers to decide upon, validate, and test a solution to this problem. We first consider the “earlier” job of the Product Manager, namely to decide what problem to bring to a team of designers & engineers for a solution.
Let us simplify further. In this ideal world, the Product Manager can discern with exact precision both the value (V) and the cost (C) of solving any given problem.
- We measure value in dollars retained or gained by the business if the problem is to be solved. This applies both to critical bugs that will cause a customer to churn, and to important new features that will cause a prospect to be won.
- We measure cost (c) in person-days spent accomplishing the problem’s solution.
- In truth, Cost should be measured in dollars spent by the business employing a workforce to solve the problem. However, this would require approximate salary information for all team members associated with solving the problem, a task tedious at best and an HR violation at worst.
- Here instead, we make the naive assumption that all staff members are paid an equal amount.
And so, we have our first, naive model of what and how Product Management is. It is the act of first discovering the set of all problems P, and investigating each thoroughly such that each is associated with a value V. Finally, the product manager eventually learns to associate each with its own solution, or facilitates this discussion with the team.
[((P1: V1), (S1: C1)), ((P2: V2), (S2: C2)), ..., ((PN: VN), (SN: CN))]
# ^ greatest value ^ least valueFinally, with these numbers at play, the proper approach to Product Management is simple. Find the problems with the greatest value-to-cost ratio. Sort by their value-to-cost ratio, and continue indefinitely, with each one earning the business money.
Now that we have a simplistic mathematical approach to Product Management, we can discern how exactly Product Management must remain an art, and not a science.
Even within this idealized world of perfect knowledge of problems and solutions, consider the following:
- Urgency plays a role in product decisions, which one can consider as a multiplier of Cost. For example, suppose there exists a critical bug that exclusively impacts the top customer of the company, so much so that they threaten to churn. Upon the bug’s discovery, the Cost is proportional to the churned ACV of the customer. However, if this bug is delayed behind other work, and the customer churns as a result, then the Value of the bug is diminished. In general, the value of solving all problems fluctuates over time. It is a critical facet of product management to discern which problems are in accordance to which “shapes” of the Value vs. Time graph.
- Vision and Strategy are critical components that cannot be overstated in their importance, but are forgotten by our mathematics. Take the example of the just released MVP of a new company, made somewhat competitive due to a compelling underlying machine-learning technology making it a novel entrant to an old, undisrupted industry. Thanks to an innovative Marketing and Sales team, the company lands a large enterprise customer in its pipeline, but they refuse to complete the purchase unless 5 critical problems are solved. These problems would require the product to expand its underlying technology significantly, and launch the product into a new market where they could begin to compete with other tools. The leader of the Sales team meets with the Product Manager, asking them to prioritize these issues at once. All five problems are at the very top of the value-to-cost ratio given the customer’s high ACV. Should then the PM say yes to this proposition? The issue lies in the fact that not all problems are independent of one another. The solution to some problems beget more problems. Suppose that our PM, committed to the mathematical cause, agrees. The Sales & Marketing team rejoice with the PM in their good fortune, leading to a lengthy night of alcohol and larger-than-life storytelling. Sadly for our PM, this begets a cycle. There are no limits to the number of times this may happen, and a precedent has been set. Soon enough, another large customer comes down the pipeline demanding a similar set of problems that launch the product as a novice entrant into yet another market. And another. And another. All justified by high value-to-cost ratios, and indeed, the money flows. Immediately, anyways. In another year’s time, they have another large enterprise customer in their pipeline, looking for a specialized tool. Yet this time, this prospect is lost to competition. A competitor has outdone the once new startup in their own native market. In the time spent by the Product Manager, Designers, and Engineers, their competition has become hyper-specialized. Where our protagonist company chose to build out capabilities themselves, their competition strategically integrated with a network of technologies to make up for their losses. In this way, solving each problem is not only associated with monetary value, but also with a kind of “direction.” Even the biggest value-to-cost ratio’d problems may wind up circling around to itself, resulting in nothing of novelty compared to competition. The strongest companies tend to build upon a highly specialized basis of problems, then expand outwards once they have a strong foothold in their respective markets. A PM’s plan for this direction may helpfully labelled “strategy.”
- Build, Buy, or Partner. As previously discussed, the world of technology is not one of simple binary choices: to build or not to build. Any technological problem can be resolved in-house, be handed to another company to solve, or be rectified by a strategic partnership where two or more companies promise to cooperate with one another. A more costly solution to partner with a vendor to solve several problems at once, both present and future, may prove optimistic.
- The Future’s Problems. One final flaw in our mathematical approach is that all measurements are based upon the current state of the market. However, the product that adequately predicts the future state of the market’s problems, and arrives at a just-in-time solution, will be richly rewarded, versus the Product Manager who solely measures the present moment and build solutions too late for their full effectiveness.
Even in a perfect world where all knowledge, present and future, is known, the mathematics becomes quickly too complicated to discern or execute. Shall we measure our problems against “vision-fit”? Shall we explore all O(n) options to build, buy, or partner with the infinity of solutions that exist? Shall we discern and plot in three dimensions the value-vs-time curve that belies each problem?
There is no single mathematical approach to Product Management. No formula. No calculator. But, mathematics is a useful tool.
However, then we must ask which tools do we employ, when, and to answer which questions?