Why Growth Engineering Practices Don't Transfer to Product Engineering

Any time I write about growth engineering on the internet, I end up with comments like these:

If all of these Growth Eng practices lead to high-velocity, high-impact teams, shouldn’t we all be running our Product teams the way we run Growth?

Short answer: no.

Should marathoner runners train like sprinters? While there are probably some interesting cross-training opportunities, the two are fundamentally different.

The same is true for Growth vs Product Engineering. Forcing Growth practices upon Product Engineers will neither improve your velocity nor your product quality.

Here’s what goes wrong:

1. Product Teams would give up features early

If a movie studio makes 10 trailers but then only uses the 3 that performed best, that’s a best practice. If they scrap an entirely-finished movie, that’s a tragedy tax write-off.

Growth Engineering teams throw away failed experiments all the time, but shutting down a feature that’s already live generally does not go over well. Product Engineers need conviction in their ideas the same way Growth Engineers need to be willing to kill your darlings.

2. The codebase would become an unholy mess.

Growth Engineers go fast by cutting corners. If Product Engineering took a similar “we’ll make it nice when it wins” approach, the team would drown in tech debt almost immediately.

This is because, compared to Growth,

1. There are more Product Engineers, so there’d be more “temporary code”
2. Product surfaces are more complicated, compounding the tech debt
3. Product features are bigger and take longer to build, making the “temporary code” last longer

Development would grind to a halt. Growth gets away with it, and even then barely.

3. Stuff would break more often, and it would be a big deal.

A product outage is breaking news.

I have yet to see an equivalent article for “Thousands Reported Issues with Slack.com marketing site.”

The reliability bar is higher for a product with paying users. That’s why working more methodically makes sense. If a Core Product had as many small incidents as a Growth team, they’re liable to get some upset customers.

Cross Training: What Product teams can take from Growth Engineering

As we’ve seen, a wholesale adoption of Growth practices wouldn’t work. So then, which ideas are worth emulating?

1. Emphasize the Business Metric Many Core Product Engineers treat business metrics as an afterthought. Go over key metrics at the team’s weekly meeting to help the team focus on their team’s mission.

2. Quantify your rollouts via Feature Flags Feature flags are just a good idea. Rolling out slowly both reduces anxiety and helps quantify impact.

3. Interdisciplinary Engineers Strong Growth Engineers tend to be well-rounded, with a combination of product sense, analytics, user behavior, and statistics. As everyday coding becomes commoditized, Product Engineers will need to invest in similarly broadening their skillsets.

…if only there was a class for that 😉.

Tags: #growth engineering #culture #advice-for-engineer