John Egan

In product-led Growth, some of the biggest opportunities can require working across product boundaries and partnering with other teams. When collaboration goes well it can deliver big unlocks, help build a seamless user experience, and avoid the trap of your product reflecting your org structure. Collaboration not done well can cause friction, contention, and put a damper on future efforts to work together. Here are my five rules that Growth teams should follow to ensure happy and effective collaboration.

 

1) Come With The Problem, Not the Solution

When you have an idea for an experiment you want to run, the first rule when approaching another team is to start with the problem, not the solution. Avoid starting off by telling them what experiment you want to run right off the bat. While you may have ideas in mind, begin with the user problem you are trying to solve and work together with the other team to ideate potential solutions to that problem. The benefits of this is a) it will be perceived by the other team as more collaborative and open b) it encourages the other team who has more experience in that particular domain or product area to be more engaged in thinking about solutions rather than just approving/disapproving your experiment idea.

 

2) The Right of First Refusal

The right of first refusal is a concept in contracts. A classic example is when investing in stock in a private company, the stock agreement may have terms that give the company the right of first refusal when you sell the stock. This gives the company the right to decide if they want to purchase the stock back from you before you are allowed to sell the stock to a third party. The reason this exists is so the company can control the number of shareholders they have to avoid the rules and regulations that come with having more than 500 shareholders.

When it comes to collaboration, sometimes there can be contention over who does the work. I’ve found this idea of “right of first refusal” useful in helping ensure smooth collaboration. The idea is if the team that owns the product area you want to work on really wants to implement the idea themselves, go ahead and let them since you get the idea implemented and it frees you up to go work on other ideas. There are a number of good reasons the team that owns the product area may want to implement the idea themselves, such as a) they are concerned about the risk of something critical breaking, b) maybe they already had the same idea and had been promising it as a career development opportunity to someone on their team, etc. However, if the other team does take on the project, they need to explicitly commit to getting it done in a reasonable timeframe. My rule of thumb is that the timeframe should be no more than 4x the amount of time it would take to implement the project (ex: if it takes 1 week to implement, the other team should commit to getting it done in the next 4 weeks). If both teams agree that the experiment idea has merit, but the other team can’t commit to completing it within that time and your team has an engineer ready to work on it, it is hard to see a compelling argument for why the experiment should be substantially delayed when there is a team is willing to do the work now.

 

3) Pre-Align on What Success Looks Like for Controversial Experiments

Sometimes there are experiments in Growth that can involve tradeoffs between metrics impact vs. more qualitative aspects (ex: branding, user experience, etc). For instance, in 2016 Pinterest changed the “Pin it” button to say “Save” to help make the button better understood by a global audience. It was a seemingly simple change, there was some controversy because there was a lot of branding built into “Pin it” vs. “Save” which was more generic. I’ve found that for controversial experiments it is best to align on shipping criteria before the experiment is even launched. Waiting for the experiment results to come in before aligning on what bar the experiment needs to meet to ship it, people tend to stick to the biases they had for which variant they preferred. Pre-aligning on ship criteria before either side has any data leads to a much more principled conversation on the tradeoffs between metrics vs other qualitative aspects. Then once you have alignment you simply run the experiment and see if the results meet the bar for the pre-agreed upon shipping criteria.

 

4) Communicate, Communicate, Communicate

So you’ve reached the point where you’ve agreed on the experiment you want to implement and the shipping criteria and it is now time to go into execution mode. It is important to thoroughly communicate every step along the way to make sure the other team is well informed on what is happening. Let them know when your engineer starts working on the project, when the experiment is launching, when it is being ramped up, when it is shipping and include the other team on code reviews. Communicating every step of the way ensures there aren’t any unexpected surprises for the other team and can also reduce the risk of potentially having conflicting experiments live at the same time.

 

5) Cleanup After Yourself

The final rule is to be respectful of the other team’s code base and take the time to properly ship it or shut it down when the experiment is done. That means really being disciplined about writing unit tests, integration tests, documentation, implementing alerts, etc. if the experiment is being shipped, or deleting the code and confirming it is removed if the experiment is shut down.

 

To wrap up, every company culture is and can place different emphasis on quality, velocity, impact, collaboration, etc so use these five rules as a guide and adapt them in a way that makes sense for your company’s culture.