Sat June 21 2014

The Arrogance and Luxury of Scale

The luxury of scale is a double-edged sword. While scale can bring huge network effects you can leverage for fast user growth of new products, it can also mislead a big company to go after the wrong opportunities and paralyze a small company.

So when developing a new product, make sure you build a compelling first time user experience (FTUE) that does not rely on the benefits of network effects. The FTUE is important to get a push out of the gate, but iteration and designed-in network effects are what will win the game in the long run.

When Big Companies Assume the Luxury of Scale

Big companies that have achieved scale and take scale for granted are many times trapped into slow moving and myopic decisions that optimize on a local maximum.1 This is a topic that’s covered extensively in The Innovator’s Dilemma.

Big company that did this poorly: Google

Google Wave and Google Buzz both failed because they assumed the luxury of scale. They assumed that the large user base of Gmail and Google Search would transfer directly to a social product. Google mysteriously assumed that, just because it was a Google product, people would automatically sign up and use it regularly. It made no effort at integrating with email or any particular effort to ensure engagement other than sticking “Google” in front of the product name.

The FTUE was bad because Google neglected the core user behavior for both of those products: both are inherently controlled private experiences. Yes, Gmail is “social” in the sense that you are emailing other people, but they are private in the sense that the user expects data generated by Gmail to be private.

Big company that did this well: Zynga

Zynga was able to turn effectively a non-scalable game studio business into a massively scalable company with huge network effects and metrics-driven best practices. They understood the core value proposition and the first time user experience to make sure the user is hooked with each new game. Every single time Zynga launches a new game, they know:

  1. Why the game is addicting,
  2. How to optimize the FTUE to convert the user into a paying user, and
  3. How to effectively transfer all of the previous Zynga games’ user bases into new games.

And most importantly, the folks at Zynga understood that you have to design to scale by designing in network effects. If they had designed assuming scale, they would have failed much like Google Buzz and Wave did.

When Small Companies Assume the Luxury of Scale

Small companies that have not achieved scale, yet assume massive distribution without understanding the core value proposition of the product, often end up with a product that has a bad first time user experience (FTUE) and fails to convert users into highly engaged users.

I’m a big believer in the KISS school of design. Test single hypotheses and control for every other variable to isolate a cause-and-effect relationship.

Small company that did this well: Foursquare

Foursquare’s first iteration of their app was solely focused on getting people to check in to a venue. No other bells and whistles in the feature set. They tested that core use case / value proposition and found that it is a hugely viral action that taps into our need to humblebrag (more on this in a separate blog post).

They assumed no scale or network effects. I still remember the key complaint about Foursquare when they first launched — that you need a certain number of friends for the product to be really interesting. I think the threshold number of users that Facebook found that users became engaged users was around 15 friends. So Foursquare used Twitter’s existing scale and pushed a lot of actions to Twitter by default. Also, Foursquare’s badges and mayorships features helped improve the single-player experience.

Small company that did this poorly: Hot Potato v1

In the first version of our Hot Potato app,2 we fell into the trap of assuming scale for the FTUE. As a result, we failed to pinpoint the main reason why a product feature is compelling from the first time the user loads the app. The single-player experience was bad. When users landed inside an event conversation stream, they saw an empty feed the majority of the time. The app worked well for large scale events like WWDC and SXSW, but failed for the long tail of event feeds on the app.

So when developing an app, make sure the FTUE is compelling. Users have limited attention spans. Without a core focus, everything looks like the most important thing to focus on. The edge cases begin to look like the core focus.

Make the product useful for your first users and understand its reliance on network effects before designing for scale.3

If you chase two rabbits, both will escape.

Thanks to Robert Goldberg, Justin Wohlstadter, Keith Nowak, Taylor Davidson, Trevor Owens, Harry DeMott, Sajid Mehmood, and Alex Taub for helping me crystallize my thoughts in this post.


  1. Related to the hill climbing problem in mathematical optimization. Also covered extensively by Eric Ries specifically related to product development here

  2. Hot Potato was an app we built for people to have conversations with like-minded people around live events. 

  3. See my earlier blog post on structuring serendipity in product design here. Maximize structure around your single core behavior and minimize structure around edge cases to maximize serendipity. 

Browse by Category