Scaling Mozilla (Firefox) with John Lilly — Class 5 Notes of Stanford University’s CS183C

Here is an essay version of my class notes from Class 5 of Stanford University’s CS183C — Technology-enabled Blitzscaling — taught by Reid Hoffman, John Lilly, Chris Yeh, and Allen Blue. Errors and omissions are my own. Credit for good stuff is Reid, John, Chris Yeh, and Allen’s entirely.

A big thank you again to Ryan McKinney for helping me to record the last portion of the class. I had to rush to San Francisco for a Greylock event we were hosting*

This class and the next three classes are on the second level of scale — Operational Scale (OS2) — the Tribe level of scale or the stage between 10–100 people. This first class was a deep dive with Allen Blue regarding his experience at LinkedIn and John Lilly on his experience joining and eventually leading Mozilla.

Video from the class, notes are below:

Slides from the class, notes are below:

I. Recap from the last four classes, OS1 level of Scale

What were the themes in common between Sam Altman, Michael Dearing, and Ann Miura-Ko?

• As a small startup you need to move fast
• Make decisions quickly
• Have extreme user focus — build something people care about
• Don’t start a company unless it’s bursting out of you
• Don’t do it alone — much easier with co-founders
• Authenticity of the founding story — why your founding story connects to what you are building
• Strong focus on product market fit
• You can ignore a lot of things in the early stage

What were the divergent themes between Sam Altman, Michael Dearing, and Ann Miura-Ko?

• Diversity and how much diversity matters. It’s a controversial topic and no one has the answer.
• Building a proprietary technical advantage (Ann) vs. just building something people want. (Sam)
• What the optimum early financing structure should look like — SAFE notes (Sam) vs. equity. (Michael)
• Decision making in an early stage startup — autocratic (Sam/Ann) vs. market-based decision making. (Michael)

II. OS2 — The Tribe

This stage — OS2 — is where you go from a great idea and early prototype — to building out a full company and product line for extremely broad growth.

Everything which you think you know about product market fit and your operational plan (from the previous stage)— is going to change.

Other people are going to know about you, and find your market space interesting to move into. The goal is how you get to market share before your competitors get to market share by moving quickly.

The way you scale up is by becoming a tribe — having more resources, a bigger team, new functions, interacting with customers on a deeper level. This period of growth is a race to scale and creating advanced features that unlock market share.

III. Example with LinkedIn

In the first stage, all companies make a bet in the beginning — which if it works out will give a structural advantage (Proprietary Power).

For LinkedIn it was the bet that building a huge professional social network would allow them to build a huge search business. For them, the end value was search (being able to search through people) — the growth of LinkedIn was in order to build the search space in order to get the business.

Other types of companies have different value levers. For example pure social apps such as Whatsapp — the value is having more people on the network for other people to talk to. Enterprise applications would have a different set of value levers.

For LinkedIn, they learned the eventual “product market fit” was allowing recruiters to search through their social network of professionals. Recruiters loved the concept, but in the beginning, when they went in to search for people — the search space was too small. Product market fit was there but only with the people who could envision the full network built out.

The strategy was not sell the product before they we ready but rather get to user growth scale. For LinkedIn the most important part was building the social graph before selling the product (searching across the social graph). Other competitors tried to sell their products sooner than LinkedIn but all failed because they were not at scale yet.

In short, as best said by John Lilly — Make sure you get the product right — before you focus on growth. It’s easy to burn a lot of money if your product isn’t right.

IV. Becoming a Tribe

One of the biggest tactical differences between the OS1 and OS2 is building out of your team. Put simply, the team can be broken up into two broad categories:

1. Team One — Focuses on engineering, product, design, growth, etc.
2. Team Two — Focuses on defending and supporting team one — office space, legal, PR, customer service, sales, operations, HR, recruiting, etc.

Team two starts to build out the organization of the company and is needed to support the scale of the product and users.

V. The Mozilla Founding Story

Next we moved onto the story of John Lilly — how he joined Mozilla and how he helped scale the organization. First, some context:

In 2000, Microsoft had 97% market share of its operating system in computers and, at its peak in 2004, Internet Explorer reached 95% market share of web browsers.

Microsoft had previously killed Netscape, killed AOL, and was the dominant platform for the internet. The Microsoft team declared victory on the internet and had believed they won the browser war. In fact, Microsoft moved most of the Internet Explorer team off the browser and onto the Silverlight product (a whole other story).

