Growth Teams Must Have Aggressive Parallel Execution

Who is the most aggressive person in your company, driving the hardest to hit your goals?

They say the most aggressive person should be the head of growth, with #2 being the CEO. Growth teams should be so aggressive and autonomous that the only person reeling them in is the CEO.

Your company picks a goal and knows how to move the needle by building a map of the product, analytics, and marketing. You come up with new ideas and triage by cost, benefit, and risk. Next comes execution. Execution needs to be aggressive and parallelized to drive as much learning and experimentation as possible. It’s a race for your life — your startup’s life.

So how do you do it? This is actually a question about how you organize your teams. It’s a question of company culture. We’ll explore these ideas in this post.

Growth Team vs Growth Managers

Should you have a growth team? Or should you have people responsible for growth on individual teams?

For a small startup, the answer is easy: the CEO is the head of growth. You need to know you metrics inside and out. You need to understand the strategy to get traction, and you’re probably the one executing on that mission. You need to deeply care about your customers and understand what makes them tick.

What about larger organizations? The answer isn’t obvious and it probably depends on how your current company is organized.

If there is a dedicated growth team, who triages the product roadmap for other teams? What rubric is used in that triage if not hitting some clear objective? Who owns the metrics?

If you have individual members responsible for growth, how do you test bold new growth ideas that take dedicated resources? How are lessons learned shared across your organization?

When designing the shape of your company, the important part is understanding these tradeoffs and making your objectives clear. You should experiment with changes that fit your company and see what works best.

In-House Growth Consulting

If I were joining a new company without a strong focus on growth, where might I start?

I’d go to every other team and ask two basic questions:

1- What are you working on?

2- What do you think will happen when that launches?

It’s shocking how many companies don’t ask such basic questions. There are a myriad of excuses — maybe focusing on quality over performance. Maybe thinking that a lack of corollary makes predicting the future hard.

Call this out. Prediction is hard, but that’s no excuse.

Going through a product development cycle with these questions in mind gets a company on the right track. After a launch, did things go as expected? Why not? What did we learn? What can you do next time? How can we organize our team in a way to deliver better results? If that worked, what can we do more to double down?

This is how a growth team thinks. Start by asking your product leaders some basic performance focused questions and keeping score.

Analytics Life Blood

Growth teams must make informed decisions to win. Early on, this might be qualitative data from talking to customers. At larger scale, aggregate behavioral data speaks volumes.

How are questions answered in your company? Put aside the mechanics, though they do matter. This isn’t about your analytics tech stack. If someone on your team has a product question, what do they need to do to get an answer?

Can they get an answer themselves? Do they need to be in good graces with Bob running the analytics servers? Do they need to know SQL? How are questions triaged? How are answers shared?

Build an organization where the cost of asking questions is as low as possible. Friction means some questions just won’t get asked and you’re on track to building a culture where data, even anecdotal from customers, isn’t needed to make decisions.

I’ve seen different organizations deal with this in different ways. Certainly there are instrumentation and exploration tools that can be bought or built to enable teams to answer questions. The collaborative side to these tools is the most interesting.

Dropbox at one point built a system jokingly called Coura. It was simple: ask a analytics question and say why you want to know the answer. When someone was ready to work on it, the system asked if the information was still needed. Anyone could see the other questions asked and their answers. Engineers were confident that the work they’d do to run an analysis was always needed and impactful.

At another company I helped, they built a system for managing complex queries over large data sets. One interesting byproduct was the ability to see the queries others were asking. This become an onboarding tool for product analysts. It wasn’t treated as such, but the teaching and sharing power was incredible.

Such social tools within organizations aren’t developed enough.

There are many vendors selling analytics tools and and business intelligence solutions. Their sales process and user interface distract you from the main issue in deciding what to use:

Product Needs Drive Analytics

Way too often, product teams dig into analytics tools and try to learn what the hell is going on with their product.

This is backwards. You need to start asking questions from the product side and answer in whatever way is possible. This often means writing custom code to get a real answer. This often means adding a new tool to slice and dice your data, or connect multiple data sources together.

Starting from the tool and working through questions doesn’t work well. The reason is that tools are general and not designed specifically for your company. They have a language, and not knowing your dialect means you don’t even think to ask your questions when you start from the tool.

For example, Google Analytics is very focused on pageviews. It doesn’t focus on users and their actions. If you started with GA, you’d be asking the wrong questions and working towards the wrong goals. If you focused on your product and users, you might then instrument the product with something like Mixpanel, and focus on what is really going on.

But even Mixpanel has some strong opinions. They are great at funnels and events. But if you launch a new feature and want to know how that affects retention, their cohort analysis tools aren’t as strong as Amplitude, an upstart analytics tool that focuses a lot more on cohorts.

Whatever the tool, the point is that you should focus on what is really going on with your customers and your product. Trying to understand that will yield questions that some tools can answer and others can’t.

Company Wide Performance Sharing

Some companies are really tight lipped when it comes to performance and revenue. The tide is turning here because there are huge benefits to sharing this information.

One of the easiest ways of building a more data focused product culture is to share performance data.

Dropbox did this with a daily metrics email. They built an in house metrics dashboard, and then took a daily snapshot and emailed it to everyone in the company. They included investors as well.

This has a huge impact on a company because you make what you measure. If you are measuring and sharing growth numbers, everyone in the company will internalize and represent those goals in their work.

This focus on performance was pervasive at Facebook. The whole company understood for years that the goal was to get everyone in the world on Facebook.

Product Specs Run Like Experiments

After you’ve triaged your growth, my specific tactical advice is to run each task as an experiment. You don’t need a PhD — just treat it like a 4th grade science experiment. Write down what you think will happen — something measurable that you can look at after the experiment. This is often a specific metric you hope to improve.

It’s crucial to reflect back on why your hypothesis was right or wrong. Digging into this helps you learn about your product and customers and informs your future product roadmap. We’ll cover this idea more in our next post about growth.

I really like the framework that Brian Balfour has put together here. Check out his talk here about how to run this experimental progress.

Putting It All Together

This is the fourth post in a series about growth. Subscribe here to get the next post right in your inbox.

1-  Pick a Goal

2- Map your Product to your Goal

3- Triage by Cost, Benefit, and Risk

4- Aggressive Parallel Execution (hello there!)

5- Keep Score (coming soon)

We’re also putting together a class on growth which covers this whole process and more. This will launch in a few weeks, so subscribe to learn more.