System: Funding Model: P&L Approach
This is an excerpt from my longer article “Systems: How Product Best Practices Drive Success at Amazon.
Funding Model: P&L Approach
Some might argue with my claim that the WBR meeting is what truly provides the strongest accountability at Amazon. For many, it is the company's funding model that rules, and this opinion indeed holds weight. Why? Because this system requires you to justify your ROI for everything. It is the magic of a P&L mindset brought to life for all product and engineering teams at Amazon.
In order to get your product "funded", to get engineers, designers, data scientists, product managers, and resources with which to build it, you must make a case for why your product ideas are more deserving than the competition's. This creates an interesting dynamic, both between teams and across product and engineering.
The Engineering View
My focus has so far been on the product manager's view, but I want to take a brief moment here to address the unique benefit this P&L approach provides on the engineering side of the house. The engineering manager directs his team by balancing his P&L, which can be funded by one dedicated PM team or spread across multiple teams. There is also another form of funding within the engineering organization, in which pure platform plays can be funded from the engineering leadership. This empowers engineering managers to build and fund their own ideas to improve the underlying architecture. It also fuels independence and longer-term approaches to solving problems for the customer. If there are clear benefits for your product, a PM team can reap the rewards of an enterprising engineering manager.
The Product View
As a rule, the bulk of an engineering team's time is dedicated to building efforts that the product "funds". However, the engineering team also has two other buckets of "budget", one for KLO, ("Keep the Lights On") efforts, otherwise known as "On Call and Tech Debt", and another for Engineering Excellence (EE). EE ensures that the engineering team has time to develop and explore their big ideas. As a PM, I have to fund the budget but I can’t touch it. This is simply the cost of doing business.
What I miss most about this structure is that the engineering manager had something to negotiate with. Without this approach, I have found that tech debt discussions tend to devolve into an absolute mess. With it, systems are protected, and engineering managers are incentivized because they control some of their team’s destiny.
Two Views on P&L Ownership
Amazon's setup holds both the PM and EM accountable for planning what their resources should work on and making the case for more budgets. While the PM holds the bulk of the budget, to figure out how it is being spent, they must work with their engineering manager to balance things out in order to produce the product and meet goals. However, this system also gives engineering a voice in a world heavily driven by the business and product side of the house. Additionally, when both the PM and the EM manage a P&L there is a sense of shared responsibility and camaraderie.
Selling your Idea
The other thing I love about Amazon's funding model is that if either a PM or an engineer has a great idea, they can write a Working Backwards document and shop it around. I once pitched a plan I had to several teams to try to get it funded, with mixed results. While this was frustrating, it was a mini case of market forces at work, and a sign that I probably needed to strengthen my proposal. The beauty was that I was encouraged to give my idea a try if I felt that passionate about it. Failure was okay, and I was still respected for trying.
Lines Provide Control and Ownership
The last benefit of this funding model was that it made clear there were lines we couldn’t cross. If we did, there needed to be a negotiation. This meant there was always a budget for tech debt—not necessarily a lot, but always some. This was left in the hands of the engineering team; the product team couldn’t touch it without negotiation. The same went for engineering excellence. As I recall, we ideated so much with our engineering team that we often knew what the EE hours were going toward, and were equally enthusiastic. Regardless, allocating those resources gave engineering teams clear ownership.
I go on about this last one a bit because, outside of Amazon, the absence of this practice leads to a mountain of debt, and causes engineering teams to have less of a voice than they do within Amazon. An empowered engineering team is a dream partnership for any good PM.
