Throughout the past month at YCG, the thread that seem to bound some of the best performing companies was what the founders had learnt from their time at Amazon. Notes: names redacted, pseudo names given.
Jason (CEO of IPO’ed platform business) premise is that Google is a not a good example of organisational success. They have made so much money from search that they can afford to lose unlimited amounts of money building random things, like Google+. Amazon, however, has had fierce, near perfect competition in many of the verticals, e.g. ecommerce, AWS. So for a scaling startup, Amazon’s approach to winning despite intense competition is more useful.
Let’s assume we agree with this premise. What results is an intriguing set of organisational principles useful to how an organisation is run. I’m not advocating or suggesting that Xendit will adopt all of these, but at minimum food for thought and at maximum, an excellent guide for a default lest we have good reason not to adopt this philosophy.
Build a bench of strong general leaders
If we believe the world is full of customer problems then a startup is just an engine that produces and solves customer problems predictably. To execute, we need to build a bench of leaders that can then go solve this problem.
- Single threaded owners – focused on 1 product/problem and are accountable for its success
- Problem discovery comes from intellectual curiousity and asking “why?” … a lot
- Have autonomy to make decisions
- Squad has control to move quickly, i.e. can push to production without relying on other teams
- Doesn’t have to be technical lead, e.g. Andy Jassy who runs AWS
- Managed with monthly business reviews
Small teams that are self-contained can move faster. The idea is that everybody should be focused on the customer for each service. They hold their P&Ls, revenue targets, adoption targets. If something’s not going right, it’s the leader of that service that gets the tag. They don’t get to point to somebody else and say, ‘That’s not my problem.
In Jason’s case, customer discovery is the domain of the GMs (PMs in ours).
We’re a platform business, so we get to talk to customers and ask what their problems are. Ask them why they built on top of us? What they built? Ask “Why?” 5 times and they’ll tell you what’s missing in the market.
Penny agrees. She asks for 2 things: 1) what devs have built on top of the platform and 2) curiousity into the “why?”.
PMs have to have this curiousity. I trained it. I saw a PM present a product, answer Y/N questions and was done. I then asked 55 minutes of questions. The PM got it and never finished within 5 minutes again
Small decentralised teams drive product development
Amazon employees are organized into small, multi-disciplinary teams focused on a single product or problem. These teams are usually no larger than 6-8 people in size and hence called “two-pizza teams.” They are run by a single-threaded owner who has full responsibility for the team, even if her teammates come from different disciplines (e.g., Product, Design, Engineering, QA, Product Marketing). Performance reviews are written by two-pizza team leads, but functional departments still exist and in areas like Marketing, Finance, etc.
Jason is a huge proponent of this model. It allows innovation to come bottom up, allows whole organisation to move quickly. The trade-off? It optimises for speed over efficiency, e.g. often 2 of Jason’s teams work on the same thing. In such situations, they compete and the best one wins whilst the other team gets repurposed.
You get speed and better product-market fit because you’ve got folks focusing exactly on what’s needed and it’s not a least common denominator approach. In a growth stage, I will take faster time to market and better product fit over the most efficient use of resources and super-tight consistency
Amazon doesn’t do values, leadership principles guide performance reviews
Amazon has 14 leadership principles which permeate hiring, firing and performance reviews. These aren’t to be memorised but are specific behaviour they want to incentivise, and punish when absent. Some are famous, e.g. “leaders are right, a lot” and “have backbone, disagree and commit” which drives for some hard debates and drives certain culture.
Emory (CEO of billion dollar consumer internet platform) says this avoids fluffy values that aren’t clear. These 14 principles are very practical and help you prioritise, make decisions in a product discussion.
Work backwards from the customer
At Amazon, we were required to product press releases and user FAQs before we were allowed to build. This doc was then sent upwards to the chain of command for review. This forced us to think about the value to the customer and why they’d want what we’re building. We have this in principle already at Xendit when you hear us obsessing about what customers told us or why customers will want what we’re building.
Engineering consistency through senior engineering reviews
Instead of engineering approvals at multiple levels, Amazon uses a group of respected individual contributor senior engineers to review code for teams outside their own. These senior engineers work on a 2 pizza team, but are consulted during architectural decisions and review code across the organisation. In our world, we’re still defining how we do this. We’re currently more centralised than the Amazon model seems to be. I think that makes sense in this phase as we’re trying to iterate into the right engineering structure for us.
Mission to metrics
Amazon provides guardrails for product teams by forcing all product teams to point to 3 metrics that they believe are the drivers for the business model: price, selection, convenience (previously fast shipping). Every team is able to point to how their product feature, effort builds towards one of these 3 metrics. The sentiment is roughly “You work on one of these metrics, now go!”. For Emory, the 3 metrics are “fame, money, love” and all teams can point to improving one of those three metrics.
Each GM is expected to create a 6 pager plan for the year, including P&L and budget request. The plan is locked in in February. The teams then develop their roadmaps, with GMs checking in with senior managers as needed. Frugality is a core value, so teams get less than they want.
We try not to spend money on things that don’t matter to customers. Frugality breeds resourcefulness, self-sufficiency, and invention
This is where Jason gets really excited.
I’m skeptical about OKRs and business plans. Google never had to fight for survival, business plans are unclear on prioritisation
Instead, Jason’s litmus test for a good plan is that leaders are arguing over what to build. Instead of plans, he asks for a list of priorities. What’s the #1 thing we need to accomplish this year? Then requires leaders to stack rank priorities to list of 6-9.
Now Jason, Penny (B2B Marketing platform) and Tom (B2C logistics company) rail against product strategy.
Product strategy is a terrible idea
Google+ came from the top down (void of customer context) and it was a failure. Amazon Phone too. So have every team do prioritisation with ambient awareness of company goals. GMs should use their brains to come up with plans. These GMs are then accountable for these plans in metrics and Town Halls.
My synthesis of these strong opinions are still the same. We hold 2 things in tension:
- YC’s advice “Having no plan is planning to fail”
- YC’s advice “The first thing to get thrown out on the ground is the plan”
I think GMs/PMs should have a view of what needs to happen that period, e.g. payment parity is real and we should have it in 2019. However, the actual execution and timing is based on customer needs, e.g. Ovo goes in first, we need to also fix VAs so customers don’t give us feedback that we’re the worst in the country for it.
Service driven architecture rather than monoliths (including internal services)
Amazon builds to a service based infrastructure that has every service owned by a small product team. If you want to build a new product, you spin up a new service. Whoever builds the service has to maintain the service.
Internal services are held to the same standard as external services. This means clean API documentation that anyone that needs to know can know. This also means it’s very quick for new businesses to get stood up. The open the documentation and services to the public, now they have a new product.
We’ve been lucky to have to accidentally do this a few times. The pivot to B2B happened by exposing an internal service, disbursement via APIs. Lately, you’ve seen us emphasising this more as we build more and more products.
Force prose
Amazon is also famous for banning powerpoint for presentation. The use 6-pagers prolifically, where you’re forced to write down what you want to say. It optimises for a few things:
- lowers ability to “sell” with nice slide vs tell facts
- forces person to push to clarity in thought (as much for writer as for audience)
- provides paper trail for decision making
This method has rubbed off on the other CEOs. Danielle, Emory, Jason and Tom don’t do slides. They rely on the written word.
Finding growth after hitting 0%
I asked the CEOs how this model plays out in an extremely stressful situation. Danielle said that plateaus in growth are natural but also death. Most companies at our stage have found some product/market fit, the founders have found a rocketship, lit it and are holding on for dear life. The companies who are able to get to the next level then need to find a second rocketship and light that whilst holding on to the first. He believes finding this second rocketship is the primary role of senior leadership.
Emory describes a different story. There was a period of time where his business wasn’t growing. He kept asking his team “What aren’t we growing?” Each product team was experimenting to find an answer. In the end, it was the insights team that came up with the root problem “our users weren’t sticky to streamers”. A product team then proposed a solution. They tried it. It worked. The morale of the story – even when the future was dire Emory relied on autonomous product teams to find the solution.
