2. Building relationships with other teams

As a growth designer, working well with other disciplines on your team is important, but it’s not enough. A unique challenge that growth teams face is that they don’t own surfaces, they own experiences. That means that growth teams need to cultivate relationships with those other teams on whose surfaces they’re running experiments.

For example, on Paper growth, we recently ran an experiment where we added education about Paper in Dropbox onboarding. To do that, it was important to have a good relationship with the team working on Dropbox onboarding.

Communicating the value of a certain experiment to other teams can be tricky. One way we approach this on Paper growth is that we try to find common ground based on shared goals that our teams have. And the way to do that is to focus on the business and on the user.

• On the business side, to find shared goals, we try to align on high level goals that our organization or company has.
• On the user side, we focus on user problems. If our experiment is addressing a user problem on the surface owned by another team, that team will be very happy to work with us to solve that problem.

II. Move fast, don’t break things

Having great processes for working cross-functionally gets you halfway there in creating an effective growth team. Working well is important, but you also need to work fast.

A growth team that takes a very long time to launch experiments is unlikely to have a good fate, for two reasons:

• First, growth teams have very clear metrics they try to improve. If those metrics don’t move, it’s obvious quickly that something isn’t working.
• Furthermore, product growth is, almost always, an immediate priority for the business. If a growth team doesn’t deliver on that, there’s something wrong either with the product / the target market, or with the growth team bringing that product to market.

So, there is another important dimension to consider in building a growth team. And that is how you enable the team to move at high velocity, while maintaining a high bar for shipping designs of great quality.

1. How to move fast

On Paper, we realized that if we wanted to learn from our users through experimentation, we needed to speed up our iteration cycles. Since we wanted to move fast, but also ship great experiences, that raised the question of how much polish we should put in each experiment. To answer that, we decided that instead of the MVP — the minimally viable product, we wanted to build the MPP — the minimally proud product. That means that we try to move as fast as possible to ship; but, when we launch something, we want to be able to answer with “Yes!” to two questions:

• Am I, as a growth designer, proud of the user experience that was shipped?
• On the engineering side: is the engineer proud of what she/he shipped?

Since there’s obvious subjectivity in what makes one proud, we also decided on some objective things that are needed to ship an experiment — a set of shared principles for experimental quality. We all agree that experiments don’t have to be 100% polished. But they should be an experience that with a little bit more polish would be something ready to ship to all users.

Experiments should be good enough to test our hypotheses and learn, and almost good enough to ship to everyone.