How to avoid a dysfunctional relationship between product and growth teams
How to avoid a dysfunctional relationship between product and growth teams
If your company has distinct product and growth teams, I’m willing to bet you’ve seen or felt something about their relationship that doesn’t quite sit right with you. What you’re sensing is dysfunction. It might not be catastrophic levels of dysfunction, but make no mistake, it's impacting your product growth and probably taking casualties along the way, with people on the teams feeling frustrated and adversarial.
On the other hand, the positive impact can be significant when product and growth teams work well together. Both teams can learn faster. Both teams can move faster. The product can grow faster.
Everyone wants that right? So why is this even a thing?
Sadly, I’ve found it’s rare for a company to avoid dysfunction between product and growth teams completely, and in practice, it often looks more like a spectrum - from harmony at one end of the scale to dysfunction at the other. In this post, I’ll help you learn how to identify and minimise that dysfunction.
Signs of a dysfunctional relationship
If you’re on (or leading) a product or growth team and hear any of these things being said, you know there’s an issue. The more of these things you hear, and the more often you hear them, the more you’re going to need to lean in to right the ship.
You might hear people in Growth say:
“Product doesn’t care about growth".”
“There’s not enough value in the product.”
“Another product change just invalidated our experiment.”
“Product doesn’t understand the importance of testing and experimentation.”
“Product has been blocking us from getting this experiment live for weeks.”
“Product is too slow and risk-averse.”
You might hear people in Product say:
“Growth is just optimisation.”
“Growth hands over poor quality code.”
“The value is there if Growth would just get people to see it.”
“Growth do things that aren’t scalable and won’t perform.”
“Growth is too focused on short-term gains.”
“Product could put those engineers/PMs/designers to much better use to build this important new thing.”
We are human. We’re individuals. We err. There will always be some dysfunction in any organisation. But there are a number of things you can do to help product and growth teams approach harmony.
Note: Even when you don't have high levels of dysfunction, instead there's often apathy and both teams kind of just getting on and doing their thing in isolation, which really leaves a big untapped opportunity. The goal is to have them working together well, not ignoring each other.
The path to harmony
Here’s how to set up your product and growth teams and their ways of working to minimise dysfunction and get them working together more harmoniously.
1. Organise to maintain cultural alignment.
Don’t isolate Growth teams on their own island. Have them be part of the same higher-level R&D organisation, and ensure they work on the same cadence as - or a cadence that frequently aligns with that of - product teams. Make sure product and growth teams have some key unifying ceremonies. The sprint demo was one of the most important meetings for nurturing cultural alignment and creating a sense of shared belonging for product and growth teams at Snyk. It also helped combat misconceptions about Growth by providing greater visibility into the work itself and the approach to that work. At the same time, when growth work was showcased there, it helped counter the absolution effect by normalising the work as being under the same umbrella as other product work.
2. Avoid the growth == marketing trap
In your PLG company, growth teams aren’t another name for the subset of the marketing team that is goaled on new user and/or lead acquisition. Nope. They are product teams ++.
Product teams are typically built with the holy trinity of PM, Design and Engineering. Growth teams have that same nucleus but extend it with Decision Scientists and (in B2B SaaS) Growth Marketing Managers.
If you have a growth team that is, in effect, a hamstrung marketing team unable to work on any product surfaces, then you’re building massive amounts of friction into the org between Product and ‘Growth’ who likely have different priorities and incentives. This was historically the case at Snyk before we created a truly cross-functional Growth team:
3. Build strategic alignment
The product and growth strategy can’t exist in isolation. They need to be synergistic, and everyone in the core product and growth teams needs an aligned understanding of both strategies and their interplay. It’s so important that Product and Growth teams understand how the work they do (and the work each other do) contributes to broader company growth, and the Product and Growth strategies should develop that alignment.
The growth model, the definition of your growth loops, and the user/team state model are all the basis of a common language between Product and Growth.
4. Build alignment around who you serve
What market(s) are you serving? Who is your Ideal Customer Profile (ICP)? Who are your users? What are their Jobs-To-Be-Done (JTBD)? PLG companies should make the user front and centre, and product and growth teams need to figure out how they can best support each other in solving user pain/problems.
Share all of this stuff. Collaborate on it. Evolve it together.
5. Align objectives
Even with aligned product and growth strategies, you can introduce a strong current of dysfunction that is hard to swim against if you don’t ensure both teams' respective objectives are aligned, and supporting those strategies.
It’s not about them working on the same objectives, but rather putting in place non-conflicting, complementary objectives that together help drive higher-level business outcomes.
I love to see product teams have accountability for feature-level engagement and retention (avoiding ‘ship it and move on’ and orienting instead around ‘ship, monitor success and react’). Measuring feature release success in the volume of adoption is a red flag.
6. Collaborate on product feature launches
Growth teams should have good advance visibility of what’s coming down the product pipeline and be able to consider how those new things might impact the growth model, and how they might leverage new features to drive growth.
Product teams shouldn’t plan in isolation. Make sure there is some Growth representation in the product planning processes.
7. Collaborate on growth experiments
Growth teams experimenting on surfaces they are not code owners for is a common need, and simultaneously a really common source of friction.
I’ve seen product teams become very territorial when it comes to growth teams working in their codebases.
The most effective way to counter this is for growth teams to actively involve product teams in the growth process from idea generation onwards. Of particular importance is collaborating on the experiment plan and scheduling. Not just asking product teams to review plans, but working with them to create the plans.
Unless product and growth teams collaborate closely in this way, there’s a high probability that you’ll encounter another issue whereby product teams inadvertently make changes on their product surfaces that invalidate live experiments, which understandably causes huge frustration within growth teams and deprives the whole org of learning opportunities.
8. Collaborate to define the process
Because growth teams are often working on code they don’t own, it goes a long way to have product and growth teams come together upfront and agree on some ground rules and ways of working.
You won’t want the same full set of coding standards to apply for code that, in all likelihood, will be thrown away, but agreeing on the subset of standards that should apply is important. Similarly, it’s good to have an agreed workflow around experiment cleanup, and internally agreed objectives for taking experiments and making them production ready.
It’s just bad form (and ultimately will end up causing end-user impact) to leave experimental implementations hanging around longer than needed.
Managing this as part of a broader cross-R&D strategy for technical debt is recommended.
9. Work with the same tools and data
The use of standardised tooling can give a big boost to how product and growth teams work together.
If it’s not happening already, improve the visibility of work by using the same planning and tracking tools.
There’s nothing that can create alignment quite like indisputable data about users, whether qualitative or quantitative. Provide a common base for product and growth work by leveraging the same tooling for behavioural analytics and experimentation. Have growth teams and product teams collaborate on user research.
If one of the teams trailblazes with new platforms, make it easy for other teams to follow and get on board. We did this at Snyk when we implemented our growth analytics and experimentation platform. The growth team, created training materials, documentation, easy-to-implement wrappers around SDKs, an event tracking style guide and set up supporting Slack channels where people could reach out for help.
10. Share learnings
Last but certainly not least, find ways for both teams to share learnings with each other and a wider set of stakeholders. A monthly Impact and Learnings review is a great way to formalise that, but the exchange of knowledge and learnings should be happening very fluidly and dynamically on an ongoing basis day to day.
Teams should always ask themselves, “Who else might this learning be useful to?”
Learn. Share. Learn. Share. Learn. Share. Do it over and over again.
Repetition never spoilt the prayer.
If you’ve found any other ways to help product and growth teams get to a 2+2=5 situation, I’d love to hear from you. Drop me a line at ben@plgeek.com.
1 interesting listen:
Patrick Campbell on the right culture for your company on BUILD with Blake Bartlett
3 interesting reads:
Adam Fishman on Parenting while producting
Varun Parmar on How Miro builds product on Lenny’s Newsletter (note this is a paid edition, but it’s content like this that makes a subscription a no-brainer)
Christine Itwaru on Cognitive bias in PMs and product teams