Blitzscaling pt. 1

Blitzscaling by Reid Hoffman introduces the term “blitzscaling” – a strategy for growing businesses insanely quick in those circumstances when it’s either do or die.

Here’s my notes on what it is, why do it and when to apply it. Quotes from the book are marked as, well, quotes.

See also my notes pt. 2 for how to work in, hire, manage and lead a business that is growing.

Summary

Blitzscaling = splurging money to grow rapidly. It really only makes sense when there’s a huge first mover advantage.

The only time that it makes sense to blitzscale is when you have deterermined that speed into the market is the critical strategy to achieve massive outcomes.

You need operational scalability to prevent collapsing under your own weight as you grow. Employees, culture and systems are in danger of breaking under the pressure – make sure they don’t.

Operational scalability is one of the primary growth limiters that scale-ups need to address.

Get timing right. Scaling too early or too late can be the end of you.

If your product/market fit isn’t right, or your business model doesn’t work yet, or if the market conditions aren’t right for hypergrowth, then premature blitzscaling can lead oh so painfully (and rapidly!) to “blitzfailing”.

Terminology

First mover advantage

A descriptive term: By being first, you have an advantage. In this book it’s super relevant, as it never makes sense to Blitzscale without it [citation needed].

Example: Being the first company to obtain a fleet of self-driving cars would have a period when they can have insane margins on taxi services. That’s not true if you’re the second company.

Network effect

A product has a network effect when the value of the product increases as the number of users increases.

Example: If an imaginary company “Basehook” created a Facebook clone: an exact copy (without risking legal infringement), they would probably crash and burn. Their product is terrible in comparison, because you won’t have anything in your news feed, no events to attend and no friends to talk to: they have no users.

“Efficiency”

Blitzscaling is a strategy for driving extreme growth, prioritizing speed over efficiency in an environment of uncertainty.

Efficiency in this book is about value per monetary input. One example he mentions would be to pay construction workers to work around the clock, to finish a work-site in 3 months instead of 6, implicitly paying them a lot more money to do the same thing. It’s not about efficency per employee hour, but efficiency per dollar.

I found the way the term a bit confusing, so I think of “sacrifice efficiency” as “splurging money”.

Classic start up growth

Classic start up growth prioritizes efficiency in the face of uncertainty.

Rephrased: Start ups don’t splurge money, they find users to learn from and verify hypothesis.

When starting a new company, I don’t really know anything. Who should I target? What problem do they need to solve? Is there money in it? Is our solution too much / confusing / too little?

Summarizing Eric Ries’ Lean Startup: Get my product out there, and test it on users. Make a MVP, and only add features than I need. Experiment and measure. There’s no shaming in turning/pivoting. I’m probably wrong with some of me attempts, so I won’t take it personally or feel defeated when I find out that I am. Instead realize that I’ve just learned something new that’ll help me come closer to a good product/market fit.

The classic start up will not spend large amount of money on an uncertain bet, but rather cut the budget in half and spend the initial months or years finding the perfect fit, before really betting on it. This is efficient use of money -> less $ spent to find the product that’ll be suitable for a 90% margin.

Classic scale-up growth

Classic scale-up growth focuses on growing efficiently once certainty is achieved about the environment.

Rephrased: When a start up has learned enough (“found a good market fit”), they scale with focus on efficiency – improving unit economics.

This is step 2 after finding the product I feel certain about. Get it out, grow and maximize efficiency, i.e. “Get more users, but also splurge less money”. I already know what I’m making, so let’s find better, more efficient ways of making that product. Reduce support by adding a FAQ, serving up a Support Chat bot. Get lower supplier costs with new procurement deals. Measure marketing effectiveness to lower customer acquisiton cost.

This is how classic scale-up focuses on efficiency to increase profitabilty.

Fastscaling

Fastscaling means I’m willing to sacrifice efficiency for increased growth rate.

