Demystifying unit economics: A deep dive into using UE as an effective tool, Part 2
Devising strategies: Food for thought for technical founders
The first instalment in our latest series explored how and why unit economics can be used as a helpful tool to steer a B2B software business today.
Why focus on unit economics now? Because creating a business strategy after analysing your company’s unit economics can help ensure a laser-focus on value creation. This is important, because delivering value creation will be crucial in the coming years as founders look to show a path to both strong growth and profitability.
This piece will dive into some of the core components of a scaling company’s unit economics, highlight key things to consider, and share real-world insights and examples.
So, if you digested the first instalment and answered the question: “Do I really have a scalable product?” with an honest “yes”, then please do read on.
***
To recap: What are the key components of unit economics in software?
The usual way to think about unit economics is by calculating the lifetime value (LTV) of a customer, and dividing this by the cost to acquire this customer (customer acquisition cost or CAC). The lifetime value of a customer means the gross profit your company gets from a certain customer over that customer’s lifetime.
Before we dive into the key elements of this equation, there are important questions to answer upfront. These are:
Have I segmented my customers appropriately? And do I understand the behaviour of each customer segment?
Founders may think that segmenting a customer base properly is only relevant for larger companies. However, in my experience many software startups tend to get started in the mid-market and then gradually evolve both their product and GTM motion to be suitable for Enterprise.
Failing to keep things clear during this transition, or doing so too late, can lead to missing important trends.
I once worked with a startup that was relatively early on in this journey (think sub-$5m of ARR). The startup involved Solution Engineers (SEs) — expensive and overworked people in pretty much every company I’ve encountered — in every sales conversation, whether the pitch was for a $500k enterprise licence or a $20k mid-market deal.
Overall, the company’s unit economics were not terrible. However, because SEs are a scarce resource, the firm’s Enterprise deals were suffering delays. Instead of focusing their expertise on large, lucrative deals, the company was squandering SEs’ time.
The startup only discovered this was happening when it started an exercise aiming to understand the cost to sell at a granular level. Following the discovery, its team re-engineered both the product (by reducing the scope and complexity of the mid-market product, so that it could be sold without SEs in the mix), and its sales process (by putting in place cross-functional Enterprise sales teams). These measures went on to vastly improve both acquisition cost and customer satisfaction.
Next, pose the question: Do I really know what it costs my business to sell a contract?
The amount of money it costs to sell a contract is critical, and the true total is often misunderstood by startups.
Your marketing costs, and the salaries you pay your sales people and BDRs, count towards the total for sure. But ask yourself: Who else in your organisation is spending their time on sales, or on new customer implementations? Is there an engineering team dedicating hours to developing new features aimed at getting Contract X or Contract Y over the line?
It is critical to ask these questions and to answer them honestly, and then to assign a dollar value to every sale input. The total you come up with will not be perfectly accurate, and it will certainly evolve, but even the exercise itself will reveal so much about your business.
Completing the exercise helped one company realise it was vastly underestimating the amount of support customers required to implement a seemingly “seamless” API, for example.
The team was seeing contracts pushed out again and again, because customers lacked Engineering resources. As a patch solution, the company’s engineering resources were diverted to assist implementations (unpaid). After analysing the cost of selling each contract, the business solved the problem by establishing a small revenue-generating Implementation Services team, which saw sales cycles reduced by about 30–40%. Customers were happy, and our company’s unit economics improved tremendously.
… And consider another (critical) subset of the above question: What exactly is upsell / ‘cross sell’ in my company, and what does it cost?
In short, the “easy” way to upsell is through something like Snowflake’s volume-based model. This model sees a company switch on a customer, and then scale revenues as customer consumption increases. This revenue growth generally tends to come with little extra effort, and only some involvement from customer success.
(Another example of a volume-based model is a payments startup whose revenues simply scale with the customer’s volumes).
The reality for many enterprise software startups is quite different, however. Customer success and sales teams often work with a customer to identify the next use case or business unit, then define the requirements, before repeating most of the initial sales process.
There is nothing wrong with this situation, as long as startups recognise these efforts and capture them as a true ‘cost to sell’ by assigning them a dollar value. Merely starting this process will likely do wonders for how you steer your organisation going forward. It might lead you to conclude that a ‘land and expand’ motion is not that suitable for your business, and you should be finding ways to charge your customers more upfront.
Thanks for reading! Please stay tuned for the final instalment in the series, which will address the question: What should I really be charging my customers?
If you want to more helpful insights, or to reach out about your latest scaling startup, please get in touch with me at mina@dawncapital.com.
