Building Financial and Planning Models
This is a diatribe on how to project the scaling of a team using models of work allocation and driving product-based financial models’ feedback loops with a dynamic workforce. It works pretty well, to be honest.
It’s easy to spend more time modeling costs than revenue sources: in other words, it’s easier to worry about spending money more than worry about making money. So keep it simple: define an architecture based on categorized spending, categorized allocation, and traceability of costs to revenue first and foremost. That spending has to come from somewhere, so your spending has to accommodate your projected monetary input. IR&D is good, but it by definition doesn’t pay for itself, so it has to have a path to revenue or some other concrete value trade-off that will help you feed your team via investment or grants that will come in before you’re insolvent.
In short, the books have to balance, and to have sound finances, the books have to be traceable to revenue.
Inventing the Universe:
Let’s say I project that I will sell 1095 lemonades in 2021. This yields $2190 of revenue in 2021. Great! That’s my target. That’s obviously not where I started: I started by modeling the universe and putting down all my assumptions, because saying I’ll sell a bunch of lemonade is not going to magically make it happen. Your financial model needs assumptions and levers you can pull on to modulate those assumptions, yielding, eventually, revenue.
For your revenue root function, you start off with the fact that, based on your experience, 150 will walk by your lemonade stand a day, and you expect 1/50 people who walk by to buy your thing (3 sales/day). If it’s a hot day, 100 people might walk by (there’s one side of the pressure felt by your customer), but 1/25 will buy lemonade (4 sales/day). So on a hot day you have fewer customers, but they’re more interested in the thing. On a brisk day, 50 people will walk by and 1/100 will buy lemonade (1 sale/2 days).
The baseline universe we live in is assumed to have 365 days, and the data I gathered is from all over the place, but it may be potentially broken out into discrete customer models. The driving factor for the customer is thirst. The weather affects their thirst, but customer themselves have thresholds and different preferences for how they take in your solution to their problem. This leads us to, with some preamble, the foundation of your model, which is the combination of your assumptions. The core assumptions are bolded, while compound ones which can in aggregate provide you an equivalent assumption are not:
people will walk by my stand and some of them will buy lemonade on average, per one of the following models:
150 people on average will walk by and 1/50 of them will buy lemonade every day, or
with demographics of my customer established, I define binning categories, for which on average:
40% of the population is 20-50 has a 2% baseline probability of buying something,
20% is 50+ and has a 4% chance of buying, and
20% is <20 and has a 1% chance of buying
I will sell 365 days of the year, and each day people will walk by based on:
150 people will walk by on an average day, or
of the 365 days, 165 will be regular days, 100 will be warm, and 100 will be cold.
On hot days, 100 people walk by,
on a regular day, 150 people will walk by, and
on a cold day, 50 people will walk by my roadside stand.
On each day of the year, sales will be affected by the weather as per:
on any regular day, the customer will be thirsty and prone to buy a drink per their statistical mean, or
the above purchase functions will be modulated by weather and thirst such that:
during hot days people will want a drink 100% more,
on regular days people will want a drink per their statistical mean, and
on cold days 50% as many people want a cold lemonade.
I will sell my product, per one of the following assumptions, for:
$2/lemonade, which is my baseline product, or
whatever each thing I sell to each customer is discretely priced at, and each product has a different “preference” coefficient for each customer, e.g. older people might love lemonade, but younger people like things sweeter.
However you define your assumptions and baseline statistics of the universe you exist in, start simple. There’s no reason to account for everything on the onset of your model.
If you want to make it more complex, you write those numbers down, go off to the side, write out your statistical model, then link the outputs of your model to those cells so you are making decisions based on the aggregate your nominal customer profiles’ output in the same place. So easy you can do it in Excel. Down the road I advocate building using programming language for your mathematical model, because since so much changes year-over-year and as a function of everything else, you may eventually end up like me trying to make 4-dimensional tables in excel with your team mad at you because your spreadsheet is too complicated.
Levers, Not Yet
So we have established a steady-state normalized universe. Now you get to do work, because your baseline is actually not $2190 per year. Your baseline is $0 a year. Who cares about your lemonade? This is where revenue models get really messy, because every lever has a cost to shift it, and magic levers without associated traceability are bad news for everyone. You either need holistic understanding of what the lever means and associated assumptions that come along with shifting of the lever, or you make that lever a function of something you spend money to do, i.e. you have the power to achieve without the magic lever doing it for you.
They’re complicated, so we’ll step away from the levers and leave them alone for now. You know what your lever is until you’ve figured out what your lever is? Throw in some ARR growth of 250% by projecting 250% growth in customers every year, or something. Your revenue drives everything you can do, so you’re going to set that up before you do anything else, and come back to it and fix it later. Please do not just leave a blanket 250% yearly increase in customers with no explanation.
Your lever can be any of a number of things. It may be simply “I have a lemonade stand; they will come”, which yields a boolean growth from 0 and then you just passively have the above sales numbers. More broadly, a lever might be a fan that blows on people and makes them feel cooler on a hot day so they’re thankful for you and want to support your business; it may be a heat gun you blow on passersby on hot days to make them so warm and thirsty that on hot days you get 100% of customers; whatever works. We’ll revisit levers later.
Revenue
If you kept it simple above, for your revenue all you have to do is write down the following numbers:
365 <- days in a year
150 <- people who walk by daily
0.02 <- 1/50 people who walk by will get lemonade
$2 <- how much a customer will pay for a lemonade
250% <- your customer growth per year, and essentially your ARR growth because there’s no limit to your sales
A times B times C times D yields $2190. Easy. With that ARR growth of 250% you’re ready for a Series A!
First, establish the deliverable item, or output (done, it’s lemonades, and via inference you can see they are priced at $2/unit). As I stated, how many get delivered is driven by a different lever, and needs to be a function of it, but the path to profit is to have revenue be bigger than cost.
Establishing your revenue keystone is important: that’s the root of your model growing because you’re on a hockey stick pulled along by the levers of your customer and contracts pipeline. Of course, you might do more than one kind of work, and can break it down into both recurring and non-recurring revenue across different revenue buckets, but we’ll get there because those are just numbers and will have to be discretely traced to deliverables and work products/work to be done to make those numbers add up.
Remember that you can categorize things and lump-sum them: this is a simple model. So you have two potential revenue sources, and by inference you make $2/lemonade, and you’re trying to model introducing pomegranate juice to your operation and how it will change things at $4/pomegranate juice.
Expenses
With the starting point of revenue we can establish the costs to make it. The coin of expenditure has two sides: the work, the cost of the work. No, seriously: the work itself encompasses personnel or contract costs established by the workers intrinsically; the cost of the work overlaps a bit, because it has costs associated with being done in the real world, which you might categorize as overhead, but in the end is still work and not an extrinsic cost of doing work. Extrinsic costs are literally materials, facilities, rent, tax (that one is for later).
For the denominator, 2080 hours per year is a baseline you can use, and if it turns out the hours required to do the thing you need yield a >1 number, one person will not be able to do it if you’re going to be honest about labor. But that is about the individual and how they’re broken down into their discrete tasks and priorities.