One of the biggest challenges, especially with small development teams, is figuring out how much emphasis to allocate to product engineering (e.g., new functionality, features, or usability improvements) vs. growth engineering (increasing the user base). And to make the right decision, you need to understand the differences between both engineerings. To make your job easier, we share the comparison below.

The Differences

Growth Engineering and product engineering have different yet interrelated goals in mind. Product engineering teams focus more on the creation and improvement of a core product offering.

Each team works on strategic bets that product requirements drive. These bets are primarily based on market and customer demand. There is a set of backlog expected product changes. Product engineers focus on a mix of operational improvements and delivery engineering.

On the other hand, growth engineering teams focus on opportunity discovery and incremental learning. Growth engineers concentrate on discovering and unlocking customer value in existing product offerings.

Product engineers answer questions about:

● What are the customers’ needs?

● What product should be built to meet the market demand?

● What features should be introduced next as per strategy?

Growth Engineers answer questions about:

● What features do not appeal to users, or do they struggle to discover? And what’s the solution?

● Why are users leaving?

Product engineers build a product for the market fit. Growth engineers try to learn the current products are performing and being used. They focus on the health of the user journey to make sure it doesn’t degrade. They focus on the holistic user journey outside and between products. They try to figure out opportunities to create a measurable impact. Then they make incremental amendments to unlock them.

Growth Engineering teams work on different elements of the user journey. Some growth engineers focus on product adoption and expanding the user base. Other teams focus on product simplification and help guide users to explore underutilized product functionality.

User journey optimization can be complicated. Growth engineers run experiments that differ from the existing product experience; then, they analyze those amendments to evaluate if they make the improvements as expected.

Maintaining Separate Product and Growth Roadmaps

Not every company has a dedicated team for growth engineering, but this approach has many advantages.

However, it’s recommended even the small teams should maintain a growth roadmap and keep it separate from the product roadmap. They should separate growth activities into a separate workstream to take up impact-focused initiatives instead of other key product considerations such as usability, stability, functionality, etc.

Small-sized teams may not have enough resources to build, test, and iterate on growth initiatives in parallel with product features, making prioritizing growth vs. core product development more critical.

Growth is an iterative process. Although some growth gains are easily achievable by inserting an occasional growth story into an otherwise core-product-focused roadmap, gains will be occasional, and there will be limitations to the learning (due to the sluggish part of iterative improvement), and progress could be extremely slow.

There are no clear-cut solutions or answers to the growth vs. product effort dilemma, and ultimately the IT leaders make the final decision based on business goals and available resources.

If the setup is correct, growth engineering efforts can run parallel to some extent, such that learning and iteration can happen even the engineering resources are unavailable.

Some activities in the stack, such as acquisition, may not require engineering resources. Performance marketing, community engagement, and others should be executed by non-engineers, though they may need 3rd party tool integration, bespoke product ‘hooks,’ additional analytics tracking to improve effectiveness. Companies can run on many fronts without having a dedicated team for growth engineering, but there is no antidote.

Growth sits at the intersection of marketing and product. The real magic happens when design, statistical analysis, engineering, and marketing efforts are allocated to growth problems holistically.

Job title and team structure do not hold any importance when it comes to adopting a growth philosophy and process that values, experimentation, data, and a drive for impact stay above all.

So, do you have any questions about the differences between growth engineering and product engineering? Please feel free to leave your comments below.