Recommended
More Related Content
Similar to Disruptive Innovation at Cloudflare
Similar to Disruptive Innovation at Cloudflare (20)
Recently uploaded
Recently uploaded (20)
Disruptive Innovation at Cloudflare
- 1. Disruptive Innovation at Cloudflare Zack Bloom
- 2. plus Sales, Customer Success, Support, etc... Product Engineering Product Strategy Product Engineering I work here!
- 3. Product and Engineering grow our core business and revenue Product Strategy builds new things which … disrupt our existing businesses … target new markets … create the ‘next acts’ of the company
- 5. - Weekly marketing, pricing, packaging, trust and safety, infosec, customer support, sales, senior leadership meetings - Detailed specs before engineering begins - Large team with dozens of engineers, to match the importance of the feature How to run a disruptive project FAILURE
- 6. - Weekly marketing, pricing, packaging, trust and safety, infosec, customer support, sales, senior leadership meetings: no time left to build - Detailed specs before engineering begins: … the wrong thing - Large team with dozens of engineers, to match the importance of the feature: … that will never ship
- 10. Case Study: Workers - Serverless Compute Platform - The first platform to not use VMs or Containers - 3x More Compute per $ than competitors - 3x Less Memory - 100x Lower Cold-Start Time - Running in 154 Data Centers around the world Workers Everything Else
- 11. Case Study: Workers - Built by 3 engineers and one PM - … who wrote specs only as they experimented and built - … built prototypes before they shipped - … with guard rails and advocates, but not visibility in the company - … very few meetings and distractions - … permission to disrupt portions of business if it aligned us with vision - … involvement from marketing, legal, etc. just leading up to release
- 12. - Small teams of 0.5-1 PMs and 2-5 engineers - We use more people to build more, not fill seats - Launched 14 products in 14 days last month - Ongoing projects include: - Storage: Build applications on the fabric of the Internet - Access: Turn off your VPN - Stream: Integrated video encoding and delivery - Registrar: Disrupting a predatory industry - Argo Tunnel: The best way to connect a server to the Internet - 1.1.1.1: The world’s fastest DNS resolver - Startups are about finding the red line of what we are capable of and riding it. - Executive sponsorship who want us to do audacious things. How We Work
- 14. What We Build
- 15. We build things which make the Internet better for the people who use it We operate ethically, don’t sell data, don’t trick customers We only charge for what costs us money If it’s a commodity, we commoditize it We don’t want feature-by-feature competition, we want to only do what we can do best We only want to enter markets where we deliver unique and defensible value
- 16. Trust: Reputation for security and technical expertise - When we launch 1.1.1.1, people trust it will protect their privacy. - When we launch a Registrar, people believe we will keep their domains safe
- 17. Network: 154 Data Centers near every Internet user - Three people in three weeks can build the world’s fastest DNS resolver - Access control decisions can be made close to every user, fixing the VPN performance problem
- 18. We ship products to customers
- 19. Everything ships within 3-12 months If it can’t, it’s too broadly scoped We deliver value quickly and learn People using the product gives us energy and focus … and prevents us from making mistakes
- 20. The vision has to be world changing, the initial release just has to be useful
- 21. Impatience and laziness are critical skills
- 22. Questions
Editor's Notes
- Cloudflare has a traditional product and engineering org which builds our core products. It also has a Product Strategy organization which takes risks and makes bets on what the future will look like.
- Product and engineering keep the lights on (literally). They also innovate within each of the products we already have, making them better for our customers. Product Strategy is about new markets, new lines of business, new ways of using the key advantages we have as an organization to bring new products to market. It was created because we found ourselves forever sacrificing that long term thinking to satisfy the (very legitimate) needs of our existing customers. We needed a totally separate group which could focus on those things which will take longer to turn into revenue. As they grow Product Strategy products will graduate to the traditional Product and Engineering groups. It turns out disruptive teams also have to be organized a bit differently to be successful.
- We think about innovation two different ways. Iterative innovation is what happens within an established product line. Each generation (hopefully) gets progressively better than the last, faster, more reliable, and more feature rich. Competitors introduce features which you have to compete with, and you introduce features for them to try and best. Think of it as Ford vs Chevy. Disruptive innovation is what great startups try to do. They release products which are an entire world away from what currently exists. They have to be used different ways, support different things, and it usually takes a mindset shift on the part of customers to switch to them. But, they are not just 10 or 20% better than what currently exists, they can be 200% or 2000% better. They’re also risky, they’re a bet that the future will look different than the present, and that we know what that future will look like, and we’re gonna ‘skate to where the puck will be’, not where it is. They can dramatically fail, and are harder to market, but they create a real opportunity to change the world. Any disruptive innovation will eventually be copied, creating an iterative innovation ecosystem around itself. I’m going to explain this chart more in a future slide, but I introduce it here because it really shows what I’m talking about. Improving response time by 10 or 20% is a great accomplishment for an iterative innovation-based team. But in disruptive innovation, you’re finding an entirely new way of solving the customer’s problem, potentially improving it by 300%.
- This description aligns well with a way many reasonable people would think about structuring an important, innovative, project. You bring in every team who needs to be informed to make sure no one is surprised and everyone gets to have their hand in what is built. You write detailed specs before writing code because this is IMPORTANT, you don’t want to risk building the wrong thing. Finally, you devote a huge number of people to the project because THIS IS THE FUTURE OF THE COMPANY, it’s not something to toy with. Then the project fails.
- When you involve everyone, all decisions end up being made through consensus. But to do great things you have to make decisions which are risky, which represent the unique vision of people who can see the future and make a bet on it. That type of risk taking is antithetical to having too many voices in the process. Even worse, creating every meeting you might someday need consumes a massive amount of time. Time is a limited resource, what you spend on a meeting isn’t being used to build. Detailed specs seem like a great way to avoid engineering the wrong thing. In practice they lock your engineering decisions down at the beginning of the project when you know the least. When you are building disruptive things, you are doing research and development. You aren’t building something you’ve built a thousand times, you are reinventing the world. That can only be done as you create things, writing specs to clarify your thoughts and communicate only as you create. It’s tempting to apply a large number of people to match a projects importance. In practice, above a certain point the larger a team is the more opinions you have to contend with and the harder it is to move quickly and experiment. It has been seen time and time again how a startup of a handful of people can outmanuver the largest enterprises in the world, a small, passionate, team with autonomy is the ideal team to invent the future, no more, no less.
- The Razr was one of the most successful phones of all time. It also was almost never made. The team thought it would sell 300k units. They had to lie to execs and tell them 800k because Motorola wouldn’t consider building something which would sell less than that. That’s what you can be up against in large organizations, unwillingness to ship a product if it isn’t already guaranteed a success. But of course, in the world of disruption, nothing is guaranteed. It’s all an experiment, a belief that the world will look different in the future and a willingness to bet on that. The Razr ultimately sold 130 million units. But the team had to literally LIE to make it happen.
- Consider the 747. It’s one of the most successful aircraft of all time, conveying over 3.5 billion passengers and revolutionizing international travel. The only reason it is as great as it is was everyone at Boeing with any political sense wasn’t working on it. They were building the SST, a supersonic jet that was supposed to be the future of travel. That left the 747 team the space and freedom to build the first wide-body jet without the involvement of the team that would eventually lead the SST project to be cancelled. You absolutely want the entire muscle of a large organization focused on iterative priorities, having them focused on a disruption-based goal is a recipe for failure. Disruption happens in small teams with vision and autonomy.
- Back to our chart and one of our products. The chart is showing response time ms from around the world, with Workers clocking in around 3x faster than competing platforms. Each of these teams is working hard to reduce their cold-start time and latency, but they’re doing it from the premise they have to maintain backwards compatibility. That means they can only iteratively innovate. Disruptive iteration can be characterized by something which breaks at least one of the fundamental assumptions everyone else in the industry is holding onto.
- We created Workers because no other platform could be affordably and efficiently deployed to all of our data centers around the world. Every serverless platform out there uses containerized processes. Workers runs everyone’s code in a single process using isolates. Every virtualization platform of the last 40 years has tried to provide a POSIX-compliant API that allows customer’s code to think it’s running on its own machine with its own operating system. Workers just… doesn’t. And in return, everything changes for customers.
- Workers has, and is, having a massive impact on Cloudflare. You would logically think that that meant it was developed by a large team commensurate with its importance. But if that was the case, it likely never would have shipped. It’s only after its position in the market has become clear that the team has grown.
- And that’s how we work everywhere.
- As I gave this presentation one of the longest holders of a short-selling position on the car company Tesla had just reversed his position. After years of betting the other car companies would catch up with Tesla and pass them, he finally gave up and crowned them the winner. It’s easy to confuse iterative innovation ability with disruption ability. Disruption takes entirely different chops though, and a successful disrupter looks a lot more like Tesla than Ford. It was actually easier for a small team to accomplish it than a large company.
- We won’t be building a car anytime soon (as far as I know!). We have guiding principles which I’ve just roughly sketched here. What’s key is that we have a big vision that can fit a lot of innovation inside it. It’s critical that we haven’t collapsed that vision to something so narrow that we trap ourselves in an iterative world. Doing what we do best refers to ensuring that anything we do is not just competing head-to-head with other companies but is instead relying on something we do uniquely well or have which they don’t. In the next slides we’ll consider a couple of the advantages we have, but it will be different for every company.
- Here is an example of one of our advantages, the trust felt by our customers. It means when we launch 1.1.1.1, the world’s fastest DNS resolver, people trust us to protect their privacy. It would be very hard for a startup to earn that trust in the same way. Similarly, when we launched our no-markup domain Registrar, people trusted their domains with us. It would, again, be a painstaking journey as a small company to earn that trust, but we get it on day one because of our reputation.
- Obviously dozens of people supported the launch of 1.1.1.1 in various ways, but the core engineering team was tiny. And they launched the fastest DNS resolver in the world, something which would take at least half a decade to do from scratch. They were able to tap into a massive network of servers in 150 locations, all running an identical software stack. That is a key advantage which plays into many of the things we do.
- This is a critical thing. Other R&D divisions are about building proofs-of-concept, experiments, or even doing original science. We build products which ship.
- Similarly, we ship products quickly. Having a product in the hands of customers gives us energy. There’s nothing more exciting than having a call with a customer who is building things with what you’ve built. That energy keeps us engaged and building. Particularly when you are doing disruptive innovation, it’s just not possible to predict the future well enough to build for longer than 12 months (ideally less) without what you’ve done being confronted by the customer.
- In the same vein, we don’t do anything which doesn’t have an impressive ultimate vision. BUT if we wait to realize that full vision we will end up far from what customers actually want, and when it’s time to release it our go-to-market will be woefully behind. What we first ship should be on the path to our vision, but it doesn’t have to realize it, it just has to be useful, in some way, to some person.
- This is easy to misinterpret. I don’t define laziness as not wanting to do work, I define it as not wanting to expend more work than is necessary. This is not because we don’t want to work hard, it’s because we want to get a tremendous amount accomplished. Specifically in the world of disruptive innovation, it’s very dangerous to be willing to wait patiently for a long-lived project to complete; it often doesn’t. It’s also dangerous to be willing to accept having to do a large amount of work for a luke-warm result. Disruption is a fragile thing, you need the little time you have to make bets. Long-lived work is critically important to any business, but it’s best done in a different environment. This is not a playbook for every organization or every part of an organization, it’s specifically how we operate when we wish to disrupt. We could not function as an organization without many teams focusing on systematic growth of our existing markets and products.