5. Calculate Your Value
How much value does my company create for an acquirer?
A key to strategic acquisitions that value is subjective, relating to the use case for a specific acquirer.
A subjective valuation is a mind-bender for most of M&A, which tends to derive value from multiples of revenue or EBITDA and apply those values to every buyer equally.
This doesn’t work for strategic acquisitions because the buyer is not interested in your business’ earning potential as a standalone entity. They are interested what your capability can do within their use case. The good news is, this value can far exceed any industry-standard revenue multiple.
KEY ASSUMPTIONS
1. The value of a use case varies widely between individual acquirers. If Walmart rolls out your fulfillment optimization feature it could bring hundreds of millions in value. If a regional chain rolls it out it might bring far less in value.
2. Your tech can be replicated. Even if an acquirer truly cannot replicate your tech, they are not likely under that same assumption; they assume that their alternative is to hire and build it themselves.
3. Whatever value you calculate likely exceeds the price a buyer will pay. Use the calculation to unhook buyers from the “multiples” conversation, and to rank your attractiveness between buyers. See friction points in the next section for more details on the data points that will suppress your price.
Calculate Your Value (cont’d)
Your value is calculated using the formula:
Direct cost (DC) of building your capability
- Adjustment (A) for an external solution
+ Time (T) to build your capability * Foregone $ (F$) during build
Value = DC - A + (T*F$)
Let’s break down these components.
DC
Direct cost of building your capability is just what the company would have pay to build the capability. Remember, their costs are not the same as yours. Big companies will generally pay their developers more and have more overhead associated with product management, QA etc.
A
Adjustment for an external solution is to factor that code developed internally is easier to understand and maintain than inherited code. A quick adjustment in percentage terms is sufficient, with 10% at the bottom end if you use the same frameworks and quality control as the acquirer, and 40% at the high end if you are using a language they will have to learn or have technical debt.
T
Time to build your capability is how long it would take the acquirer to replicate your capability. As you map your build time to the acquirer’s, don’t forget the iterations you went through to get your solution working. And don’t factor pivots or other directions before you started building the specific capability.
F$
Foregone $ during the build is the big one. This is the opportunity cost of building versus having an acquired solution available much sooner. This is driven by whatever business outcome is part of the buyer’s use case – upsell, internal efficiency, retention, new market.