# Growth Engineering vs Product Engineering

- Link: https://phiture.com/mobilegrowthstack/growth-engineering-vs-product-engineering-f37fd37f095c/
- Published: 2017-02-04T17:21:05+01:00
- Author: Andy Carvell

![Growth Engineering vs Product Engineering ](https://phiture.com/wp-content/uploads/
2017/02/Growth-Engineering-vs-Product-Engineering-min.jpeg)

One tough challenge, especially with small teams, is deciding how much emphasis 
to allocate to product (e.g. new features, functionality or usability improvements)
vs growth (sustainably growing the active user base), especially when it comes to
engineering resources, which are usually the scarcest and most expensive to deploy.

_Maintain separate Product and Growth roadmaps_

It’s not necessary for a company to have a dedicated growth team, though there are
definitely advantages to this approach. What is definitely recommended, however,
even for small teams, is to maintain a growth roadmap, separate from the product
roadmap; separating growth activities into a separate workstream helps keep these
initiatives focused on _impact_ (as evidenced by metrics and statistically-significant
experiment results) as opposed to other key product considerations such as functionality,
usability, stability, etc.

Small, early-stage teams may not have enough resources to build, test and iterate
on growth initiatives in parallel with product features, which may necessitate prioritization
of growth vs core product and lead to one of them taking a back seat for one or 
more product iterations. This is suboptimal for both, since growth is an iterative
process. While it’s certainly possible to achieve some growth gains by inserting
an occasional growth story into an otherwise core-product-focused roadmap, gains
will be sporadic, learning will be limited (due to the slow pace of iterative improvement)
and progress with be frustratingly slow.

There are no easy solutions to the product-vs-growth effort dilemma and ultimately
the leadership must make tough judgment calls based on available resources and business
goals. With the right set up, growth marketing efforts can be parallelized to some
extent, such that iteration and learning can happen even when engineering resources
are not available.

Some activities in the stack — particularly, but not exclusively, in the acquisition
layer — do not require engineering resources. Content, Lifecycle and Performance
marketing programs, Community Engagement and others can be executed by non-engineers
in parallel to engineering tasks, though may require integration of 3rd party tools,
additional analytics tracking, or bespoke product ‘hooks’ in order to maximize their
effectiveness. It’s possible to get moving on many fronts without dedicated growth
engineering resources, but there is no panacea.

Growth, by definition, sits at the intersection of product and marketing. The real
magic happens when engineering, design, statistical analysis and marketing efforts
are applied to growth problems in a holistic way. Team structure and job titles 
are far less important than the adoption of a growth philosophy and process that
values data, experimentation and a drive for impact above all else.