Dear friends,
In the age of AI, large corporations — not just startups — can move fast. I often speak with large companies’ C-suite and Boards about AI strategy and implementation, and would like to share some ideas that are applicable to big companies. One key is to create an environment where small, scrappy teams don’t need permission to innovate. Let me explain.
Large companies are slower than startups for many reasons. But why are even 3-person, scrappy teams within large companies slower than startups of a similar size? One major reason is that large companies have more to lose, and cannot afford for a small team to build and ship a feature that leaks sensitive information, damages the company brand, hurts revenue, invites regulatory scrutiny, or otherwise damages an important part of the business. To prevent these outcomes, I have seen companies require privacy review, marketing review, financial review, legal review, and so on before a team can ship anything. But if engineers need sign-off from 5 vice presidents before they’re even allowed to launch an MVP (minimum viable product) to run an experiment, how can they ever discover what customers want, iterate quickly, or invent any meaningful new product?
Thanks to AI-assisted coding, the world now has a capability to build software prototypes really fast. But many large companies’ processes – designed to protect against legitimate downside risks – make them unable to take advantage of this capability. In contrast, in small startups with no revenue, no customers, and no brand reputation the downside is limited. In fact, going out of business is a very real possibility anyway, so moving fast makes a superior tradeoff to moving slowly to protect against downside risk. In the worst case, it might invent a new way to go out of business, but in a good case, it might become very valuable.
Fortunately, large companies have a way out of this conundrum. They can create a sandbox environment for teams to experiment in a way that strictly limits the downside risk. Then those teams can go much faster and not have to slow down to get anyone’s permission.
The sandbox environment can be a set of written policies, not necessarily a software implementation of a sandbox. For example, it may permit a team to test the nascent product only on employees of the company and perhaps alpha testers who have signed an NDA, and give no access to sensitive information. It may be allowed to launch product experiments only under newly created brands not tied directly to the company. Perhaps it must operate within a pre-allocated budget for compute.
Within this sandbox, there can be broad scope for experimentation, and — importantly — a team is free to experiment without frequently needing to ask for permission, because the downside they can create is limited. Further, when a prototype shows sufficient promise to bring it to scale, the company can then invest in making sure the software is reliable, secure, treats sensitive information appropriately, is consistent with the company’s brand, and so on.
Under this framework, it is easier to build a company culture that encourages learning, building, and experimentation and celebrates even the inevitable failures that now come with modest cost. Dozens or hundreds of prototypes can be built and quickly discarded as part of the price of finding one or two ideas that turn out to be home runs.
Importantly, this also lets teams move quickly as they churn through those dozens of prototypes needed to get to the valuable ones.I often speak with large companies about AI strategy and implementation. My quick checklist of things to consider is people, process, and platform. This letter has addressed only part of processes, with an emphasis on moving fast. I’m bullish about what both startups and large companies can do with AI, and I will write about the roles of people and platforms in future letters.
Keep building!
Andrew