Bezos’ Response to a 90% Drop in Amazon’s Stock
Bezos’ Response to a 90% Drop in Amazon’s Stock
+ Reducing PM Attrition
Bezos grew Amazon to $1.75T as CEO. But, in 2001 after the dot-com crash, Amazon’s stock had fallen 90% to $5B.
In a hail mary attempt, Bezos invited a book author to Amazon. Together, they created the foundation for trillions in market cap:
The author was Jim Collins, who published Built to Last in ‘94. By ‘01, Bezos had adapted several of its concepts into Amazon’s principles:
Tyranny Of Or → Avoid 1-Way Doors
Homegrown Leadership → Hire & Develop the Best
Good Enough Never Is → Insist on the Highest Standards
So, when Collins told Bezos that the key concept in his upcoming book was a flywheel, Bezos was eager to adapt it. Collins had in mind the 5,000 lb old style flywheels. They took hours to turn at first. But at some point, WHOOSH! Their own momentum kept them going.
Collins had commissioned a large team of Harvard MBA researchers for the new book. They identified good-to-great companies that had delivered sustainable, S&P 500 beating results for years. They then compared those to mediocre companies that had flailed.
What Collins and the team found is the great companies were spinning flywheels. It wasn’t the first, or fifth, or one hundredth rotation that got them spinning. It was their concentrated effort that led to the breakthrough momentum. Thereafter, the heavy disk would spin on its own.
On the other hand, mediocre companies were constantly launching new initiatives. Instead of achieving breakthrough momentum on one flywheel, they tried to create many. But each never achieved breakthrough velocity. They had to keep manually cranking them.
Given the insight, Bezos and Collins began sketching out Amazon’s e-commerce flywheel. They identified that Amazon could generate self-reinforcing momentum in 2 ways:
Lower cost structure leading to lower prices leading to more scale and back to lower costs.
Greater selection leading to customer experience leading to traffic leading to more sellers and back to greater selection.
These two elements have been the backbone of Amazon’s e-commerce business for the 20+ years since the pair initially founded them.
To this date, the flywheel continues to extract market share for Amazon. Last year, Amazon reached a tremendous 56.7% of total US e-commerce sales. At $614B in revenue, it has left the competition - like Walmart - in the dust.
So, what can we learn from Amazon’s e-commerce flywheel? As product and business people, we are tempted to start new flywheels constantly. But, it usually pays to focus on spinning our main one with self-reinforcing momentum faster. Sketch out your flywheel, and go get it.
Reducing PM Attrition
Product Management is one of the highest attrition jobs in tech. Everyday, I talk to PMs who want to leave. They are stressed, unhappy, and ready to move. Despite being well paid.
How can candidates find a great job - and companies retain them? It comes down to what makes a great PM job:
1. Dedicated eng team
Being a PM without an eng team is a farce. You are more like a product strategist or consultant. Yet, these positions are everywhere. These positions tend to have the highest attrition.
PMs need to build and deliver features that impact users. This is impossible without engineers (or “ops” or “tech design” - people who release features). A magical ratio is 7:1 engineers to a PM.
2. Dedicated design analytics, & user research team members
Although lack of design works for certain backend teams, most those PMs end up in the position of needing to ask other teams for support to make impact. They end up in the same position as PMs without dedicated eng.
Similarly, analytics are critical for good prioritization and experiment analysis. PMs who are shipping lots of features don’t have time to write SQL queries and build dashboards.
Finally, working to do user research (UXR) on your own as a PM is time traded off with other activities. Discovery and usability testing are sciences best performed by experts.
Most PMs need at least half a resource of design, analytics, & user research. PMs doing these jobs trades off with driving execution, developing strategy, and bringing along the company. This causes PMs to either underperform or work long hours - driving attrition.
3. Working for a great line of product leadership
There is no formal training for product management. (The few that exist are not to standard.) Most PMs have to learn on the job.
As a result, leadership matters. Great product leaders teach specifically via feedback, 1:1s, and career sessions. They also teach by example. Decisions aren’t made by gut, but by discovery. Features aren’t graduated just because, but due to metrics.
Bad product leadership, on the other hand, is ubiquitous. It’s not uncommon to find product leaders who haven’t even been individual contributor PMs. They can rarely coach how to execute and influence. They don’t have the context.
4. Empowered to determine your own roadmap and strategy
Product managers who are glorified project managers rarely stay. Yet, this is all too common. PMs are handed roadmap and strategy by execs.
On the other hand, there are few thrills quite like leading an empowered product team. These PMs feel empowered to make an impact and change the world.
5. Collaborate with supportive cross-functional colleagues
Often, it’s an influential sales team blaming the product team. Other times, it’s marketing, partnerships, finance, analytics, design, or legal. Whomever the culprit, once other functions point the finger, PMs leave.
But when the entire company begins to row the boat in one direction, magic happens.
Bonus: Chrome Case Study for the 5 Central Questions of PM
Chrome has 3.2 billion users, 42% of the world’s population. It’s a masterclass in product management as the pursuit of 5 central questions:
Why → Vision
What → Strategy
Who → Segmentation
When → Roadmap
How → Specifications
1. Why → Vision
Product vision should answer the question, “why we are doing what we doing?” It should be a timeless ideal state that helps motivate the larger picture. It should take the mission & principles and translate them to the specific product team.
Chrome’s vision is a great example. Sundar saw web architecture evolving faster than browser architecture. By 2008, websites were using XML HTTP to create rich AJAX sites. Google’s vision was to create a browser that kept up with the pace of innovation on the web.
2. What → Strategy
Product strategy should answer the question, “what are we going to build to achieve the vision?” It should encapsulate decisions the team has made given the competitive and user landscape of the now. It should describe what a product team will build.
Making a browser that kept up with the pace of innovation on the web could be done many ways. Chrome chose that the user should enjoy surfing the web and the browser should stay out of the way. So, it focused on speed, security, stability, and multiple isolated tabs.
3. Who → Segmentation
Product segmentation should answer the question, “who are we building for?” It should explain who you are not building for. Building for everyone is building for no one. It should answer the job to be done the product will service for the user.
Sundar led Chrome to build for technologists that wanted to experience the web to its fullest. He described users like himself, who are doing everything from spreadsheets and calendars to HR software on the web. It was a radical vision for 2008.
4. When → Roadmap
A roadmap should answer, “when are we going to deliver the features to achieve the strategy?” It should sequence planned problems and features. Dates are out of fashion. It should help achieve the vision as fast as possible, via the strategy for the segment. We usually build the roadmap for a time period. It should highlight what is above and below the line.
For the Chrome beta, above the line was Windows, open source, 43 languages, and 100 countries. Below the line was Mac, Linux, and Mobile.
5. How → Specifications
Specifications answer the question, “how should we implement a feature we are building?” It should have enough for design to work off of. After the design is ready, it should have enough for engineering to build.
We do not have Sundar walking through a spec. But, from my time at Google, I can say a great spec has:
What:
Product mock
Description of implementation
Why:
User story
Business motivation
How:
Phasing
Success criteria
Length is less important than good thinking.
In summary, as PMs, we can learn from the decisions master PMs make - like Sundar with Chrome.