Systematization: Making Things Simple, in Smarter Ways
The greatest superpower for product managers.
The world is complicated, but the business world is one hell of a ride. Business administration includes thousands of metrics and benchmarks in different views, segments, and cohorts. It’s dozens of customer journeys, hundreds of processes in teams and subsystems.
With all that information coming in, human brain can just explode. We have to simplify systems to make business decisions. But that simplicity increases the risk of making costly mistakes for a manager.
1. The problem
Decomposition is a classic approach to simplifying systems. Basic example: making an org chart based on the metrics that any given department is responsible for. Articles with life hacks on how to solve the “Sales vs. Marketing” problems are all over the web.
Marketing is responsible for lead acquisition and its cost. Sales covers payment conversion. As a result, if the marketing team does a great job on the cold channel, it leads to a drop in certain metrics of the sales team as they are out of the marketing competencies.
The problem of marketing and sales is just a tip of the iceberg. That conflict is easily manageable /if only that was so easy/ with introducing KPI/OKR adjustments for those departments and improving cross-functional processes. However, if the conflict of metrics is not that obvious, the bigger problems begin.
Decomposition of metrics in product management reaches incredible heights: funnels, AARRR / HEART/ NSM frameworks, unit-economics. Dozens of toolsets for decision-making assistance shamed young product managers with deceptive simplicity. Get AARRR, realize that activation conversion is dropping, make three landing pages for the key funnel stage, start the A/B test and choose the best option — how hard is that?
But the devil is in the details. Three months after the final option hook-up, it turns out that we have a retention slap on the cohort 3rd month. After debugging we see that we clearly brought clients’ attention on getting the value after three months of product use.
And it’s obvious! How come we didn’t think about that? Because we were only focusing on one of the funnel stages when we designed the experiment. We could think of some correction at the end of the 3rd month from the start, but that would make the A/B test more complicated. Honestly, we didn’t even think about that.
Another mistake that I’ve seen in different companies is not running a super promising experiment because it doesn’t fit the org chart. Seriously? Who would take care of the referral program before the payment? Since the referral is covered by the product, and the payment is taken care of by the sales, right? OMG, whatever! How do we introduce an alternative selling scenario without the sales team? Remember that marketing is only in charge of the scheduled calls, while sales ensure the call conversion to payments? These cases are killing me, but there are a lot of them. Really.
2. What to do?
Let’s come back to a person being unable to constantly keep a complex scheme with a bunch of elements and dependencies in their mind. There are two options.
The first one is to break this scheme into separate chunks, isolate them, take only one and focus on it. Usually, this is the default way we use.
The other one is to structure all processes so that the basic scheme can fit in your head. You can draw certain big units in detail, and approach the whole system, opening only the units you need right now.
While structuring, we employ two tools at a time: first, we draw the scheme, since paper (or miro) does not have a memory limit, unlike the human brain. Second, when we design future solutions, we keep the system as a whole in our head, which allows anticipating the effects of the second, third, etc. orders with better accuracy.
Unfortunately, the second way is used pretty rarely. It requires thorough artifact preparation before outlining solutions. We could write a separate article to describe the way we study every system. However, in a nutshell, we can seldom study the whole system top-down. Usually, we start to look at it from the point we are at. We know what is near us in great detail, but we have trouble picturing what is going on slightly further away from our circle of influence.
Remember your last change of job? You come to a team as a product manager. You get fully immersed into how the development team works, you see the backlog of the latest changes and research results. However, how does the analytics system work in detail? How is the marketing channels mix made? What was the logic behind choosing countries for the launch? Who is in charge of connecting several key back-office systems? To get answers for all these questions, you will need to work alone, moreover, you will do it after hours.
3. But still, what to do?
First, you need to acknowledge that structuring the system knowledge is a must. It pays off starting from the very first serious decision you make.
Then you are to study and describe the system top-down. It is better to do this from several angles. I can think of at least two: user path and company P&L.
Studying from the user-path standpoint starts from a basic description of the customer’s CJM, then you gradually add up forks, internal business processes, motivation systems, and many other things. Studying from the P&L perspective starts from basic financial documentation of the company, then you gradually go through disclosing incomes and expenses, arriving at user path metrics, but looking at how they influence business.
While studying the system of the kind, it is essential to record them as a scheme. Moreover, it is better to use a simple (or not too simple) legend from the start to visually divide high-level and embedded processes. You can use a BPMN legend or even a relevant engine. However, if you are not a pro in describing business processes, BPMN can put you off with its complexity, which will lead to turning the idea down completely. In this case, it is easier to open Miro (or a similar service) and make a scheme there, employing basic units.
The more, the better. Designing any solution will require some more actions.
Action one. Choose which metric you would like to influence, and then go to the top of the metrics tree to see what the project affects. Most often, this is either the growth in income or drop in expenses. Then you are to go down the metrics scheme, paying special attention to the branch, on which your project is focused. If your project is aimed at income growth, you keep this direction in mind anyway. More importantly, you should check if the system can get the increase in the expenses you did not plan.
Action Two. Run your project through the user’s entire CJM to see how it can affect each particular section of CJM. The more operations you have in the product, the more unexpected consequences the project can cause. Do you have line employees’ KPI aimed at the metric you are cutting down? Be ready for a surge of anger. What if calculating the necessary resources for support does not consider your innovations? You get an overloaded or underloaded support team, and broken SLA. Run the change in detail through the entire scheme, do not skip even the steps that are far away from your circle of influence. Even your notification messages can prepare the whole system for the change.
Action Three. Ensure end-to-end monitoring for the change effects across the whole system.
At least, track the entire unit economy and product cash flow during the experiment.
If you do everything correctly in the first two steps, you will get a better picture of the metrics you are to track. This will include KPI, SLA, and other second and third-order metrics that affect your project. Even a minimum of the unit economy and cash flow will show you the key positive and negative effects of your experiment better than a single dashboard demonstrating the conversion of the modified funnel section.
This approach has some perks. You can hold an experiment that will not improve the target metrics, but will significantly and positively change the side picture. Thus, it will essentially be successful, even though it can be eliminated in a straightforward analysis.
I had a case when switching from selling packages to offering a subscription model did not bring the expected increase in client LTV, but it shifted cash-in inflow dramatically in the early months of the client’s life. This shift had an incredibly positive impact on the company’s investor money cash-burn and allowed a different disposition of the available funds. The initial idea of the experiment was different, so the experiment team was focused on other numbers. A full-fledged analysis across the entire metrics pyramid allowed us to see positive externalities just in time to benefit from them.
4. A few words for the C-level executives
This approach to decision-making is even more important when shaping the orgchart and goal-setting of the company’s departments and divisions. To avoid dysfunction and sabotage of promising projects that contradict the structure, but help the business, it is important to openly use systematic goal-setting, while working with all departments.
The approach can be executed in different ways: through cascading the top-level metrics into OKR for all departments or employing a careful selection of counter-metrics at all levels. However, the most important part is to constantly communicate that “positive impact on the business as a whole is always more important than the short-term impact on your KPI metrics” in the culture.
KPI can and should be revisited. Orgchart can change. Only business objectives are fundamental, and every single person involved in decision-making must realize how exactly their actions affect business objectives. Why this action is the most valuable one right now.
In his book “Winning Now, Winning Later”, David M. Cote calls these business dysfunctions “intellectual laziness”, arguing that if you keep conveying these ideas systematically, they will be embraced by your employees and internalized in your company values. He encourages critical thinking and root cause analysis for every rule. Re-envisioning every guideline will help steer through these dysfunctions.
5. Anticipate Changes
You must always anticipate how the changes will affect the company in total, and assess project priorities regarding how they influence the business as a whole, instead of just one metric.
Each change has the aftermath of the second and third orders, and it is vital to assess, anticipate and control them.
KPI, structure, regulations, and processes are mere tools for achieving business goals, they can and should be revised, they shouldn’t draw decisions that would contradict these objectives.
Think more — it always pays off!
Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.
