Kill RoB Pt. 2: IO Mental Models
This article is Part 2 of a series on ‘Strategy in Action: Killing the Rhythm of the Business (RoB).’ In Part 1, we talked about what the RoB is and how we could improve it. In this article, we’ll talk about the first step in moving away from the traditional RoB with the concept of an Integrated Data Table, and we’ll start designing one with an “IO Mental Model.”
The Integrated Data Table is the absolute heart of putting Strategy in Action. It aligns operating and financial metrics into a single data construct and forecasting model. This is what enables you to cancel budget season, eliminate quarterly forecasts, have your three-year plan done every month and transform the operations of your business from an inefficient, siloed, frustrating eternal negotiation of opaque business practices to an agile, always-on data driven operating machine that can do anything!
Ok, that’s hyperbole. But imagine that every month, you sit down with your team and look at operating numbers like website traffic and conversion rates in the same framework as recognized revenue, cost-of-good-sold (COGs) and marketing expenses. Not only are all these operating and financial metrics connected in the same model, every key metric is forecasted for the rest of the current year and two years into the future. If someone asks what you think your conversion rate for a customer segment is going to be in three months, you know. If someone wants to know what you are spending marketing for the holiday period based on what sales assumption, you know. You know everything [clap] every [clap] single [clap] month [clap].
It may not be obvious beneath all the business jargon, but there are three key innovations I’m proposing here.
First, I have rarely, if ever, seen a single report or dashboard package that tracks both in-depth operating metrics such as average order value, churn, retention, or traffic at the same time as financial metrics such as COGs, gross margin and variable costs. It’s as if most companies are trained to speak two different languages about the same thing. The business units speak one language: the operating lingua franca of customer behavior, pricing decisions, marketing impacts and product design. Then the executives, investors and board members speak a second language grounded in financial terminology designed to provide a one-size-fits-all approach to managing any kind of company. Operating metrics are in disconnected dashboards, driven bottoms-up. Financial metrics are centralized and tops-down.
Despite their obvious overlap, few people speak both languages. Translations are infrequent, maybe a couple times a year at forecast and budget time. In my experience, performance results discussed in finance parlance are structurally disconnected from the daily operating dialogue. Language is important and having your executive and operating leadership teams speaking two different language is a problem. I believe there are massive efficiency and performance gains to be had for your company if your operators and executives speak the same language. Imagine using that single language to make both daily decisions and three-year capital allocation decisions. Integrating operational metrics and financial results into a single model used by all teams, operating and executive, every day, to make decisions is surprisingly, an innovation.
The second surprising innovation is that rarely do operating dashboards commit to forecasts for key metrics. The finance metrics are usually forecast for the current fiscal year. But not the key operating metrics that go into that finance forecast. For example, if you are selling things on a website, you know that your sales are a result of traffic to your website and the customer experience that drives purchase conversion once someone gets there (price, in-stock, etc.).
Do you forecast your weekly traffic? Some do, many don’t. I believe that if a metric is an essential part of your mental model for how the business works, if it is the type of metric you would call a Key Performance indicator or “KPI,” if it is the type of metric that would drive a revenue or variable cost forecast, then it is important enough to not only track but forecast. This is because having a forecast is the best way to learn about your business. See this article on Reporting 101 for a discussion of why variance to forecast is the best way to generate meaning when interpreting results. My rule is that if it’s worth tracking, it’s worth forecasting.
The third surprising innovation is the combination of the previous two: combine and connect operating and financial metrics in the same forecast! If you are not forecasting website traffic, and the Finance department has revenue forecast for that week, what are they basing their revenue forecast on? It must be on something other than traffic, which means they are forecasting revenue that you may be responsible to generate with some different mental model than the one you are using. Maybe it’s on historical data, what did we sell this week last year? Or maybe it’s an annual negotiated number that is just ‘peanut-butter’ spread out over the weeks? Regardless, if you are making decisions to drive traffic to a website and your mental model is ‘traffic * conversion = sales,’ and that is NOT the Finance department’s mental model for forecasting your revenue, then you should be worried.
The Integrated Data Model makes this go away because the finance metric forecasts are driven by the operating metrics. In other words, the design of the Integrated Data Model forces the business unit and the Finance department to align on what the core forecasting methodology is. While it seems obvious, I must be honest that after almost twenty years working in technology startups, Microsoft’s Xbox, Amazon’ Twitch and now Toys R Us Canada, I have rarely seen finance and business units align on a forecasting methodology. Often, Finance does it in isolation and gets approval from the business unit. Or the business unit does it, the Finance department takes it and then applies ‘controller judgement’ and changes it without permission from the business unit. An Integrated Data Model gets everyone speaking the same language, literally on the same page, and reduces organizational anxiety by removing constant negotiations and opaque expectations.
There are four concepts included in the Integrated Data Table: 1) Operating Metrics derived from an IO Mental Model, 2) Financial Metrics, 3) Data Table, and 4) the Forecasting Model. I’m only going to get through the Operating Metrics in this article.
Operating Metrics are the data measures you look at regularly to make decisions. When we talk of “data-driven decision making,” there are usually two types of decision data: 1) decision data that is produced regularly, weekly, daily, and monthly to track progress, and 2) one-off, ad hoc analyses on particular issues. Operating Metrics are the former: the data you look at in an always-on dashboard. Ad hoc data analyses are super valuable, but not part of the Integrated Data Table.
Operating Metrics come from the mental model you have for your business. They are often called “KPIs” or “Key Performance Indicators.” If you’ve ever heard of “OKRs” (Objectives and Key Results), the Key Results are measured by Operating Metrics. Operating Metrics are the things you see in dashboards and reports, like website traffic, conversion rates, AOV (average order value), LTV (lifetime value), and so on. You would never see an Operating Metric on a P&L, income statement or balance sheet, they are almost by definition not financial metrics.
Great Operating Metrics are limited to those that effect outcomes and that the organization can change or influence. (metrics that are static and unchangeable are perhaps better treated as factors in the forecasting model.) Great Operating Metrics should be strategic in nature and are almost never provided in default reports from software packages. My approach for developing great Operating Metrics is by facilitating a dialogue around what I call the “IO Mental Model.”
“IO” is a technology term for “Input/Output,” with a presumed operation in between. For example, imagine you write code that adds values X and Y. The user types in two values, as inputs, one for X and one for Y, say “2” and “3”. The code performs an operation to add them together and prints “5.” “5” is the Output. Yes, “IO” a nerdy tech term, but the underlying concept is universal.
For example, there is an Input and Output sequence for my dog Lucy every day in the late afternoon. When her biological clock tells her brain that its 4:30pm (Input), she comes and puts her paw on my arm indicating its dinner time (Output). Her brain interprets that it’s been X hours since she last ate and that prompts her to take action (an operation). She then triggers another IO sequence: I get the Input of her paw on my arm, which triggers an operation in my brain to get up and make her dinner, which is the Output of Lucy putting her paw on my arm. These are all just predictable cause and effect sequences.
A Mental Model is a theory of causality that you rely on to take action. It’s your understanding of how things work. If you do X, Y will happen. It’s a Mental Model because it’s in your head. For example, therapists will talk about “narratives” or “self-talk.” Philosophers talk about “heuristics.” Business consultants have “frameworks.” Scientists have “hypotheses.” These are all different ways to talk about Mental Models. They are stories we tell ourselves to interpret things we experience and to inform our actions. Lucy has an operative I/O Mental Model for getting me to make her dinner. I suspect you could identify several in your daily routine if you choose to parse your experience in this way.
Making an IO Mental Model starts with writing down what you do and why you do it. You already have one, if not hundreds of causality sequences in your day. But they are likely unexamined or intentionally designed. Like the example above with Lucy, every action we take every day in every second can be broken down and understood as an IO Mental Model. This is also true in the business context. Whatever work you or your team does every day has an operative IO Mental Model already. Our brains and social groups will automatically create IO Mental Models and act on them. It just happens.
Here is an example of my method for facilitating an IO Mental Model. I’m currently doing a version of this for marketing, customer support, and a real estate project. But it works for any mechanisms for producing a desired result. I’ll use my own weight loss as an example.
Step 1: Establish the Ultimate Output
Facilitator Matt: Hey Matt, why are you worried about eating and exercise in the first place?
Matt: I’m not healthy or happy when I’m overweight. My clothes look bad. I’m too tired, and I’m embarrassed about how I look in pictures.
Facilitator Matt: Ok, so goal = lose weight. How do you measure whether you’ve hit your goal or not?
Matt: Um, by how much I weigh?
Facilitator Matt: Makes sense (not so bright this Facilitator Matt). So goal = lose weight as measured by pounds on a scale. Let’s put that in a box on a slide at the far right end and call it the “Ultimate Output.”
Step 2: What needs to be true to reach the Ultimate Goal?
Facilitator Matt: Ok, let’s work backwards from that Ultimate Goal. What needs to be true as a direct condition precedent to losing weight? Think about the things directly to the left of that “Lose Weight” box.
Matt: Well, to lose weight you need to burn more calories than you consume. So I guess there are two factors: calories burned and calories consumed. [Note: voila! We’ve found Matt’s operative mental model]
Facilitator Matt: Perfect, how do you measure calories burned?
Matt: Well, there are estimators, but I use steps via my Fitbit because it’s an easily measured proxy.
Facilitator Matt: Perfect, how do you measure calories consumed?
Matt: I use My Fitness Pal to track calories.
Facilitator Matt: Sweet, this is progress.
Steps 3 — N: Keep going backwards asking “what needs to be true” and “how do you measure it?”
Facilitator Matt: Let’s keep going. What needs to be true to burn calories?
Matt: I need to exercise.
Facilitator Matt: And how do you measure it?
Matt: times per week I get on the elliptical.
Facilitator Matt: How about limiting caloric intake?
Matt: I need to plan ahead and schedule time to cook and track.
Facilitator Matt: And how do you measure it?
Matt: number of days during a week that I had a complete menu planned out ahead of time.
Eventually, after enough discussion and iteration, you will end up with a left-to-right chart that describes what you think needs to happen to produce the result you want. You will have broken down the problem to constituent parts and assign a metric to each. You will know when it’s time to stop when the pre-condition for something is obvious and not specific to your task. For example, turning on the computer is technically a pre-condition to writing this article, but I wouldn’t include “turn on computer” in a mental model about writing. I would include “schedule time to write.”
At the point where you find boxes that represent actions that you can do easily and immediately (and that are not common and obvious) that’s the Ultimate Input and the far-left box on your chart. Your collection of boxes from Ultimate Input (far left) to Ultimate Output (far right) now represents your operative IO Mental Model and are the Operating Metrics for your Integrated Data Table.
Next time, we’ll talk about setting targets for your key Operating Metrics and common ways they intersect with Financial Metrics.
— — — — — — — —
I write about data design, leadership, business management, financial management, Cascadia, amateur film making and operational excellence. Please follow me on Medium, Twitter or LinkedIn.
