The 30/90 Principle

The 30/90 Principle

Why is Growth Engineering so different than Product Engineering?

Code that Product Engineers ship has a 90% chance of being around a year later.

Code that Growth Engineers ship has a 30% chance of being around a year later.

This is the 30/90 Principle. It has some pretty major implications about how to get work done.

First of all, moving to Growth is not an invitation to abandon indentation and use single letter variable names.

Instead, working on a 30% team means being thoughtful about the trade-offs and shortcuts worth taking. ?Coming from a Core Product team, developers will have honed a speed-vs-quality trade-off that will need to shift. Growth is a whole new ball game.

What kind of practices do growth engineers use to balance code quality with speed? Things like:

• keep “non-experiment” code at a high quality bar, but be more lenient with experiment code
• for most smaller experiments, keep the experiment itself in a single PR, making cleanup as simple as a revert
• when taking a shortcut, explicitly document the post-experiment cleanup plan before shipping?

The 30% mindset takes a while to internalize, making the Product to Growth adjustment rough for many engineers. ?One way to help smooth the transition is, of course, to ????enroll in my Growth Engineering Course @ Reforge, starting April 23????!?

PS. As far as I can remember, I learned the 30/90 principle from Gagan Biyani, though he attributed it to Naval Ravikant.