During this period, Mozilla was not a competitive threat and was not even on the competitive radar of anyone. Mozilla actually started back in 1998 as an open sourced project inside of Netscape — one of the leading commercial browsers at the time.

Netscape’s GM, Bob Lisbonne, was worried that Netscape wouldn’t be able to keep up with Internet Explorer. Microsoft literally had 10x the people working on IE vs. Netscape and they would never be able to keep up.

Since there was no way to compete symmetrically with Internet Explore — the strategy was to compete asymmetrically and do something drastically different. The war analogy would be, instead of fighting the British in head on formations, they were fighting guerrilla warfare instead.

This led Bob t0 let Mitchell Baker and Brendan Eich run with things to start Mozilla. Initially the team built an open sourced project which included a browser, html editor, email client, etc (the Mozilla Suite). In 2004, the team paired back all of the features into a single fast browser named it — Firefox 1.0. This was one one of the first new browsers in a long time.

VI. The Mozilla Product and Launch

The key features of the Firefox 1.0 product were popup blocking, tabbed browsing, and security. Given that Internet Explorer had no more product development going on (because they “won” the browser war) — there were many security flaws in Internet Explorer.

This became a big catalyst for the initial adoption of Mozilla. For example the US Cert advised normal users to install an alternate browser to IE.

The way Firefox launched was also fairly unique. They created the first ever “Kickstarter like campaign” of its kind back in 2004. The way they did this was:

• They took out an advertisement in the New York Times.
• They gave people the ability to pay $10, and in return their name would be listed on the ad in the New York Times.

As a result, they raised twice the amount they were hoping to raise — everyone who was in the NYT showed the ad to their friends, and they had a lot of press written about “what Mozilla did to get attention.”

Firefox was downloaded 10,000,000 times in 30 days.

The core insight the team learned through this process was — Mozilla was the community.

The key was to let people see themselves in the community, and let them help. People felt ownership for helping Mozilla succeed, and people wanted to help. Mozilla really became much more than a product — it was a movement — and much of their early marketing tactics stemmed from political campaigns.

Community was everything.

Firefox had 100's of people regularly contributing code, 1,000's of people testing new releases, people localizing Firefox in their own language, and millions of people took ownership of Firefox by spreading Firefox.

The other big innovation within the Mozilla browser was search. At the time most people just used the top bar to write in the URL of a website. Mozilla was designed for search to be a first class feature to find things on the web.

Mozilla built search directly into the browser, and worked out a deal with Google to include them as the default browser. Mozilla was the first browser to do this.

Question from the audience — Security is an amorphous thing, how did you get people to care about security?

The press did it for us. Technology writers would do deep dive reviews of various browsers and show Firefox as more secure than Internet Explorer. It’s much easier for other people to talk about how secure your product is vs. telling that story yourself.

Some of our other speakers said not to spend money on PR — but Mozilla was not like that. We had a strong emphasis on community — directly to our audience — it was an effective way to get people to spread our message.

VII. The “VP of Business Development and Operations”

John Lilly joined Mozilla in 2005. He originally visited Mozilla 3 months after the launch of Firefox 1.0 while he was in between companies. His initial observation was the whole team looked very tired every time he saw them (a key indicator of product market fit).

During their first meeting, the team shared all of the problems they were facing at that time and John took all of these problems and created a powerpoint presentation on what he thought they should do. After — he heard nothing back from the team.

After thinking that sending a Powerpoint to an open sourced team (fighting Microsoft) was a bad idea — John Lilly went back in with the team and had another great session. Afterwards however, he wrote a long email — not a powerpoint — on all the things he would do. Again, afterwards— he heard nothing back from the team.

John thought to himself — did they not care about his suggestions? Did they not like him? Given he was then unemployed, he felt self conscious at the time. He thought to himself, if they aren’t going to answer my emails — I’m just going to show up and start helping with their problems. He didn’t want to join a non-profit (which Mozilla is) but he wanted to help.

The first official company meeting John Lilly took part in was a meeting with Jerry Yang — the founder of Yahoo. As soon as Jerry got into the room he started yelling at the Mozilla team and was very angry. He was angry because Google was built as the default search engine choice for the Firefox browser. In 2005, Yahoo was in a huge battle with Google and Firefox was helping to accelerate Google’s traction.

