Zoom and the perfect balance: Product Stories #2
Balance of Zoom between SMB and enterprise market; as well as features that scale vs that don't (part 2 of 2)
Since I wrote the first part of Zoom’s product story (which was last week), there has been a lot of press about Zoom and its lack of security features. Google banned it on employee computers. Here is a list of all the security issues found on Zoom for those interested.
I also came across an interesting tweet regarding the fixes Zoom was making:
To provide more context on the security fixes, one of the fix Zoom did was the fact that new joiners get added to a “waiting room” by default. This was done to prevent Zoombombing - a phenomenon where random ill-intentioned people join your Zoom meeting by trying different permutations of the Zoom call link.
The ability to add your partner very quickly was one of the reasons why Zoom grew so quickly. No friction-full onboarding was required. While this was not the only reason Zoom became so hugely successful, but surely was one of the top few.
As I talked about in my previous mail, Zoom was not built in a “move fast and iterate” model. The feature of quickly adding people was a carefully thought through trade-off. Eric (Zoom’s founder) would have known that he might have to remove this feature someday but still went ahead with it. This is a very fine line on which some founders have difficulty walking. I personally tend to walk more on the “build it, we’ll see what happens” side of the line (which has led to Google banning our app from Playstore a couple of times). Some founders I know are overly cautious while building a risky feature (which has led them to abandon those features all-together). The problem here is that you don’t know where the line is until you have walked miles on it.
This also points to the fact that I highlighted in my previous Reddit story - Sometimes you need to do things that might or might not scale. I did not realize when I started rambling about this aspect of Zoom’s story that it would point to the popular Paul Graham’s quote “Do things that don’t scale”. But sadly, it did.
SMB vs Enterprise
While Zoom did do some things that didn’t scale, a lot of things it did in its initial 2-year “product building phase” did end up scaling. One example of that would be their go-to-market strategy.
While Zoom (like most of their contemporaries) wanted to serve the enterprise market, Eric knew it would be a difficult battle to begin with (especially in a market filled with biggies). As a result, he started with a heavier focus on the freemium model, which is generally meant for SMB customers.
He figured he would start with the SMB market and simultaneously, keep on getting enterprise customers (where the sales cycles were much longer). Note that he never wanted to go to the consumer market as then he would have to rely on advertising as a business model; which according to him doesn't make sense for a video call application. His freemium model (of keeping one-on-one chat completely free and a 40 max cap on group calls) provided him with enough leads to grow sustainably; while he kept going after the enterprise customers. In fact, his first paying customer was an enterprise customer (Stanford Continuing Studies) even though he started with more focus on SMB first.
Zoom also did a bunch of billboards and NBA ads later on when his focus shifted on the enterprise more. Eric believes that brand advertising is expensive but something one needs to do in order to shorten the sales cycle. If your company is something one has never heard of, it is very difficult to convince all the stakeholders involved in an enterprise sales deal.
This is the same strategy Slack followed. Provide a free product that works seamlessly, thereby providing with enough leads to you to build for the SMB market organically while you inorganically try and close enterprise deals. But there are very few problems that hit SMBs and enterprises alike. Zoom as well as Slack were lucky enough to find those.
Talking about early metrics of Zoom might be a moot point because they were so good from the start that it’s practically of no viable learning for others (at least the numbers disclosed publicly).
Metrics actively tracked by Eric during the initial days:
Daily number of meeting participants
Number of minutes
While 2 (or 3) are what can be constituted as North Star Metric, NPS Score is a good check metric to ensure growth doesn’t come at the cost of existing users. NPS score essentially is a measure of how much your existing users like your product.
After couple of years of launching the product, Zoom’s NPS was 68 (30 is the average SaaS NPS score and 40 is a good score). Major video conferencing products were at 20 at that time.
Zoom’s growth has always been fantastic. Probably one of the reasons why Eric does not pay much attention to it. They launched their product via a Wall Street Journal article and got 60k users in 1 day (this is even more than Instagram which got 25k users in a day on its launch).
Cumulative user growth since inception:
0.5 years: 500,000
1 year: 3,000,000
1.5 years: 6,000,000
2 years: 10,000,000
2.5 years: 40,000,000
Their total users grew 40% month on month since their inception. This is a phenomenal feat to achieve.
While there is very little visibility of Zoom’s revenue early on, it has grown from $61m to $331m in annual revenue in the past three years. 11% MoM growth rate in revenue in the last 3 years.
One negative data point we do have is that a few VCs passed on Zoom early on because they felt that it had higher than normal churn. Eric explains that it was because customers were changing their individual plans to company-wide plans but we would never know.
Please do share this article with anyone who you feel might benefit from reading this - any startup founder, Product Manager or in general tech enthusiast.
As I finish this mail, I would like to leave you with this one quote by Eric on Zoom’s growth strategy, which he has talked about at several forums.
If you want to go from San Jose to San Fransisco, you can go at 60 mph and reach there in 1 hour. If you are aggressive, you can also go at 80 mph, and reach there in 1 hour 10 minutes. The difference would be just 10 minutes, but significantly higher risk. I would choose the comparatively slower but less risky approach.