This past week in one of our Accounting classes, we went through a ‘profit wheel’ for a coffee company. This is part of our SMB internal accounting management module, which has proved slightly more interesting than our accounting principles and rules module. A profit wheel is a tool managers use to either motivate teams to hit certain targets, or work with their internal teams to understand the state of the business and what targets to hit. Although we did not explicitly use a profit wheel in Dropbox planning, Dropbox really transformed as a company when we went from only sprintly/quarterly planning to company-wide annual planning.

Dropbox had a top-down and bottom-up approach: product managers would pitch lower level ideas that would trickle their way up in the way of resource request, and the executive teams would give high level targets or green light entire new product lines. Somewhere in the middle these request met, and resource allocation and negotiations would ensue. It was critical to have an executive sponsor to be able to receive the funding you might want as a product manager.

Most of the time as a product manager at a SAAS company, we would only be concerned with two numbers during planning: headcount required and growth estimates (that were tied to revenue estimates). The profit wheel we analyzed in class covers these inputs as well, but SAAS tends to be less interesting to analyze with a profit wheel since you assume no capex. Usually.

I worked on a project when I was the lead for the Paper Enterprise team that required more analysis past headcount and growth estimates, which was my first foray into more conventional profit planning. Since Dropbox owns and runs its own data centers across several locations and a few different countries, sometimes product features will directly impact investment into computing resources required, which is a form of capex for Dropbox.

I had pitched a few additional search features to close a potential enterprise client, which required cross collaboration with our finance teams and our hardware operations teams. It was really interesting to see their projections for costs to expanding certain data centers and computing resources, and my inputs into the process included possible growth numbers and search usage numbers. Sales and marketing came in to confirm approximate projected sales numbers, and in this way we constructed our own profit wheel for this project. These numbers were fed into company-wide numbers to allocate resources and project growth, and executive management finalized commitments and set our targets with this information.

What’s interesting is an inherent tension between planning and setting targets. What comes first? If you set targets and then have teams plan for them, perhaps there is a lower likelihood that you set achievable targets. But if you plan first and then set targets, you incentivize your teams to produce planning data that encourages setting lower, more achievable targets since presumably they’ll be compensated for their ability to achieve a given target.

The first year we did annual planning, we did finished in May for the same year we had been planning for, which was comical but also to be expected. Every year the company improved, and when I left the company had started finishing the planning process before the year we were planning for started.

At even more mature companies, entire teams will spend 90% of their time over an entire year to plan for the entire company. Although this requires more communication between teams, it relieves a lot of the burden from execution-focused teams and saves them the time of planning when they could be executing.