John Lilly thought that if Firefox could get someone like Jerry Yang so angry — there must be something here. Afterwards he joined the company with the title “VP of Business Development and Operations” (we’ll come back to this) and in addition, Reid Hoffman and Joi Ito joined Mozilla’s board along with him.

VIII. The Key Decisions for Mozilla During OS2

Here are the key decisions the team decided right as they moved into the next level of scale — OS2

1. Hiring was key

Their culture as a company was to pay people well — but to never win on salary. Their main competitors for talent were Google and Facebook — if someone said Google was offering them $10K more then Mozilla would say to go with them instead.

Mozilla was looking for people who wanted to work with them together for the mission of opening up the web. Mozilla was able to bring on some incredibly talented people — all of which were wired to be mission oriented vs. compensation oriented.

Question from the audience — Do you advise companies to do this today?

My advice is to figure out what you care most about as a company — then optimize for that. It’s better to decide on your own internal core principles first and different companies can have different cultures.

2. Distributed organization

One of Mozilla’s early principles was the team was not going to be all local — they were going to build a distributed organization and have an open sourced project with people from all over the world contributing.

Much of what they did early on was to find the best people in the world who were already contributing in significant ways to Mozilla — bringing those people in and building a team around them. Mozilla ended up with offices in New Zealand, Berlin, Toyko, Paris, etc.

Personally John Lilly doesn’t love distributed companies — they can be a huge pain — but they used this to their advantage for Mozilla.

3. Community as Insiders

Mozilla allowed their community members to talk to press, have official business cards, speak on their behalf, etc. They needed to do things that Microsoft would never do to be able to compete with them. Microsoft saw this weird distributed community and didn’t know how to compete until it was too late.

Question from the audience — Given the community was so geographically diverse how did it not get chaotic?

It was crazy chaotic all of the time. We had so many people moving in so many directions — to people who worked in normal companies — they had no idea what was going on.

However this was our unique superpower and we fed on this ability. In terms of language, our whole team spoke English so working together wasn’t an issue.

Another thing we did which was unique at the time was — we had a travel policy in which any team who wanted to get together — we would pay for them to meet in person in any location. The policy was I would yell at people if their teams spent too much money — however I never once had to yell at anyone.

4. Ignore the enterprise

Large fortune 500 company would adopt Firefox if we only had these X features — we faced this question constantly.

Our stance was we built what humans wanted, not enterprise, and completely ignored all of the enterprise feature requests. The hope was people within companies would adopt us, despite not having all of these extra features.

5. Mission is the top goal

Our mission at Mozilla was not pure market share — it was making the web more participatory.

IX. Goal Setting in OS2

At this point Firefox had clear product market fit — and started to take over a significant portion of the browser marketshare — 12% vs. Internet explorer at 83%. (Remember Microsoft thought they had “won the internet already”)

These next few slides are taken directly from Mozilla’s presentation to their board of directors at the time. It’s a good way to look into the actual issues they were facing at the time and how they were thinking about them.

Team scaling was still an issue and they continued to build out more of “Team Two” to support the organization.

Goal setting is a difficult problem in a rapidly scaling company. The big question is what is a good goal to set?

For Mozilla, was 20% market share a good goal? Was that reasonable? One thing John Lilly found during this time was the team had to be iterative on setting goals. Their first goals to set for themselves were way off but they eventually got better at setting goals over time.

The purpose of goals is to set organizational goals in which you can hit over time to help the team know you are making progress and start to deliver consistent results over time.

Question from the audience — What was the message to your team when you didn’t know what your goals were? How did you explain that?

Over time we got better with goal setting. In addition we had a weekly all hands meeting with the team and every quarter we would talk about goals — what we hit and what we didn’t.

My take on this is if we hit 71% of our goals we had a good quarter. If we only hit 66% of our goal, it was bad goal to begin with. We needed enough of a stretch goal to go after and always had to make some progress towards it. However if the team hits the goals 100% of the time — this isn’t a good thing because we weren’t stretching ourselves enough.

In terms of handling this with the team we were very open and transparent about our goals, the actual board deck, and our reasoning behind why we were doing things.

One more thing about goals with Mozilla is we found market share to be a lagging indicator of success. Market share could continue to go up even when the fundamentals aren’t great. It was clear Mozilla was winning and we were the first open sourced organization to achieve something at this level of scale.

X. Metrics and Competition

A few interesting things to note on metrics:

