Docker pivoted from ops to developers
How Docker 2.0 went from $11M to $135M in 2 years
Docker’s real mistake was trying to sell infrastructure control to ops when its product had already become a daily habit for developers. That created a mismatch between who loved the tool and who was asked to justify budget. The result was a heavy enterprise sales motion around Swarm and Kubernetes, even as Docker Desktop and Docker Hub were already where developers were getting everyday value, which made the later PLG reset much more direct and efficient.
-
In practice, ops was being asked to buy one more system to manage, while developers were already using Docker locally to build, test, and package apps. That meant sales calls started with education about containers, not with a buyer trying to expand an already proven workflow.
-
Google and the cloud platforms made orchestration hard to monetize by pushing Kubernetes into the open source core and then selling managed versions through cloud infrastructure. That undercut Docker’s original enterprise revenue center and made the desktop and developer workflow the cleaner place to charge.
-
The post 2019 model flipped the buyer path. Docker started with low price developer seats on credit cards, then sold team features like SSO, admin controls, and usage visibility to engineering managers once usage was already visible inside the company. Statsig’s workflow reflects this pattern, with developers choosing and paying for Docker directly.
This points toward developer tools being priced closer to the moment code is written, not the moment infrastructure is deployed. Docker’s expansion path is to turn its place on the developer desktop into a broader productivity and safety layer, then grow from single user utility into team wide spending inside engineering orgs.