The Growth Engineering Process
Since it has been almost a year since I’ve joined Tray.io as a Senior Growth Engineer. I figured it was time for a reflection on my thoughts on what I define as the basis for what I do every day.
Not only to share my lessons with you but to also define a structure for future growth engineers to quickly get up to speed
Choose A Metric
“You can't manage what you can't measure.” - Peter Drucker
We begin the process by choosing a metric that we wish to improve. More often then not this will be a baseline metric such as Conversion Rate, Form Fill Rate, Website load time, Engagement, Email Link Clicks, etc.
What I tend to do is look at the metric and see if I can see any obvious trends. Has it decreased over time? Does it peak during times of the year? Is there another metric that impacts this metric?
This is useful further down the line so you can factor in a metric's normal behavior when you make a change.
Develop a Hypothesis
“Quickness is the essence of the war.” - Sun Tzu
Now you must ask yourself how you’ll improve this metric. To not get married to a single solution I tend to ask myself a series of questions:
- What’s impacting this metric? For metrics such as conversion rate, you can observe traffic sources, website load time, etc.
- How could I cause this metric to go down? Useful to think of the opposite for once and do the inverse.
- Who is responsible for this metric? You can get a deeper insight by speaking with the person in charge of acquisition etc.
I often find that forcing myself to come up with more than one solution often leads to thinking about edge cases and other tactics that can feed into the main solution.
Once you’ve developed your hypothesis I recommend finding the smallest possible way to test it. Whether that be an A/B test or tweaking some variables or copy. The aim is to see if the hypothesis will have an impact on the metric. If a small change can cause a slight shift then implementing the full change will cause an uptick.
A/B Test it
“The options are limitless, but each path must begin with the same first step: replacing assumptions” – Tim Ferriss
Once you’re ready to release your change to the world I recommend partially releasing it to a subset of your traffic. I’ve mentioned previously that you should test your hypothesis with a small tweak, which acts as an indicator, but when making larger changes I still like to test the effects.
It has the benefit of being able to quickly see the percentage improvement you’ve delivered compared to the old version of the site. Normally I see a lot of developers skip this step and just deploy the entire change which makes it harder to see the impact in the short term.
Keep an eye on it
“If you wait by the river long enough, the bodies of your enemies will float by.” - Sun Tzu
Don’t just give up now that you’ve released! Keep an eye on that metric as it may take a few days for the changes you’ve made to show any significant impact.
I highly recommend having an easily accessible dashboard which shows all the metrics your team is working on to improve. Watch the metric for 1-2 weeks to see if the trend has been impacted. Factor in that external sources might also be contributing to any trends that you’re seeing
If you haven’t already noticed the above process is very similar to the Lean Startup approach by Eric Reis. My convictions about Growth Engineering is that it should closely follow the Lean Startup method. As engineers we are constantly creating features, products, updating copy, and looking for new ways to help the business. It makes perfect sense therefore to follow a method that validates our assumptions and acts as a guiding principle for improvement.
if you’re a software engineer who has a fascination with marketing and optimizing conversion rate etc. Then I’d love to talk with you about the above process and get your thoughts on it.