The Mind of Jeff Bezos
I’ve worked at a few companies since Amazon and, as time passes, I’m realizing how wise Jeff Bezos really is. Despite the geeky perception, Jeff Bezos really was visionary in many, many ways. Three ways in which I believe he was absolutely visionary is in his (1) focus on the customer, (2) in the product and software development practices at Amazon, (3) and in his insights on team dynamics and in team size.
Amazon is a company that is absolutely customer obsessed — from the top-down. It has been able to build a culture with the customer at the center, because its processes, technology, and the general worldview of its employees are centered right on the customer.
The Amazon Core Values, for example, are not just a list of rote phrases the people forget after they are tacked-up on the wall: they are hard-core in every Amazonian. Specifically, the Amazon Core Values are:
- Customer Obsession: We start with the customer and work backwards.
- Innovation: If you don’t listen to your customers you will fail. But if you only listen to your customers you will also fail.
- Bias for Action: We live in a time of unheralded revolution and insurmountable opportunity – provided we make every minute count.
- Ownership: Ownership matters when you’re building a great company. Owners think long-term, plead passionately for their projects and ideas, and are empowered to respectfully challenge decisions.
- High Hiring Bar: When making a hiring decision we ask ourselves: “Will I admire this person? Will I learn from this person? Is this person a superstar?”
- Frugality: We spend money on things that really matter and believe that frugality breeds resourcefulness, self-sufficiency, and invention!
The product development process at Amazon is also absolutely centered on the customer. Amazon follows a process called "Working Backwards", which means that the first deliverables created are the documents at launch, then work backwards towards the items closer to the implementation. Defining a product this way adds clarity and simplicity — you know at the front-end what the customer can expect, and working backwards allows the team to build it. Here are the general steps followed in this process, and I take it directly from Werner Vogels:
- Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists – what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product – not just how we think about it internally.
- Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
- Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.
- Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.
Following this process reduced so much "front-end" time — that is, the cycle time from concept-to-delivery (brainstorming, discussions, and arguments) was significantly reduced because the team and peripheral stakeholders agreed earlier rather than later on what the product would look like in the end. Moreover, because of the bias-for-action core value, people naturally want to produce, rather than have long, drawn-out discussions: at the end, people want working code, manifested in a store that is launched and adding value to the top-line.
This process places the customer at the center, and drives simplicity and clarity throughout the process. Start with the customer, and work backwards — is a very effective process that works well and places the customer in her rightful place.
Regarding team size, Amazon follows a 2-pizza team model: that is, no team should be larger than two pizzas can feed. This model is followed all throughout Amazon. The result of this approach to team size is, I believe, a much simpler, effective, and efficient team. I’ve talked much about team size and I argue, quantitatively that as team size grows, the number of communication links grows exponentially. This means, then, that the opportunity for communication breakdown and miscommunication grows exponentially as team size grows. This is important because one of the main reasons for project failure is communication-related. The 2-pizza team, I believe, really avoids this problem all-together.
Amazon is not perfect, and neither is Bezos. But, people underestimate him, to be sure. One of the outcomes of Amazon’s secrecy is that few become aware of the really cool things that Bezos has started within Amazon and what other people at Amazon have done that are incredibly entrepreneurial and innovative. The above items are just a few that I want to highlight and attribute to Bezos. While not perfect, he is wiser and much more of a visionary than people give him credit for.
The content below is taken from a Fast Company interview with Bezos. The items below support what I claim above:
Communication is terrible.
When Jeff Bezos’s people said they needed to communicate more within the company, he shocked them by shooting back: "No, communication is terrible." To promote his decentralized vision of the company, he created "two-pizza teams": highly autonomous task forces with five to seven people — no more than can be fed with two pizzas — who innovate and test new features.
Take leaps of faith.
Bezos takes risks on ideas — such as letting Web surfers search the full texts of hundreds of thousands of books — that are so bold and innovative that the only way to know whether they’ll work is to try them on a grand scale.
Be simpleminded.
Bezos loves making decisions based on hard data, but when that’s not possible, he believes in the power of being "simpleminded," relying on common sense about what would be in the best interests of his customers.
Add up lots of little advantages.
Bezos realizes that Amazon doesn’t have any single big advantage over potential competitors, so he’s constantly introducing small but innovative features that add up to a superlative experience for customers.
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
That’s a good post. In my time at Amazon, I definitely found the small team sizes to work well for rapid innovation. However, where it sometimes breaks down is when the software is no longer new and exciting, but enters “maintenance mode”. What I’ve seen happen is that in a small team of maybe 5 or 6 people, occasionally a few will leave at around same time (usually after completing some major project, or with a management change). The knowledge about how the software works is concentrated in only a few folks (because there’s not much communication among teams) and so when people leave, they take a tremendous amount of the product with them. The replacement team then wades through the mess ill-equipped to deal with the software that was left behind. There is I think an excess of waste that comes as a result of developer attrition because of the lack of emphasis on good documentation and well-written code (which are forms of good communication).
I think Amazon’s model served it wonderfully in the early years, but now that it is a bigger company, some more cross-company communication would be helpful. I don’t remember how many times I heard about several teams each doing almost exactly the same thing – reinventing the wheel over and over. When it gets really big, it’s hard for the left hand to know what the right’s doing. That creates waste – which as I’ve heard, the Lean model is all about combating.
But then again, these are just my observations from one corner – I’m sure in some parts of the company (especially the growing, new, exciting parts), the 2-pizza model still works great.
Leave a comment
Additional comments powered by BackType
Great post. I love Amazon and this brilliant development model seems to be one of the reasons they’ve been so successful. Thanks for sharing.