What is a Growth Engineer?

Early in their career most software engineers are often exploring a bunch of different and exciting programming languages, jumping to the hottest technologies and learning the newest frameworks. At some point after a few years of experience, most people end up specializing in specific frameworks and languages, whereas others maintain a wide range of skills and become full-stack engineers.

Similarly, Growth Engineers are engineers who expand their range of skills beyond engineering and technology and develop cross-functional skills including Product, UX Design, Data & Analytics and Marketing. In fact, Growth Engineers are some of the most versatile engineers in the industry.

‍

‍

But what exactly do Growth Engineers do? To answer that, first we need to understand what Growth is and how Growth teams operate:

1. What is Product Growth?
2. How do Growth teams operate?
3. What do Growth Engineers do?

What is Product Growth?

First let’s clarify what Product Growth is not:

• A/B testing dozens of different colors for a button
• Spamming users with a ton of notifications hoping to increase engagement
• Tricking users into purchasing more expensive subscriptions
• “Growth at all costs"

Even though it’s certain that big tech companies are hyper-optimizing every single aspect of their products, that’s usually not the case for the majority of small/medium size companies that most likely don’t even have enough traffic to run experiments such as finding the perfect shade of blue for their buttons or the perfect ratio between white space and content. Furthermore, these types of optimizations only cover a fraction of what Growth work is about.

In fact, when talking about Growth we can consider a spectrum of different types of work. On one side we have what I think of as the functional part of Growth work: optimizing a home page, a signup flow, a checkout experience, to be more functional, to have less friction, to be more focused and therefore to make it easier to use, with the goal of increasing conversion rate (# of visitors / # of visitors who perform a certain action - such as sign up, subscribe, purchase, or simply continue using your product).

On the other side of the spectrum there is what I consider to be the systematic part of Growth work, which first of all consists in having a deeper understanding of your users, of what motivates them, of how they use your product and why, of what makes them successful or unsuccessful when doing so. With a deeper understanding of your users come a lot of ideas and hypotheses of how certain changes to the product / UX will positively impact users and make them more successful with your product, and therefore more likely to stick around, engage, convert more and help you grow your business systematically.

Functional Growth work is about finding the local maximum on an existing user experience, whereas systematic Growth work is about seeking a greater understanding of your target users in order to make their experience fundamentally better and achieve systematic business growth.

Product Growth is very user centric, but at the same time it’s very tied to business outcomes. Growth teams’ success is measured by their ability to move metrics such as activation, retention and monetization. However, such metrics are in fact a proxy of how good their product is and how successful their users are using it. Therefore the ultimate goal of Growth teams is to make their users successful using their product. In fact, so successful that they’ll pay for it and they’ll keep on using it.

‍

How do Growth teams operate?

What usually differentiates Growth teams from other product teams is the way they operate. Depending on the stage of the company, the Growth function could be more or less mature. Most companies start with a small Growth team (e.g. 1 PM, 1 designer and 2-3 engineers) that can evolve into multiple teams/pods all working on different parts of the user journey (aka. the funnel): acquisition, activation, engagement, monetization, retention.

Growth teams usually start by identifying user pain points and areas of opportunity, combining insights from qualitative research and quantitative data. Areas of opportunity are prioritized based on their size: how big of a problem it is and how many users are affected by it. The team then brainstorms and discusses a bunch of ideas and solutions, which are prioritized based on effort estimates and expected impact (a common prioritization framework is ICE).

So far nothing is unusual and most product teams go through similar steps when deciding what features to work on. However, what usually sets Growth teams apart is that once they come up with a list of ideas, they don’t go ahead and build them right away. Instead they start by validating their hypothesis in an iterative approach.

‍

Ideas are often broken down into the smallest unit that can be tested, in order to validate a specific assumption and de-risk it early in the process. The team might build prototypes and do user interviews to gather quick feedback that will help them iterate on their original idea (or sometimes event discard it). 

Then come the experiments and A/B tests in production to gather real users data and statistically measure how the new solution performs against the current experience. For each A/B test they set specific metrics to measure success (e.g. signup rate, 1 week retention rate, etc.). By A/B testing their ideas Growth teams not only validate that they’re actually solving the user problems, but also they gather more learnings and insights, which help them iterate again or come up with new ideas to test.

In short, Growth teams operate with an iterative and hypothesis-driven approach, in a fast-paced environment, making heavy use of prototypes and experimentation to measure their success and gather learnings that generate new hypotheses and ideas, with the goal of moving business metrics that are a proxy to users’ success.

‍

What do Growth Engineers do?

Now that we clarified what Growth teams work on, let’s take a look at what Growth Engineers do and what responsibilities they have.

Growth Engineers are usually very involved with Product and Design early in the process. They usually align on customer problems and desired business outcomes, participate in solution brainstormings, come up with hypothesis and experiment ideas, evaluate feasibility of different ideas and help prioritize, give feedback on designs, propose alternative solutions and share ownership.

When it comes to actual development, Growth engineers are usually building prototypes or A/B tests and then cleaning up tech debt or productizing solutions after experiments are over. In fact, because of the nature of how Growth teams operate, the majority of code Growth engineers write is thrown away very quickly. With this in mind, Growth Engineers are often looking for the right tradeoffs between speed and quality. They usually stray away from over-engineered solutions and premature optimizations and abstractions until they’re more certain that what they’re building is there to stay.

Growth Engineers are also very familiar with analytics and they make sure the right tracking is in place in order to analyze experiment results. They’re usually comfortable digging into the data, creating funnels and dashboards and coming up with insights (even though it’s usually not their responsibility).

Depending on how mature the Growth function is in a company, Growth Engineers might need to build and maintain an in-house A/B testing framework, or integrate third-party services. Usually when a company scales a dedicated infra team or data engineering team might own the A/B testing framework instead.

Sometimes Growth Engineers collaborate with Marketing and Sales on various initiatives such as SEO, leads generation and email campaigns.

Overall, Growth Engineers have a strong interest in Product and in measuring the impact of their work on user success and business outcomes. They thrive working in a fast-paced environment with an experimentation-driven and customer-centric approach. They work closely with their cross-functional teammates (Product, Design, Data) and have good communication skills. They’re not attached to their code and they’re great at making tradeoffs. They value solving real customer problems over complex technical challenges.

‍

Becoming a Growth Engineer

If you haven’t worked on a Growth team before and you’re considering joining one, the question you should be asking yourself is whether you resonate or not with the way Growth teams operate and what they work on. Do you want to have a say in what you’re building and why, instead of only defining how? Then joining a Growth team will give you lots of opportunities to build up your Product strategy muscles. Do you like working in a data-driven environment where the impact of what you do is measurable and decisions are made based on quantitative insights rather than gut feelings? Then you’ll enjoy working in Growth. Does working on complex technical challenges excites you more than solving real-life customer problems? Then maybe Growth is not the right fit for you.

Whether you’ll join a Growth team or not, hopefully now you have a better understanding of what Growth teams and Growth Engineers do.