I have shared (similar) versions of this articles are also shared on LinkedIn and Medium
Market size estimations often feel arbitrary and pointless
Estimating a “Market Size” used to feel near pointless to me.
Typically, a "bottom up" and a "top-down analysis" resulted in numbers like “5.2 — 7.4 Billion USD” for whatever the product in question is.
These kind of market size numbers are impossible to manage by, hold accountable for, improve or verify. They are useless numbers.
Market sizing is crucial for decision making
A lot of things are done badly. That’s ok if they are not important. But market sizing is very important. It is the key input for tactical management decisions for example: product investment, marketing goals, sales targets or engineering resource allocation.
On a strategic level, a lot of management theory concerns the choice of markets. For example “new market disruption” theory points to delivering a product to previously underserved market.
Blue Ocean Strategy argues that creating new markets is the best way of escaping bloody competition in the current markets.
Obviously, both these approaches only make sense if the “new blue ocean market” or the “size of the underserved niche” are geared towards markets that are large enough. In other words — without a good market size estimations both theories are nice but pointless.
Sometimes the “market size” is not discussed openly or not an “official” part of the analysis. Make no mistake — whether the market size is an implicit assumptions or an explicit one it does not matter, it is still the key assumption.
The market size will re-appear at the latest when you fail to generate enough leads in that market or loose deals because there is no demand at a certain price/functionality point.
Market sizing done better: “reverse market sizing” based on unit economics
Core insight:
A market size without an assumption on the price of a product is not a market size. There is no market without price.
This is the basic concept of what a market is. The price coordinates supply and demand, which leads to transaction (a.k.a. a product is sold) which makes a market.
Example: Component ordering software for independent car repair shops
Let’s say we are considering to build a business-to-business (b2b) software that allows independent car repair shops to compare parts from different suppliers and order them.
The problem this product solves is the time consuming research for the parts and the anxiety of not getting the right price.
Note: I made this up — now idea if this exists or is not possible for any particular reasons.
Now, what's the market size for this product?
Traditionally, the process would look like the below. Much simplified here to make the point.
Bottom-up analysis:
(number of cars in country) * (repairs per car per year) * (average cost of repair per car) * (cost of spare parts) = Big number 1 / bottom up analysis.
Then, you take a percentage of this value and assume that this is your market size.
Top-down analysis:
Find some statistics of the revenue of car repair shops. Make an assumptions on the margin through spare parts. Make an assumption on what you could gather from this. Big number 2 / top down analysis
Is this useful? Yes, this is probably useful to get the very basic statistics. But, it is certainly not meaningful, verifiable or allows us to set useful goals or evaluate the potential.
Reverse market share: ask a better question
A much more insightful way is to put put together basic unit economics of the product we are considering and reverse the market size question.
The question is not “how big is the market?” but “how big does the market for this product need to be to make the economics work?”
A much better question leads to a much more useful answer as we shall see below.
Let’s take the car part example again and do a reverse market sizing. We assume that we would be building a new product. The process would be similar for a new product.
Step 1: investment cost to build the offering for the chosen market
Do a rough and fast back of the envelope calculation of the costs. Components/ services/cost of developer time to build the offering that targets the chosen market.
Step 2: cost per unit of building, maintaining and selling the product
Cost per unit of making, selling and maintaining the product. One can have a detailed accounting based discussion of what falls into which category, e.g. Cost of Goods Sold vs. Overhead. The point here is make numbers you can use, thus I'd go with common sense. Don't overcomplicate.
Making one unit of product:
For example the cost of components and the internal or external engineering time (= cost) required to build it. Of course this depends on the product - in the case of hardware these might be physical components in the case of software components like AWS fees, mail-chimp email service or chat bot tools like intercom or whatever it is you are using. Per product sold - this is unit economics.
Selling the product:
Cost of acquiring a lead, how much time will you need to call or write personalised emails to your potential customers? Will you have a senior sales person with a roller deck of enterprise CIO's? What's the cost per click and the conversion assumption?
Again, this per product sold so you will need to make a number of assumptions.
Maintaining the product:
In case of software there will be an overlap here with the cost of making one unit since typically the components are on subscription. Account for the cost of customer support and other maintenance type costs here.
Step 3: set the price
As we discussed above, you will need to set a price now. Yes, this probably feels uncomfortable. Yes, this is difficult but without a price you are now building a market size. A market without a price does not exist, unless you are building freeware.
If you have no other starting point (competitor research, customer interviews) I’d take a 200% - 500% of your costs per unit sold (step 2). If this sounds high: remember you are pricing the value of your product, not the costs.
Step 4: Calculate your contribution margin
Easy: revenue per unit - cost per unit
A first version for our parts ordering software market sizing effort might look like the below.
In our example here the contribution margin is 215$ per unit sold, driven mostly be the Cost of Sales as we see from the numbers.
Since our development cost is 250,000$ we need to sell 250,00/215 = 1,163 units for break even. The math obviously very straightforward.
Compare these results to "The market is between 5.2 - 7.3 Billion USD". From my point of view they are dramatically more useful, because the key elements are clearly identified:
Price
Cost
Break even volume
Now we can verify and work on each element: what can product & marketing do to get the price of the product up? What can What can we do on the engineering side do to get the cost down? How can we reach customer cheaply?
Let's say, we identify that we can increase the price by 3.7% (which I am pretty sure you can always do)?
In this example, the effects are dramatic - a 3.7% (100$) increase in price leads to reduction of the break-even market size by 31.7% (794 units)!
Price is just one example of the numbers that become manageable. That's it for now, I leave you with a quote:
Unit economics based market sizing leads to real market size and actionable data.
Always interested in feedback, critique and question on the topic. I am at s.buenau@gmail.com