Growth by the numbers
August 28th, 2017
It’s best to define a job by the projects and their results. Projects vary by company, but results are generalizable across businesses (especially SaaS).
Everyone in the business should be focused on growth (both in market share and revenue), but as an organization grows and divides into functions, each function focuses on its own priorities.
- Product biases towards new product development.
- Engineering biases towards the health of the code and application.
- Design biases on usability and brand.
- Sales biases towards revenue, specifically sales revenue.
- Marketing biases towards market mindshare and attention.
Growth engineering sits within engineering, but its focus is on customers. This tends to mean growth engineering is seen by the rest of engineering as “hacky”, but in fact, it is because the focus is less on code and application health, and more on user adoption (and thus spending more time on analytics, user outreach, and experimentation).
|Activation||Are they learning to use the product?||Are they paying?|
|Retention||Do they continue to use the product?||Are they churning?|
|Expansion||Are they using more features or inviting others?||Are they upgrading?|
What portion of the new users crosses a threshold within a period?
A threshold might be key features adopted, members invited, projects set up, trial triggered. They are the minimum user investment to understand your product’s value and, ideally, to business value for you1.
The period will vary by what you define as the “activation moment” but generally, it’s within the first day, week, or month2. For broad understanding, it’s useful to have historical cohort adoption rate, but inevitably you’ll want to pick a period and monitor it over time as you work to improve it. For Sentry and most B2B tools, it’s best to group by week in order to reduce the noise of weekends.
What portion of users stop using or paying for the product?
Happy families are all alike; every unhappy family is unhappy in its own way. Tolstoy
Retention (and its evil twin, churn) are complicated. Churn (both revenue or usage) can be broken down into two major categories: 1. insufficent product value or 2. switching to a competitor.
Churn to competitors is quite simple, as there’s a clear reason (whether it’s valid or not is a matter of perspective) behind it. All you need to do is catalog the reasons and address the common ones. Churn to lack of product value is trickier. It implies they did not properly activate, or product value had diminished over time.
Retention is especially hard because it tends to require more manual intervention. When monthly churn is high (over a few percent), this becomes a major business concern. However, when churn is relatively low, manual intervention is more about gathering product feedback.
How widely (across the organization) or deeply (of the product’s features) is your user base adopting your product?
Attribution is critical here. Users are naturally curious and over time, organically explore and adopt your product (provided they don’t churn). Without attribution, it’s hard to understand impact and value of growth engineering projects.
Measuring first and second order effects is especially tricky here.