The most important thing Dropbox did to scale Product Management

[

](https://medium.com/@slynch?source=post_page-----fed90e30697e--------------------------------)

These opinions are entirely my own, distilled from my experience at Dropbox in 2012–2015 as well as working with other startups. Since it’s been a few years, I’m sure Dropbox and their process look quite a bit different now.

I spent a lot of time in 2016 doing mentoring, advising, and consulting. Many conversations revolved around building product management teams, and through those conversations, I’ve got to reflect on the lessons I’ve learned from past PM roles. Some of those lessons are common sense and shared across most tech companies I’ve talked with. Others aren’t as obvious.

For me, one of the most valuable experiences was seeing Dropbox rapidly scale (both in customers and employee size), and witnessing all the issues that arise as those numbers increase. Today, I want to talk through the framework we developed for keeping the growing company on the same page through the product development process.

First, some context

For most of my tenure at Dropbox, the product team was led by our cofounder and CTO. He was deeply involved with all aspects of product development, including engineering and design as well as product management. In the early days, he reviewed nearly every product decision. To say he was busy is an understatement, but it worked when our team was relatively small.

But the company started growing like crazy and we started working on a lot more projects in parallel. By early 2014, we had a problem.

There are only so many hours in a day and all of our CTO’s time was booked solid. It was hard for PMs to get time with him for the feedback and approvals they needed. Things started to feel sluggish and then deadlocked. It wasn’t clear when he should be involved, what he actually needed to review, and what feedback would be helpful. PMs started trying to work around the process, and leadership got out of sync with what teams were doing. Everyone became frustrated.

To address the problem, fellow PM Anand Subramani (who now runs product at Pilot, go work with him!), proposed a simple framework for labeling the phases of a project’s lifecycle. Each of the three phases had a review associated with it, designed to answer a specific question:

Phase 0 — What is the problem we’re solving? Why is it worth solving?

Phase 1 — How are we going to solve that problem?

Phase 2 — What does our solution look like?

To be clear, I’m not advocating that this specific framework is the perfect one for every project or company, and we weren’t dogmatic about following it to the letter either. There were times when teams would combine Phase 0 and Phase 1 for smaller project or do multiple reviews in Phase 2 as they approached a launch. There’s also value to a post-launch iteration to review goals and look for opportunities to improve.

The value wasn’t in this specific incarnation. Instead, the most valuable part of the framework was three subtle but critical features that you should keep in mind as you define yours:

1. Clarified the right questions to ask and feedback to provide to a given project.

One of Dropbox’s core values is Sweat the Details. In reviewing a product, there’s a lot of details to sweat and depending on whether the product is in its development, they may not be the right ones. The framework defined shared expectations of what to focus on, at any given time.

For example, before this framework, it was common to ask questions about the phrasing of text in wireframes. Having the framework in place made it obvious when a project was too early for that sort of feedback, but also gave leadership comfort that the project would return for that level of feedback when that phase was reached.

Almost immediately after its introduction, reviewers began to self-critique saying “Oops, I’m giving phase 2 feedback in a phase 0, my bad”.

2. Separated getting agreement on the problem from getting agreement on the solution.

It’s hard for me overstate the importance of getting agreement on the problem you’re trying to solve before beginning work on the solution, particularly once there are many stakeholders from different parts of the business.

Without this, it was common to see projects get late into development, only to have the development process slow to a crawl as the stakeholders disagree on whether the product being built was actually the right thing to launch. This was because stakeholders weren’t on the same page as to what the real problem was.

By defining that and getting agreement before proceeding, teams could move forward with much greater confidence that they were working on the right thing.

3. So simple that it could be adopted by the entire company.

The core lesson here is how important concise and consistent communication is in getting a large team to work efficiently together.

The shared terminology allowed everyone at the company to immediately understand where a project was in its lifecycle. Engineering knew how much and how urgently a team needed staffing, support knew when a project would start impacting customers, and the marketing team knew when it was too early to put together marketing material because there would still be too much change in the project.

In fact, we actually attempted to do a redesign of this framework to address some issues (for example: there could be an additional phase for launch or post-launch iteration). The first attempt at redesigning introduced a new concepts, which made it harder to understand. The additional complexity prevented the redesign from replacing the first definition.