Rephrased: When a start up has learned enough (“found a good market fit”), they can scale inefficiency, but calculated.

An alternative step 2 is to focus on growth over efficiency, i.e. “splurge money to get users quickly”. Opposed to blitzscaling, fastscaling already has some certainty about the market. This could be e.g. Facebook having 100 million users, have found its product, got good profitability, and want to get 1 billion users by splurging money because they think it’ll be worth it in the long run.

Blitzscaling

Blitzscaling means that you’re willing to sacrifice efficiency for speed, without waiting for certainty.

Rephrased: When it is paramount to become large quick, you can solely focus on getting users, and find out exactly what your product will be as you go along, and make it profitable later. Splurging money to quickly become large.

I like the AirBnB example to explain blitzscaling: AirBnB is in a new type of business with a large first mover advantage: If Wimdu (the former “european AirBnB”) had saturated the market, home owners incentives to sign up for AirBnB would’ve plummeted. For AirBnB to succeed like it did, it needed greased lightning speed and a bunch of luck. It needed luck because maybe this wasn’t going to be a market of any notable size – maybe people would just prefer hotels. And it needed speed to fill the market before the competitor.

AirBnB needed a strategy that couldn’t wait for them to identify the perfect product, or to optimize the number of employees needed pr customer. It needed to splurge money to get users quickly, even before they earned any money pr customer or knew if that even was something they could count on in the future.

Blitzscaling is what AirBnB needed, and did: Splurged money, got extreme amount of users in a short amount of time, and only had time to extinguish the most intensive fires.

When and why to blitzscale

Prerequisites: Growth factors

While some of these factors could be built into the product as one grows, it’s definitely worthwhile thinking about them before deciding on what the product should be.

Market size

Blitzscaling does not make much sense in small markets, since there’s a roof to reach quickly. That’s probably why Norwegian lawyers still use 20 year old, inefficient technology products: laws only apply in this small country, and there’s too few that are interested in settling bankruptcy issues with high-end tech to justify a large investment (or any mentionable scaling) in developing a good product for it.

To blitzscale, you’ll need a large enough market.

Distribution

To blitzscale, you should find a way to spread organically, preferrably exponantionally. Below are three examples on how that has been done previously.

• People using LinkedIn to link resumes to others, led people in to their website. (On this: allowing users to download a nice resume PDF could’ve been a costly mistake.)

• Dropbox spread through simplifying sending larger file than mail could handle: The recipient of a file had to sign up to get the file. (On this: Having the link automatically download the file without opening the website first would’ve been a mistake.)

• One of Paypals vehical for distribution was settling purchases on eBay. This is an example of leveraging an existing network (eBay), to grow quickly. (On this: allowing users to send money without signing up, or sending money directly to a bank account would’ve been bad.)

Network effects

Hoffman splits networking effects it into five different categories. If the company has none of these, maybe there’s not enough of a first-mover advantage to justify blitzscaling.

• Direct network effect: E.g. Facebook. Each user directly increases the value for others.

• Indirect network effects: E.g. iPhone -> App Store. Each iPhone makes the App Store more valuable for app developers.

• Two-Sided network effects: E.g. Uber. Each driver makes Uber more valueable for paying customers and visa versa.

• Local network effects: E.g. “family packages” for mobile subscriptions. If you get all family members to use the subscription, you get free calls to each other. Each user increases the value of the product for some other users.

• Compatibility and standards: E.g. Phillips Hue hub encourages the purchase of Phillips Hue bulbs. Each existing product following the standard increases the value of your product.

Gross margins

Blitzscaling is more applicable in software than most other areas, because the cost of duplicating software is essentially zero: gross margins are high. High margins allow you to market furiously.

When to blitzscale

… you need to have a big new opportunity - one where the market size and gross margins intersect to create enormous potention value, and there isn’t an existing dominant market leader.