• At this time Mozilla didn’t have good metrics on US growth (was something you could ignore pre-product market fit) — they hired their first analytics person after this.
• This happens with all products but it gets much harder to acquire users once you reach the next levels of scale. Much easier to go from 0 to 1M than 1M to 10M. What worked at the previous level won’t sustain you the whole way through.

Competition also starts to get weird once you start to get to scale:

• People who were once your friends, now sometimes become your frenemies. To use the Facebook analogy, things get complicated.
• Google was a huge ally for Mozilla and helped them create their economic engine to get to original scale.
• At the same time Google realized the Browser was critical and was not in their control — whoever controlled the end touchpoint to the user would win.

Google now put Mozilla directly within their crosshairs by building a product to own the end user experience on the web (this eventually became Chrome).

They key decisions they made after this board presentation was to:

• Stay the course and keep building their own product on top of their own platform.
• Keep growing internationally into areas other competitors could not compete with them in.
• Feed the core advantage of the Mozilla community.

XI. Organizational Pains

During the next Mozilla all hands meeting John Lilly expressed to the team that what used to be a small organization of a handful of people has not turned into this huge org chart behemoth.

• 2 years ago they were at 15 people.
• Now they were much bigger as a company and much more complicated.
• Everyone used to be able to sit in a room together and see what was going on but now with all these people they had processes, divisions, managers, etc.
• People also started to feel disconnected from the mission at this size.

This sounds very similar to the pains Daniel McCallum expressed back in class #3.

Firefox launched the next release of their product in 2008, did a campaign to achieve the “Guinness Book of World Records” for the most downloads in a single day — achieved it with 20M downloads in one day, and launched in 70 languages vs. Internet Explorer which only had 5 languages.

Because the web was significantly bigger in 2000 than in the 1990's, Mozilla had more users at scale than Netscape ever had. Here is the importance for building on top of a growing market.

The next big challenges for Mozilla looking forward (at the time) were:

1. Chrome — Google had decided to take control of their own fate and built their own browser
2. Farmville (seriously) — Mozilla made the mistake to allow anyone to build extensions which could do anything to the browser. Bad extensions and flash caused huge performance issues but the problem is they couldn’t test them because each environment was unique — because of the extensions.
3. Rise of Mobile — Firefox is still struggling with this today.

Question from audience — Looking back it’s often easy to connect the dots , what were the most surprising things at the time?

• They didn’t know if they were winning with Firefox for a long time.
• We were moving so fast the wheels always felt like they were falling off and they were also issues that needed to be fixed.
• The other thing is people really cared about Firefox — John could go anywhere around the world and passionate users wanted to talk to him about the open web. He felt very humbled that they had such a strong community.

Question from audience — How much did being a nonprofit contribute to the success of Firefox?

John had a hard time with this question because it’s extremely difficult to build anything which 450M users used. Many people attribute this to being a nonprofit but he never felt like it benefited them. In many cases it would have been easier to be a for-profit company but this was already set in place before he joined.

Question from audience / Allen Blue — What wasMozilla’s growth hypothesis?

The big bet Mozilla placed early on was the bet on the community. They bet was if we built things for the community to adopt and spread, that they would spread it.

Many of our power users were customer support people who were helping to support their friends and family with their computer needs. These community members wanted Mom and Dad to use Firefox and not IE.

Allen Blue: Lets talk about a few specific lessons we can take away from Mozilla and LinkedIn during the OS2 stage.

Find the specific set of people who really love your product, and help them spread your product.

For LinkedIn their was a clear set of users who really loved LinkedIn — they loved to meet new people and add new connections. These were their primary drivers of new growth for LinkedIn.

The people who find your product nice or not valuable — these people wont help you grow your product. You have to find the core set of users who really needs and wants your product.

For enterprise software products, the goal is a little different. The goal isn’t to grow broadly but rather grow within the set of decision makers which your product is catering to.

LinkedIn had a recruiter product and their growth hypothesis for this product was to beta test it with one recruiter within a company, and if they loved it they would spread it to the other recruiters within their company.

Resourcing

During the OS2 phase, this is the first time a company will have a recruiting system in place.

For Mozilla they had a very specific metric for each new person they brought on. The question for them was with each marginal hire — do we get more community leverage or less community leverage from that hire.

They talked about this a lot internally and even for roles such as executive assistants, they had to figure out how they could benefit and add leverage to their existing community.

*Time ran out but I will try to post the rest of the slides here once they are released. I’ll also post the next class notes here once I am finished with them.