Should You Innovate Like Apple, or Google?
Apple and Google characterize two extremely different approaches to innovation. Consider a few quotes (courtesy of this article) from Kim Scott, who worked at both. First, about Google:
If you wanted to get something done at Google, you didn’t have to ask permission. You would just start telling people you were doing it and start doing it. So there’s sort of a consensus-based, fast-moving culture — which I would have said was impossible before I joined Google.
Then, about Apple:
And the name of the game at Apple was not to get discouraged by the nos and keep pushing
Then she describes what happens after getting approval:
Resources flowed. […] Apple cleared my decks and didn’t ask me to do anything [else]. That was amazing. You were expected to go deep and perfect things.
Others on Medium have highlighted the divergence between these two approaches to innovation. In Iteration is not design, Todd Olsen argues that the churn and burn approach to innovation is too costly to work for most organizations.
On the other hand, Jonathan Courtney of Muzli argues that, if you don’t release fast, you’ll be left behind.
Why the difference?
Why is Apple so painstaking, while Google is so fast? As other examples, Amazon is typically very fast, and Tesla is slow and careful like Apple.
There are some possible explanations. Apple and Tesla are primarily hardware companies, and with hardware, details matter. Once you decide on the material for a display, there is no changing your mind until the next generation of the device. With software, there is much more flexibility. Google can isolate product releases to certain early users much more easily. Amazon can (and does) test new ideas in certain markets.
Culture is another possibility. Elon Musk and Steve Jobs are two of the more dominant CEOs of modern times. Jobs always leaned toward vertical integration, as does Musk. The culture at Google is more open, as mentioned above, and employees often use and support open source (or at least they did for a while. Not sure where things are headed for them.) Jeff Bezos is extremely fast-moving, and habitually okays projects even if he disagrees with them. Actually, in his 2017 letter to shareholders, he neatly describes the dichotomy I started this article with, but in his terms (Day 1 = speed, Day 2 = what Bezos wants to avoid):
Day 2 companies make high-quality decisions, but they make high-quality decisions slowly. To keep the energy and dynamism of Day 1, you have to somehow make high-quality, high-velocity decisions. Easy for start-ups and very challenging for large organizations. The senior team at Amazon is determined to keep our decision-making velocity high. Speed matters in business.
Middle Ground
Both approaches obviously work in different circumstances, and maybe the preceding paragraphs help understand why. The important thing to note, however, is that there is no universal.
In most debates, essays gravitate toward the endpoints of the spectrum. This leads to polarization. It must be human nature to do this, but it is artificial. It’s not binary. Let’s reconsider some of the above perspectives:
Elon Musk is actually ridiculously fast. For example, he tweeted about the idea for The Boring Company as a joke, but then by February 2017 he had purchased a giant drill and started digging with it.
Google takes its sweet time on hardware, just like anyone else. Google also likes to acquire companies that embody the innovation approach of Apple, such as Nest Labs. There is no inherent conflict between the two, at least in that case.
In building Amazon, Bezos was extremely deliberate and theory-driven. He moved fast, sure, but he was painstaking about the design of the business.
What I’m arguing is that this is a case where we should avoid making conclusions from the outside-in. It’s too hard to know the internal details that dictate these approaches. Instead, reason from the inside-out. There are a few guideposts, in my experience:
- Can you lower the costs of iteration? If so, it will always pay you back. One of the major reasons SpaceX progressed so quickly is that they build testing systems for their rockets that allowed them so much real time information. The Wright brothers did essentially the same thing by building a mini wind tunnel in their bike shop. They learned huge amounts about different wing design iterations without having to get out an fly all of them.
- Iteration is always necessary. The only difference is whether it is public or private iteration. Private iteration is what Apple does: only employees see the stuff before the final version. Google releases early versions into the wild, which is public iteration. The decision should be fairly obvious in context. If you can silo the release to early adopters who won’t be too angry at bugs, it may give you better information. If you can update the product remotely, that eases the costs of public testing. With hardware, both of these things are not as easy. Fairly straightforward stuff.
- What is the pace of industry progress? This determines whether you’re at risk of being left behind, or whether a fast release will seem rushed.
The other guideposts are too context specific to describe as general principles, but expertise, product maturity and form factor, business model, user base and brand all play important roles.
Hierarchical Consistency
Getting meta for a moment, think about innovation about how to innovate. This is something I study as an academic. You can’t think inside the box when considering how to think outside it. Don’t assume there is one single approach to innovation, that one firm represents. Apple does one thing, Google does another, they both work for different reasons. If you think otherwise, you risk missing the benefits of one or the other. More importantly, you risk missing new ways to innovate that nobody currently practices. In other words, if you think it’s valuable to make new products, it’s hierarchically consistent to realize the value of new ways to make new products.