Facebook is investing 4 billion dollars to be able to earn sell a 11$ dollar product (your eyeballs) at a 1$ expense (dealing with angry complaints). These numbers are completely fake, but the point stands: They’re hugely profitable because they’re huge, but it requires a massive user base to get there.

If that’s the case for your opportunity as well, sounds like blitzscaling might be worth considering.

The most frequent offensive reason for blitzscaling is to achieve a critical mass that confers a lasting competitive advantage. […] If you can’t identify any network effects or customer lock-in, scaling might not confer sufficient advantage to warrant blitzscaling.

If Facebook had to have open APIs, so the fictional company “Haselook” could show all events, message anyone on Facebook, show posts from and also post to Facebook, then there’s not really a benefit of being on Facebook over Haselook. If so, then there’s no point for Facebook to Blitzscale, because they wouldn’t have gained a lasting advantage over Haselook.

If there’s no benefit for you to be first, then blitzscaling is probably not your strategy.

The most common reason for blitzscaling is the threat of competition.

If you got competition, which would crush you if they became big, you should probably focusing on getting big before them.

Blitzscaling is by definition inefficient use of reasources, and it only makes sense when speed and momentum are important.

Blitzscaling is splurging money to become large fast. If there’s not a large benefit of becoming large fast, you’ve just splurged money.

How to blitzscale

Innovate

Find a ways to scale quicker, or making the payoff of doing so larger.

Find a way to create a network effect for your product.

For successful blitzscaling, the competitive advantage comes from the growth factors such as network effects, where the first company to achieve critical scale triggers a feedback loop that allows it to dominate a winner-take-all market.

Find a way to completely change the game once you’re big.

Ubers significant investments in autonomous vehicle technology could elimite its biggest expense (driver payment) in one fell swoop.

Hoffman categorizes this as a “strategy innovation”. In other words, it can make sense to get huge fast on bad economics, if there is a chance that a radical shift in technology can put the company in an incredibly profitable situation later.

Find ways to sacrifice things for speed, while staying afloat.

…embrance counterintuitive rules like hiring “good enough” people, launching flawed and imperfect products, letting fires burn and ignore angry customers.

This goes under the subchapter “Technique #3: Management innovation”. And it’s maybe one of the things that I feel is the worst about working in a scaling company. These rules might make sense, but I have troubles accepting that since they hurt so much :(

Underlying principles

Principles that power innovation include

• Moores law: Computing power increases exponentionally. What is too costly today (e.g. low price products on top of costly GPT-3) will be sensible in a few years.

• Automation: Computers are faster and cheaper than humans. Outsource to computers what you can. One example is the automated Google Ad marketplace. If ad bidding was manual labour, it wouldn’t have worked nearly as well (if at all). If targeted ads weren’t automatic, it would’ve been to pricy.

• Adaptation, not optimization: People, markets and needs change. Optimize for agility and learning, so you can meet future requirements. (Modularity comes into mind here.)

• Contrarian principle: “What truth do few people agree with you on?” If you can find something true and important that few other realize, you can get ahead on that.

Proven patterns

A short summary of patterns that seem to play well with rapid scaling.

• Bits > Atoms: Scaling digital products is so much easier than physical things.

• Platforms: A platform often have network effects based on who’s on the platform. Making your product into a platform can give you a first-mover advantage.

• Marketplaces: A platform where people can both sell and buy goods create magic value for everyone involved (in addition to having strong network effects).

• Freemium: Give away a free version, or at least a free trial. It’s so much easier to get customers on board when you can say: just try it!

• SaaS: Software as a Service is super scalable, with low upfront costs for the company, low commitment for the user, works well with freemium. As opposed to selling software installed on-site, it has far lower support and maintainence costs.

• Feeds: endless, scrollable content with random value for the user. While the book doesn’t say this, this is a mind-trick to steal eyeball-time that I personally dislike. But it works: User engagement time goes up!

Get operational scalability

