Bottoms-Up: How the Pinterest growth team decentralizes its structure

Neeraj Chandra | Growth engineering

On the growth team at Pinterest, we describe our structure as “bottoms-up”, meaning ideas and responsibilities flow throughout the team in a way that provides a lot of autonomy to work on the projects each person wants to tackle, across a variety of roles. The result is a team that is very scalable and flexible. And it means that each of us on the team has a lot of liberty to choose how we spend our time.

How this approach works

Ultimately, my main priority is to build experiences that help contribute to the acquisition, activation, and retention of users, which is also the mechanism by which our team is evaluated.

Specifically, my team focuses on user conversion, and in the context of Pinterest, that means showing the value of Pinterest to prospective users and converting them into active users. To do so, we come up with ideas for improvements, build and launch experiments to measure the change, and analyze results. If the experiment contributed a valuable increase, we ship the experiment to users. Conversely, if the experiment had no impact on the growth funnel or negatively contributed to user growth, we shut it down, remove the experiment, and analyze the results to learn and improve. Our team runs hundreds of experiments per quarter, so in order to accurately measure the impact of a specific experiment, we randomly bucket the population into control and experiment groups.

To run so many experiments, our team is constantly searching for new ideas. We don’t believe that idea generation should belong only to one person; instead the entire team is responsible. We regularly spend time brainstorming and evaluating new ideas. Anyone can pitch an idea to the team to receive feedback, and if the idea holds up it gets moved into the backlog. Part of demonstrating that an idea is worthy is showing there is enough of an opportunity, and so we must also explain why the idea is important and large enough to work on.

In a similar fashion, the responsibility to analyze results also falls to each team member. We’ve built an experimentation framework that calculates and aggregates key metrics, but often times we need to dig further to understand user behavior. And so, a key part of my job is to utilize our data tools to construct queries and analyze the results of an experiment. While I can certainly receive help if needed, it’s expected that I drive the analysis and help complete our understanding of Pinners.

A side benefit of everyone being engaged in the analysis is we’re always thinking about the type of data and logs needed in advance of any new experiment. Because we all have experience using logs to answer questions, additional input throughout the development process can only make us better.

Why we do it

At this point, you might be wondering why we’ve organized ourselves in such a way. We still have some specialization, to be sure, but on the whole it’s a much looser structure. Why have everyone spend time on generating ideas and analyzing results?

This particular structure is ideal for us given the nature of our work, as it allows us to focus on the hard problems, remain scalable and flexible, and encourage our own growth.

Some additional key reasons:

• Make the right decisions quickly. Team input enables us to move faster in the development of high quality ideas so that we can focus on solving the right problems. If we pick the wrong project to work on, it doesn’t matter how efficient we are at development and analysis, for the entire idea is likely to have poor results and be shut down. By including everyone in the process, we can generate more solutions to our problems and incorporate a wider diversity of perspectives. In addition to coming up with ideas that solve a user problem, it’s also important to estimate the potential impact of any opportunity, so that we can prioritize accordingly. Predicting the expected impact from a new project can be difficult for just one person to do, but by having the entire team involved we can hold each other accountable and arrive at a more objective and rigorous result. In practice, this means that we have a weekly meeting where individuals pitch the team on any ideas they have. As a team, we discuss each idea for its merits and its potential opportunity, and then use that to shape our prioritization.
• Adjust to focus on the current problems. By involving everyone in each part of the process, we remain flexible and scalable. If our team is low on ideas, we can all shift our focus for the week to generating new ones. If we have a healthy backlog of ideas, we prioritize developing those ideas and launching experiments. If we need to analyze ongoing experiments, we can each perform the necessary analysis to arrive at a conclusion.The result is we can adjust to solve the current problems, regardless of where they are in our process; we can also easily onboard new members without changing our process.
• New ideas lead to professional development. Finally, each of us can learn and grow by being exposed to the different parts of the process. I personally find this to be really exciting, because I get to be involved in generating ideas, prioritizing work, developing experiments, and analyzing results. Each of these requires a different set of skills, and as the nature of my work shifts or my interests change, I can adjust accordingly. Since joining the team, I’ve gotten better at each of these things. I’ve improved my ability to come up with ideas for consideration, and I’ve improved my ability to dig deep into data analysis. Getting better at one part of the process helps me with the other parts too. For example, by becoming more familiar with analyzing experiments, I can incorporate better logs during development, and by becoming better at generating ideas, I can understand what questions to answer during analysis. It also means that, in addition to building new experiences, I get to think about the larger problem of user acquisition and activation. This is great for me and great for the business; with each of us learning more about user growth, we can in turn contribute better and higher-impact ideas, while ensuring our teams move at a fast pace.

What the approach requires

This bottoms-up approach may not work for every team. Because we tend to build smaller initiatives to test our hypotheses, before committing to larger efforts, we’re constantly having to ideate, adapt and learn. Consequently, our team benefits tremendously from our flexible nature and focus on ideation. The entire team, to its credit, has also really embraced this mentality, and it’s so exciting to see everyone adopt a curious mindset and consider new opportunities.

Through refinement, we’ve found success making the bottoms-up approach work for us. But how does it work for management?

I asked Ludo Antonov, the head of growth engineering at Pinterest, about his thoughts on this approach and why he helped structure the team this way. This is what he told me:

“I love ‘bottoms-up’ and decentralized teams because it allows everyone on the team to feel ownership over the product and the company. It encourages various functions such as design, marketing, engineering, and product to come together and learn from each other’s perspective and build a world class product. I always say that we should strive for the people that spend the most of their personal time on turning an idea into reality to have the most say in its direction. This leads to a much higher quality of execution and happiness of the team, while fostering learning and excellence.

I get ecstatic when I see engineers, designers or marketers propose radically different ideas than what we have in the product today and channel that passion into making these ideas successful. In that sense, I think of anyone in a leadership position on the team (myself included) as being an advisor to them, guiding and enabling them in that process of creating value. My favorite part is that when I have ideas that I think we should build, I know that the team is empowered to say ‘no’ to me. Thus, I know that when we actually get aligned on building something, it is because they believe it’s worth their time and will make the team and the product more successful, versus building things because of a leader’s opinion.”

Tying it all together

In the end, our team has found success with a bottoms-up culture. It’s encouraged each of us to take ownership over our domain while generating a healthy diversity of ideas. Being able to test my own ideas is incredibly empowering too — there’s no substitute for trying out an idea and seeing how it actually performs. What I enjoy most is being able to spend time throughout my day thinking about our strategy and coming up with new ideas, and then turning those ideas into reality. I get to be a part of the bigger conversations, and it’s an incredible opportunity to have influence on a product that over 250 million people use each month.

Thanks to Brian Lee, Ludo Antonov, Hayder Casey, and Jeff Chang for their help with this post!