Operational scalability is one of the primary growth limiters that scale-ups need to address. When a business can grow revenues faster than the number of employees without collapsing under it’s own growth, they can achieve greater profitability and keep growing with less constraints.

I believe this so whole heartedly. I also think that improving this over time makes for a great culture and job satisfaction, since employees feel constant empowerment over always being able to do more.

Operation scalability is the ability to grow 1000-fold without being crushed under the weight of increased operational load. Customer growth could make some workflows unfeasable (human scalability), or systems could burn under the increased load (infrastructure scalability).

On human scalability

Founder Brian Chesky [of AirBnB] describes this strategy succinctly: “Do everything by hand until it’s too painful, then automate it.”

I like AirBnB a lot after reading this book. This quote is great, as it includes thoughts on both experimentation, learning, lean and scalability.

“Do everything by hand…”:

Quite often, we can have an idea about what we need or the customer wants that is not right. Doing things by hand lets me internalize the need for it, learn the circumstances where it’s performed, and consider alternative ways of solving it.

“…until it’s too painful…”:

By waiting until it’s painful, you’ve confirmed that it’s needed and important. If it wasn’t necessary, you would’ve found a way to not do it before it became painful. At this point, you know the problem so well that the solution you have in mind is likely much better than initially. In addition, you have strong personal motivation to fix it; motivation is key to efficiency and job satisfaction – you’ve tricked your brain to be excited.

“…then automate it”:

You didn’t build it before you really needed it, and you’re building it after having learned everything about it. The solution is better, and you only fix what you need to fix – you’re staying lean!

On infrastructure scalability

AWS reflects one of the ways that Amazon has made operational scalability a competative advantage: the power of modularity.

AWS is famous for modularizing products into smaller parts with independent teams which have to live up to a contract/API, measured on metrics, but not how they meet them.

Making smaller independent modules of a product avoid the scaling problem of one part to require changes in 3 other parts (which might have other scaling challenges of their own).

Practically in my line of work, infrastructure scalability could include:

• Writing code in independant modules/libraries, so they can later be turned into an API, scaled or replaced independantly.

• Avoiding owning hardware and use e.g. AWS/Heroku++ instead, so scaling resources is a flip of a switch.

• Go towards autoscaling instances or serverless services, so available resources is ~infinite.

• Outsourcing parts of the system, e.g. Auth0 for authentication, to minimize maintainence and scaling.

• Use caching well, to widen the bottlenecks (I’d guess database).

Preparing for future scaling

If you see that there’s a chance you’ll have to scale quickly in the not-distant future, I would personally prioritize (These are great things to do on any day, though):

• Identify what we could potentially do to improve distribution, increase organic growth or add network effects to our product.

• Set up automatic metric gathering. What’s the customer acquisition cost for different marketing methods. What’s the traffic and health of our systems? Load-related problems are notoriously hard to debug without an overview over system health.

• How do we spend employee time per new customer? Can we increase operational efficiency with self-service features, or reduce support requests?

• Which systems would break under a 100x load that we can not easily patch or fix? Can we move business critical systems to serverless functions?

• Which third party businesses do we depend on? Would they be able to handle 1000x load? Can we introduce backup systems?

• Set up infrastructure for (A/B)-testing, so you’re prepared to iterate quickly.

Delicious nuggets

Instagram, when acquired by Facebook for $1 billion, it had over one hundred million users but just thirteen employees and no significant revenues.

That’s insane, I love it. Small companies making large impacts are my favorite kind of companies.

As Facebook grew, Mark changed the philosophy to “Move fast and break things with stable infrastructure”

I like this one personally, because I’ve heard the initial motto of “Move fast and break things” touted too often as an excuse to “just get it out”.

There’s a balance there: the cost of breaking things is often not being able to move fast (anymore). I feel much better with “Move fast and break things” if we have a stable infrastructure with the ability to debug errors, roll back and with automated QA/testing.