From bd1c307cdf86e406d0ef5e11c87cdea771c67503 Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Mon, 16 Sep 2024 15:55:46 -0700
Subject: [PATCH 1/8] growth engineer secrets
---
.../newsletter/growth-engineer-secrets.md | 90 +++++++++++++++++++
1 file changed, 90 insertions(+)
create mode 100644 contents/newsletter/growth-engineer-secrets.md
diff --git a/contents/newsletter/growth-engineer-secrets.md b/contents/newsletter/growth-engineer-secrets.md
new file mode 100644
index 000000000000..665594f71d08
--- /dev/null
+++ b/contents/newsletter/growth-engineer-secrets.md
@@ -0,0 +1,90 @@
+---
+title: The secrets of growth engineers
+date: 2024-09-16
+author:
+ - ian-vanagas
+featuredImage: >-
+featuredImageType: full
+tags:
+ - Engineering
+crosspost:
+ - Product engineers
+ - Founders
+ - Blog
+---
+
+From the outside, it can seem like growth engineers are bouncing around the product: signup flows, product onboarding, revenue reporting, and subscription tracking. You might think all this doesn't matter, but as many growth teams show, incremental improvements can lead to massive gains for the entire business.
+
+Growth engineers capture these gains through their unique way of thinking and working. Luckily, you don't need to go to growth engineer school to learn this yourself. If you aspire to create a successful product and business, you should care about what growth engineers do to make that happen, and this post aims to help you do just that.
+
+## 1. Being data-driven is a cliche, but it's also a way of life
+
+Everyone claims they are data-driven, but growth engineers prove it.
+
+
+
+Their work revolves around the core metrics they care about. These are platform or business-level metrics like signup conversion, activation, subscription conversion, revenue growth, user engagement, retention, and more. Their work comes down to tracking and improving these metrics.
+
+The tradeoff is caring less about products, features, roadmaps, and user requests. They let the metrics be their north star and do whatever, wherever to improve it. Instead of doing what they feel is right or the roadmap set by someone else, they work trying to improve the metrics.
+
+> **Takeaway for software engineers:** What are the growth metrics of what you are working on? Understand your key flow [conversion](/docs/product-analytics/funnels), activation, and [retention](/docs/product-analytics/retention). You can use a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to model this.
+
+## 2. How to develop an experimentation mindset
+
+The big way growth engineers improve the metrics they care about is through experiments. Doing this well requires requires developing the elusive "experimentation mindset." This differs from the traditional software engineering mindset in a few ways:
+
+1. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get torn out. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later.
+
+2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. A software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
+
+3. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns. They run experiments to validate their assumptions and care more about exploration and discovery.
+
+> **Takeaway for software engineers:** What are areas of your work that could leverage more of an experimentation mindset? Could you be more pragmatic and iterate on a hypothesis instead of just shipping the next feature on your list?
+
+## 3. How growth engineers figure out what to work on
+
+Engineers are like bus drivers, helping move a product along its roadmap toward success. Growth engineers are like Uber drivers, bouncing from experiment to experiment stacking little wins that payoff in the long term.
+
+How do they find these potential wins?
+
+1. Start by identifying a target area. For example, product onboarding.
+
+2. Identify a metric that represents that target area. For example, signup to dashboard creation conversion.
+
+3. Talk to users and create hypotheses. For example, a [survey](/surveys) reveals users have trouble finding where to create their dashboard. A hypothesis could be "adding the ability to create a dashboard from a template in the onboarding flow will lead to more dashboards created."
+
+4. Implement as small of an experiment as reasonably possible. For example, test a button that creates one of three dashboard template options, rather than a full UI.
+
+> **Takeaway for software engineers:** What are the target areas you are trying to grow? What is the important metric for that area? Are the changes you are making impacting that metric?
+
+## 4. How to run and evaluate experiments
+
+When you're ready to implement your experiment, there are a few more things you need:
+
+1. **A sufficiently large sample size of users.** This ensures you can hit statistical significance AKA your impact is better than random chance.
+
+2. **A long enough test duration.** As a rule of thumb, one week is a good minimum to include the variety of usage across the week. One month is a good maximum to avoid delaying shipping important changes.
+
+3. **A list of [common mistakes](/product-engineers/ab-testing-mistakes) and how to avoid them.** These include only viewing aggregate results, not having a predetermined duration, and neglecting counter metrics.
+
+4. **A way to split and log participants.** You want to randomly split test and control groups as well as only log participants in your results. [Feature flags](/feature-flags) help do this.
+
+> **Takeaway for software engineers:** Try it! [Running an experiment](/product-engineers/how-to-do-ab-testing) reveals a lot about crafting a good hypothesis, choosing a good goal metric, and evaluating results. It may even lead you to reevaluate changes you once considered obvious.
+
+## 5. Failure is not the end of the world
+
+For a software engineer, failure means bugs, downtime, data corruption, and many more nightmare-inducing issues. For growth engineers, it's just another day on the job.
+
+A lot of experiments will fail. Often, a majority of experiments fail. At [Google](https://hbr.org/2017/09/the-surprising-power-of-online-experiments#:~:text=At%20Google%20and%20Bing%2C%20only%20about%2010%25%20to%2020%25%20of%20experiments%20generate%20positive%20results.), 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
+
+On top of the successes, failures are also opportunities to learn. As the saying goes "it's only a failure if you fail to learn." Rapid experimentation, and the gains it provides, is only possible when you embrace failure.
+
+> **Takeaway for software engineers:** Set up your experiments so when they fail it doesn't result in a critical failure. This helps you create situations where failure is an option so you can get more comfortable with it.
+
+## More good reads
+
+- [Debugging conversion problems](https://mikebifulco.com/posts/debugging-a-conversion-problem-on-my-nextjs-site) - Mike
+Mike details his ongoing work to improve newsletter conversion on his personal site.
+- [A software engineer's guide to A/B testing](/product-engineers/ab-testing-guide-for-engineers) - Lior
+
+
\ No newline at end of file
From 2755ed8dbb5e99e34ba8171995a4d9669c667bc1 Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Tue, 17 Sep 2024 12:00:33 -0700
Subject: [PATCH 2/8] rewrite
---
.../newsletter/growth-engineer-secrets.md | 90 ------------------
.../think-like-a-growth-engineer.md | 94 +++++++++++++++++++
2 files changed, 94 insertions(+), 90 deletions(-)
delete mode 100644 contents/newsletter/growth-engineer-secrets.md
create mode 100644 contents/newsletter/think-like-a-growth-engineer.md
diff --git a/contents/newsletter/growth-engineer-secrets.md b/contents/newsletter/growth-engineer-secrets.md
deleted file mode 100644
index 665594f71d08..000000000000
--- a/contents/newsletter/growth-engineer-secrets.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: The secrets of growth engineers
-date: 2024-09-16
-author:
- - ian-vanagas
-featuredImage: >-
-featuredImageType: full
-tags:
- - Engineering
-crosspost:
- - Product engineers
- - Founders
- - Blog
----
-
-From the outside, it can seem like growth engineers are bouncing around the product: signup flows, product onboarding, revenue reporting, and subscription tracking. You might think all this doesn't matter, but as many growth teams show, incremental improvements can lead to massive gains for the entire business.
-
-Growth engineers capture these gains through their unique way of thinking and working. Luckily, you don't need to go to growth engineer school to learn this yourself. If you aspire to create a successful product and business, you should care about what growth engineers do to make that happen, and this post aims to help you do just that.
-
-## 1. Being data-driven is a cliche, but it's also a way of life
-
-Everyone claims they are data-driven, but growth engineers prove it.
-
-
-
-Their work revolves around the core metrics they care about. These are platform or business-level metrics like signup conversion, activation, subscription conversion, revenue growth, user engagement, retention, and more. Their work comes down to tracking and improving these metrics.
-
-The tradeoff is caring less about products, features, roadmaps, and user requests. They let the metrics be their north star and do whatever, wherever to improve it. Instead of doing what they feel is right or the roadmap set by someone else, they work trying to improve the metrics.
-
-> **Takeaway for software engineers:** What are the growth metrics of what you are working on? Understand your key flow [conversion](/docs/product-analytics/funnels), activation, and [retention](/docs/product-analytics/retention). You can use a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to model this.
-
-## 2. How to develop an experimentation mindset
-
-The big way growth engineers improve the metrics they care about is through experiments. Doing this well requires requires developing the elusive "experimentation mindset." This differs from the traditional software engineering mindset in a few ways:
-
-1. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get torn out. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later.
-
-2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. A software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
-
-3. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns. They run experiments to validate their assumptions and care more about exploration and discovery.
-
-> **Takeaway for software engineers:** What are areas of your work that could leverage more of an experimentation mindset? Could you be more pragmatic and iterate on a hypothesis instead of just shipping the next feature on your list?
-
-## 3. How growth engineers figure out what to work on
-
-Engineers are like bus drivers, helping move a product along its roadmap toward success. Growth engineers are like Uber drivers, bouncing from experiment to experiment stacking little wins that payoff in the long term.
-
-How do they find these potential wins?
-
-1. Start by identifying a target area. For example, product onboarding.
-
-2. Identify a metric that represents that target area. For example, signup to dashboard creation conversion.
-
-3. Talk to users and create hypotheses. For example, a [survey](/surveys) reveals users have trouble finding where to create their dashboard. A hypothesis could be "adding the ability to create a dashboard from a template in the onboarding flow will lead to more dashboards created."
-
-4. Implement as small of an experiment as reasonably possible. For example, test a button that creates one of three dashboard template options, rather than a full UI.
-
-> **Takeaway for software engineers:** What are the target areas you are trying to grow? What is the important metric for that area? Are the changes you are making impacting that metric?
-
-## 4. How to run and evaluate experiments
-
-When you're ready to implement your experiment, there are a few more things you need:
-
-1. **A sufficiently large sample size of users.** This ensures you can hit statistical significance AKA your impact is better than random chance.
-
-2. **A long enough test duration.** As a rule of thumb, one week is a good minimum to include the variety of usage across the week. One month is a good maximum to avoid delaying shipping important changes.
-
-3. **A list of [common mistakes](/product-engineers/ab-testing-mistakes) and how to avoid them.** These include only viewing aggregate results, not having a predetermined duration, and neglecting counter metrics.
-
-4. **A way to split and log participants.** You want to randomly split test and control groups as well as only log participants in your results. [Feature flags](/feature-flags) help do this.
-
-> **Takeaway for software engineers:** Try it! [Running an experiment](/product-engineers/how-to-do-ab-testing) reveals a lot about crafting a good hypothesis, choosing a good goal metric, and evaluating results. It may even lead you to reevaluate changes you once considered obvious.
-
-## 5. Failure is not the end of the world
-
-For a software engineer, failure means bugs, downtime, data corruption, and many more nightmare-inducing issues. For growth engineers, it's just another day on the job.
-
-A lot of experiments will fail. Often, a majority of experiments fail. At [Google](https://hbr.org/2017/09/the-surprising-power-of-online-experiments#:~:text=At%20Google%20and%20Bing%2C%20only%20about%2010%25%20to%2020%25%20of%20experiments%20generate%20positive%20results.), 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
-
-On top of the successes, failures are also opportunities to learn. As the saying goes "it's only a failure if you fail to learn." Rapid experimentation, and the gains it provides, is only possible when you embrace failure.
-
-> **Takeaway for software engineers:** Set up your experiments so when they fail it doesn't result in a critical failure. This helps you create situations where failure is an option so you can get more comfortable with it.
-
-## More good reads
-
-- [Debugging conversion problems](https://mikebifulco.com/posts/debugging-a-conversion-problem-on-my-nextjs-site) - Mike
-Mike details his ongoing work to improve newsletter conversion on his personal site.
-- [A software engineer's guide to A/B testing](/product-engineers/ab-testing-guide-for-engineers) - Lior
-
-
\ No newline at end of file
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
new file mode 100644
index 000000000000..502300a2af17
--- /dev/null
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -0,0 +1,94 @@
+---
+title: How to think like a growth engineer
+date: 2024-09-16
+author:
+ - ian-vanagas
+featuredImage: >-
+featuredImageType: full
+tags:
+ - Engineering
+crosspost:
+ - Product engineers
+ - Founders
+ - Blog
+---
+
+From the outside, it can seem like growth engineers are bouncing around the product: signup flows, product onboarding, revenue reporting, and subscription tracking. You might think all this doesn't matter, but as many growth teams show, incremental improvements can lead to massive gains for the entire business.
+
+Growth engineers capture these gains through their unique way of thinking and working. Luckily, you don't need to go to growth engineer school to learn this yourself. If you aspire to create a successful product and business, you should care about what growth engineers do to make that happen, and this post aims to help you do just that.
+
+## 1. Become a data-driven (for real)
+
+Everyone claims they are data-driven, but growth engineers prove it.
+
+
+
+Their work comes down to tracking and improving platform or business-level metrics. For example, our growth team cares about new revenue, expansion, signup conversion, activation, retention, and more. Their planning, prioritization, and execution are focused on improving these metrics.
+
+The tradeoff is caring less about products, features, and user requests. They aren't planning their roadmap months in advance or caring about accurate project timelines. They let the metrics be their north star and do whatever, wherever to improve it.
+
+> **Takeaway:** Create a dashboard using a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to monitor your key flow conversions, activation, and retention.
+
+
+
+## 2. Develop an experimentation mindset
+
+The big way growth engineers improve the metrics they care about is through experiments. Doing this well requires developing the elusive "experimentation mindset." This differs from the traditional software engineering mindset in a few ways:
+
+1. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns. They run experiments to validate their assumptions and care more about exploration and discovery.
+
+2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. A software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
+
+3. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get torn out. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later. For example, our team
+
+> **Takeaway:** Instead of shipping the next feature on your list, take a moment to develop a hypothesis on how you could improve your product. Does what you are working on fit the hypothesis? What would it take to test the hypothesis?
+
+## 3. Prioritize like a growth engineer
+
+Engineers are like bus drivers, helping move a product along its roadmap toward success. Growth engineers are like Uber drivers, bouncing from experiment to experiment stacking little wins that payoff in the long term.
+
+Let's look at a recent example from our growth team.
+
+1. **Identify a target area.** Product analytics has seen some massive upgrades lately and we've also added our data warehouse. Onboarding for both these products hasn't kept up, so they identified this as an area to improve.
+
+2. **Identify a metric that represents that target area.** They chose the percentage of new organizations that activate, which combines creating a dashboard, analyzing an insight, inviting a teammate, and more. They wanted to improve this metric while keeping retention the same or improving it.
+
+3. **Create hypotheses.** Dashboard templates help teams get value out of PostHog quickly. They hypothesized that adding a dashboard template to the onboarding flow using actions would lead to better activation.
+
+4. **Implement as small of an experiment as reasonably possible.** They added a step in the onboarding flow to choose a dashboard template and fill out the variables by creating actions.
+
+
+
+> **Takeaway:** For the area you work on, identify a metric that represents it. Track how the features you are shipping impact this metric. Are the features you are shipping helping or hurting this metric?
+
+## 4. How to run and evaluate experiments
+
+When you're ready to implement your experiment, there are a few more things you need:
+
+1. **A sufficiently large sample size of users.** This ensures you can hit statistical significance AKA your impact is better than random chance.
+
+2. **A long enough test duration.** As a rule of thumb, one week is a good minimum to include the variety of usage across the week. One month is a good maximum to avoid delaying shipping important changes.
+
+3. **A list of [common mistakes](/product-engineers/ab-testing-mistakes) and how to avoid them.** These include only viewing aggregate results, not having a predetermined duration, and neglecting counter metrics.
+
+4. **A way to split and log participants.** You want to randomly split test and control groups as well as only log participants in your results. [Feature flags](/feature-flags) help do this.
+
+> **Takeaway:** Try it! [Running an experiment](/product-engineers/how-to-do-ab-testing) reveals a lot about crafting a good hypothesis, choosing a good goal metric, and evaluating results. It may even lead you to reevaluate changes you once considered obvious.
+
+## 5. Failure is not the end of the world
+
+For a software engineer, failure means bugs, downtime, data corruption, and many more nightmare-inducing issues. For growth engineers, it's just another day on the job.
+
+Many experiments fail. Often, a majority of experiments fail. At [Google](https://hbr.org/2017/09/the-surprising-power-of-online-experiments#:~:text=At%20Google%20and%20Bing%2C%20only%20about%2010%25%20to%2020%25%20of%20experiments%20generate%20positive%20results.), 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
+
+On top of the successes, failures are also opportunities to learn. As the saying goes "it's only a failure if you fail to learn." Rapid experimentation, and the gains it provides, are only possible when you embrace failure.
+
+> **Takeaway:** Set up the infrastructure and processes to run experiments safely. Get comfortable running experiments on small groups before scaling.
+
+## More good reads
+
+- [Debugging conversion problems](https://mikebifulco.com/posts/debugging-a-conversion-problem-on-my-nextjs-site) - Mike
+Mike details his ongoing work to improve newsletter conversion on his site.
+- [A software engineer's guide to A/B testing](/product-engineers/ab-testing-guide-for-engineers) - Lior
+
+
\ No newline at end of file
From b3cede69f787812b511150fa19aaf506758ac7f0 Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Tue, 17 Sep 2024 14:18:54 -0700
Subject: [PATCH 3/8] more fixes
---
contents/newsletter/think-like-a-growth-engineer.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
index 502300a2af17..9300c2e35370 100644
--- a/contents/newsletter/think-like-a-growth-engineer.md
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -13,7 +13,7 @@ crosspost:
- Blog
---
-From the outside, it can seem like growth engineers are bouncing around the product: signup flows, product onboarding, revenue reporting, and subscription tracking. You might think all this doesn't matter, but as many growth teams show, incremental improvements can lead to massive gains for the entire business.
+From the outside, it can seem like growth engineers bounce around the product aimlessly: signup flows, product onboarding, revenue reporting, and subscription tracking. You might think all this doesn't matter, but as many growth teams show, incremental improvements can lead to massive gains for the entire business.
Growth engineers capture these gains through their unique way of thinking and working. Luckily, you don't need to go to growth engineer school to learn this yourself. If you aspire to create a successful product and business, you should care about what growth engineers do to make that happen, and this post aims to help you do just that.
@@ -37,9 +37,9 @@ The big way growth engineers improve the metrics they care about is through expe
1. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns. They run experiments to validate their assumptions and care more about exploration and discovery.
-2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. A software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
+2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. For example, a software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
-3. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get torn out. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later. For example, our team
+3. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get removed. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later.
> **Takeaway:** Instead of shipping the next feature on your list, take a moment to develop a hypothesis on how you could improve your product. Does what you are working on fit the hypothesis? What would it take to test the hypothesis?
@@ -47,7 +47,7 @@ The big way growth engineers improve the metrics they care about is through expe
Engineers are like bus drivers, helping move a product along its roadmap toward success. Growth engineers are like Uber drivers, bouncing from experiment to experiment stacking little wins that payoff in the long term.
-Let's look at a recent example from our growth team.
+To understand what their work looks like, let's look at a recent example from our growth team:
1. **Identify a target area.** Product analytics has seen some massive upgrades lately and we've also added our data warehouse. Onboarding for both these products hasn't kept up, so they identified this as an area to improve.
@@ -59,7 +59,7 @@ Let's look at a recent example from our growth team.
-> **Takeaway:** For the area you work on, identify a metric that represents it. Track how the features you are shipping impact this metric. Are the features you are shipping helping or hurting this metric?
+> **Takeaway:** For the area you work on, identify a metric that represents it. Track the impact features ship have on this metric. Is what you are shipping helping or hurting it?
## 4. How to run and evaluate experiments
From afbd7b14d0b48b6c48f6244ffd8c7556fa4f8c95 Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Thu, 19 Sep 2024 12:05:01 -0700
Subject: [PATCH 4/8] better takeaways
---
.../think-like-a-growth-engineer.md | 39 +++++++++++++------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
index 9300c2e35370..3399b80f180b 100644
--- a/contents/newsletter/think-like-a-growth-engineer.md
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -27,21 +27,29 @@ Their work comes down to tracking and improving platform or business-level metri
The tradeoff is caring less about products, features, and user requests. They aren't planning their roadmap months in advance or caring about accurate project timelines. They let the metrics be their north star and do whatever, wherever to improve it.
-> **Takeaway:** Create a dashboard using a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to monitor your key flow conversions, activation, and retention.
-
-
+> **Takeaway:** Figure out the status quo for the area you work on. To do this:
+> 1. Define and track your activation and retention numbers.
+> 2. Track how they move week over week.
+> 3. Track how they move with the changes you ship.
+>
+> You can't think like a growth engineer if you don't have a metrics baseline to start from.
+>
+> For more advanced users, create a dashboard using a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to monitor your key flow conversions, activation, and retention.
+> 
## 2. Develop an experimentation mindset
The big way growth engineers improve the metrics they care about is through experiments. Doing this well requires developing the elusive "experimentation mindset." This differs from the traditional software engineering mindset in a few ways:
-1. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns. They run experiments to validate their assumptions and care more about exploration and discovery.
+1. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns and care more about exploration and discovery. To do this, they develop hypotheses and run experiments to validate their assumptions.
2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. For example, a software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
3. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get removed. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later.
-> **Takeaway:** Instead of shipping the next feature on your list, take a moment to develop a hypothesis on how you could improve your product. Does what you are working on fit the hypothesis? What would it take to test the hypothesis?
+> **Takeaway:** Instead of blindly shipping the next feature on your list, think about the hypothesis behind it.
+>
+> For example, adding customizable notifications will get users to return more often, improving retention. After adding the feature, use the metrics you set up in the previous section to validate your hypothesis.
## 3. Prioritize like a growth engineer
@@ -59,11 +67,13 @@ To understand what their work looks like, let's look at a recent example from ou
-> **Takeaway:** For the area you work on, identify a metric that represents it. Track the impact features ship have on this metric. Is what you are shipping helping or hurting it?
+> **Takeaway:** Now it is time to go from post-hoc analysis to proactive prioritization. With your target area, metric, and hypothesis in mind, develop a list of experiments to run that can improve your product. Think about how you can test your ideas in the smallest way possible.
+>
+> For example, if you are trying to improve activation by changing the onboarding flow, could you test removing steps instead of adding new ones?
-## 4. How to run and evaluate experiments
+## 4. Trust the (experimentation) process
-When you're ready to implement your experiment, there are a few more things you need:
+Engineers might see the word "process" and shutter, but to be data-driven, you need to follow process to ensure you can trust your data when making decisions. When it comes to running experiments, growth engineers always make sure to have:
1. **A sufficiently large sample size of users.** This ensures you can hit statistical significance AKA your impact is better than random chance.
@@ -73,17 +83,24 @@ When you're ready to implement your experiment, there are a few more things you
4. **A way to split and log participants.** You want to randomly split test and control groups as well as only log participants in your results. [Feature flags](/feature-flags) help do this.
-> **Takeaway:** Try it! [Running an experiment](/product-engineers/how-to-do-ab-testing) reveals a lot about crafting a good hypothesis, choosing a good goal metric, and evaluating results. It may even lead you to reevaluate changes you once considered obvious.
+> **Takeaway:** Try it! Set up your feature flags and logging. Craft a hypothesis and goal metric. Check that your sample size is big enough and your duration is long enough.
+>
+> Going through this process reveals the reality of experimentation. It's not just about shipping changes and seeing what happens, it's a disciplined approach to improvement.
## 5. Failure is not the end of the world
-For a software engineer, failure means bugs, downtime, data corruption, and many more nightmare-inducing issues. For growth engineers, it's just another day on the job.
+For a software engineer, failure means bugs, downtime, data corruption, and more nightmare-inducing issues. For growth engineers, it's just another day on the job.
Many experiments fail. Often, a majority of experiments fail. At [Google](https://hbr.org/2017/09/the-surprising-power-of-online-experiments#:~:text=At%20Google%20and%20Bing%2C%20only%20about%2010%25%20to%2020%25%20of%20experiments%20generate%20positive%20results.), 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
On top of the successes, failures are also opportunities to learn. As the saying goes "it's only a failure if you fail to learn." Rapid experimentation, and the gains it provides, are only possible when you embrace failure.
-> **Takeaway:** Set up the infrastructure and processes to run experiments safely. Get comfortable running experiments on small groups before scaling.
+> **Takeaway:** To get comfortable with failure:
+> 1. Test both sides of the experiment on yourself first.
+> 2. Test on a smaller group of users before scaling.
+> 3. Keep your experiments small so you feel less bad when they fail.
+>
+> Remember, failure is core to being data-driven (the growth engineer's north star). Lying to yourself about what works and what doesn't will only hurt your product in the long run.
## More good reads
From e0e10b9a2166f6631c3a9ccf96a4bef9a42fc3e7 Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Tue, 24 Sep 2024 11:33:37 -0700
Subject: [PATCH 5/8] Andy's suggestions
Co-authored-by: Andy Vandervell <92976667+andyvan-ph@users.noreply.github.com>
---
.../newsletter/think-like-a-growth-engineer.md | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
index 3399b80f180b..57289a74239b 100644
--- a/contents/newsletter/think-like-a-growth-engineer.md
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -13,19 +13,21 @@ crosspost:
- Blog
---
-From the outside, it can seem like growth engineers bounce around the product aimlessly: signup flows, product onboarding, revenue reporting, and subscription tracking. You might think all this doesn't matter, but as many growth teams show, incremental improvements can lead to massive gains for the entire business.
+From the outside, it can seem as if growth engineers bounce around the product aimlessly – tweaking signup and onboarding flows, and running endless experiments, many of which fail.
-Growth engineers capture these gains through their unique way of thinking and working. Luckily, you don't need to go to growth engineer school to learn this yourself. If you aspire to create a successful product and business, you should care about what growth engineers do to make that happen, and this post aims to help you do just that.
+It's tempting to dismiss this as busywork, but that would be a mistake. Many successful startups have a thriving growth team at their core, driving incremental improvements that accumulate massive gains.
-## 1. Become a data-driven (for real)
+Growth engineers capture these gains through their unique way of thinking and working. And, luckily, you don't need to go to growth engineer school to learn their secrets. It all starts by learning to think like they do – here's how.
-Everyone claims they are data-driven, but growth engineers prove it.
+## 1. Become data-driven (for real)
+
+Everyone claims they are data-driven, but it's more than a meme for growth engineers.
-Their work comes down to tracking and improving platform or business-level metrics. For example, our growth team cares about new revenue, expansion, signup conversion, activation, retention, and more. Their planning, prioritization, and execution are focused on improving these metrics.
+Their work comes down to tracking and improving platform or business-level metrics. Our growth team, for example, cares about new revenue, expansion, signup conversion, activation, retention, and more. Their planning, prioritization, and execution are focused on improving these metrics.
-The tradeoff is caring less about products, features, and user requests. They aren't planning their roadmap months in advance or caring about accurate project timelines. They let the metrics be their north star and do whatever, wherever to improve it.
+The tradeoff is caring less about products, features, and user requests. They aren't planning their roadmap months in advance or obsessing about accurate project timelines. They let the metrics be their north star and do whatever, wherever to improve them.
> **Takeaway:** Figure out the status quo for the area you work on. To do this:
> 1. Define and track your activation and retention numbers.
@@ -39,7 +41,7 @@ The tradeoff is caring less about products, features, and user requests. They ar
## 2. Develop an experimentation mindset
-The big way growth engineers improve the metrics they care about is through experiments. Doing this well requires developing the elusive "experimentation mindset." This differs from the traditional software engineering mindset in a few ways:
+Growth engineers often say "everything is an experiment." This is the elusive "experimentation mindset" that drives them. It differs from the traditional software engineering mindset in a few ways:
1. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns and care more about exploration and discovery. To do this, they develop hypotheses and run experiments to validate their assumptions.
@@ -73,7 +75,7 @@ To understand what their work looks like, let's look at a recent example from ou
## 4. Trust the (experimentation) process
-Engineers might see the word "process" and shutter, but to be data-driven, you need to follow process to ensure you can trust your data when making decisions. When it comes to running experiments, growth engineers always make sure to have:
+Engineers might see the word "process" and shudder, but being data-driven requires an established process so you can trust the data when making decisions. When it comes to running experiments, growth engineers always make sure to have:
1. **A sufficiently large sample size of users.** This ensures you can hit statistical significance AKA your impact is better than random chance.
From 26d577d5414c92c8d6da2973f15be3dbaa604c1f Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Fri, 27 Sep 2024 13:35:16 -0700
Subject: [PATCH 6/8] match substack, links
---
contents/blog/what-is-a-growth-engineer.md | 2 +-
...ow-to-treat-your-pricing-like-a-product.md | 2 +-
.../think-like-a-growth-engineer.md | 95 +++++++++++--------
.../product-engineers/ab-testing-mistakes.md | 2 +-
.../fixing-growth-problems.md | 2 +-
5 files changed, 61 insertions(+), 42 deletions(-)
diff --git a/contents/blog/what-is-a-growth-engineer.md b/contents/blog/what-is-a-growth-engineer.md
index 839e59054f1a..b8170aa0deea 100644
--- a/contents/blog/what-is-a-growth-engineer.md
+++ b/contents/blog/what-is-a-growth-engineer.md
@@ -126,7 +126,7 @@ Growth engineers help your overall business by helping all products grow faster.
We've seen this from our growth team. Building cross-product features, like billing, has improved our overall business and user experience. These features don't fit into a specific product team's responsibility and would be missed out on if growth engineers didn't exist.
-Growth engineers likely won't help you find traction, they need products to connect and optimize to thrive. Once you have traction, it might be the right time to hire a growth engineer to fuel rapid growth.
+Growth engineers likely won't help you find traction, they need products to connect and optimize to thrive. Once you have traction, it might be the right time to hire a [growth engineer](/newsletter/think-like-a-growth-engineer) to fuel rapid growth.
From our experience, we'd recommend the technical and entreprenuerial growth engineer, this often arises in former founders. Later-stage teams often find success with larger growth teams, and more marketing-focused roles, but we haven't made it that far yet.
diff --git a/contents/founders/how-to-treat-your-pricing-like-a-product.md b/contents/founders/how-to-treat-your-pricing-like-a-product.md
index da6b6c3af361..2f555ce9758b 100644
--- a/contents/founders/how-to-treat-your-pricing-like-a-product.md
+++ b/contents/founders/how-to-treat-your-pricing-like-a-product.md
@@ -102,7 +102,7 @@ Any good product manager will tell you that a product is (almost) never done. Th
## How "pricing as a product" works at PostHog
-We've been on this journey for close to a year now. It started with realizing that our pricing wasn't serving the needs of both our internal and external customers, then hiring a growth engineer to own it.
+We've been on this journey for close to a year now. It started with realizing that our pricing wasn't serving the needs of both our internal and external customers, then hiring a [growth engineer](/newsletter/think-like-a-growth-engineer) to own it.
We built a completely new billing service from the ground up to satisfy those needs, and have gone through multiple iterations of how we price and sell to customers to align with our company strategy.
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
index 57289a74239b..0eb69faa1c0d 100644
--- a/contents/newsletter/think-like-a-growth-engineer.md
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -13,11 +13,11 @@ crosspost:
- Blog
---
-From the outside, it can seem as if growth engineers bounce around the product aimlessly – tweaking signup and onboarding flows, and running endless experiments, many of which fail.
+For the unfamiliar, [growth engineers](/blog/what-is-a-growth-engineer) seemingly bounce around the product aimlessly – tweaking signup flows, optimizing onboarding, and running endless experiments (many of which fail).
-It's tempting to dismiss this as busywork, but that would be a mistake. Many successful startups have a thriving growth team at their core, driving incremental improvements that accumulate massive gains.
+It's tempting to dismiss this as busywork, but that’s a mistake. Many successful startups have thriving growth teams at their core, driving incremental improvements that accumulate as massive gains.
-Growth engineers capture these gains through their unique way of thinking and working. And, luckily, you don't need to go to growth engineer school to learn their secrets. It all starts by learning to think like they do – here's how.
+Growth engineers discover and capture these gains through their unique way of thinking and working. Luckily, you don't need to go to growth engineer school to learn their secrets. It all starts by learning to think like they do – here's how.
## 1. Become data-driven (for real)
@@ -25,19 +25,25 @@ Everyone claims they are data-driven, but it's more than a meme for growth engin
-Their work comes down to tracking and improving platform or business-level metrics. Our growth team, for example, cares about new revenue, expansion, signup conversion, activation, retention, and more. Their planning, prioritization, and execution are focused on improving these metrics.
+Their work comes down to tracking and improving platform or business-level metrics. Our growth team, for example, cares about new revenue, expansion, signup conversion, activation, retention, and more. Their planning, prioritization, and execution focus on improving these metrics.
-The tradeoff is caring less about products, features, and user requests. They aren't planning their roadmap months in advance or obsessing about accurate project timelines. They let the metrics be their north star and do whatever, wherever to improve them.
+The tradeoff is caring less about products, features, and user requests. They aren't planning their roadmap months in advance or obsessing about accurate project timelines. They let the metrics be their [north star](/founders/north-star-metrics) and do whatever, wherever to improve them.
-> **Takeaway:** Figure out the status quo for the area you work on. To do this:
-> 1. Define and track your activation and retention numbers.
-> 2. Track how they move week over week.
-> 3. Track how they move with the changes you ship.
->
-> You can't think like a growth engineer if you don't have a metrics baseline to start from.
->
-> For more advanced users, create a dashboard using a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to monitor your key flow conversions, activation, and retention.
-> 
+#### How to start becoming data-driven
+
+Figure out the status quo for the area you work on. To do this:
+
+1. Define and track your activation and [retention](/docs/product-analytics/retention) numbers. Activation is users reaching the “aha moment” of your product. Retention is them returning to do it again.
+
+2. Track how they move week over week.
+
+3. Track how they move with the changes you ship.
+
+You can't think like a growth engineer if you don't have a metrics baseline to start from.
+
+For more advanced users, create a dashboard using a framework like [AARRR](/product-engineers/aarrr-pirate-funnel) or [growth loops](/product-engineers/growth-loops) to monitor your key flows.
+
+
## 2. Develop an experimentation mindset
@@ -45,37 +51,51 @@ Growth engineers often say "everything is an experiment." This is the elusive "e
1. **Hypothesis over requirements.** Software engineers work on features users clearly need. Growth engineers work on more unknowns and care more about exploration and discovery. To do this, they develop hypotheses and run experiments to validate their assumptions.
-2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. For example, a software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
+2. **Iteration over stability.** While most engineers focus on developing stable, bug-free code, growth engineers would rather fail fast and iterate. For example, a software engineer might feel uncomfortable adding a dependency before evaluating it, while a growth engineer will ship it to help them test faster.
3. **Pragmatism over perfection.** Growth engineers know their experiments might fail and get removed. This means they ship the "good enough" version over the maintainable and scalable one. They know they can always improve it later.
-> **Takeaway:** Instead of blindly shipping the next feature on your list, think about the hypothesis behind it.
+### How to start developing an experimentation mindset
+
+Instead of blindly shipping the next feature on your list, think about the hypothesis behind it and the “dumbest” way to test that hypothesis. For example, instead of building out a full feature, run a [fake door test](/tutorials/fake-door-test) to check if users click the option if it’s available.
+
+[MasterClass took this approach](/product-engineers/fixing-growth-problems) when testing tiered pricing. As Alexey, their former former head of growth engineering, said:
+
+>I knew we needed a dollar estimate, so we created a simple fake door test. Users could select their preferred tier – but at checkout, we let them know they were being upgraded to the best tier and at the cheapest price. In reality, this was the existing one-size-fits-all pricing, and we hadn't actually built any of the functionality to support these new tiers.
>
-> For example, adding customizable notifications will get users to return more often, improving retention. After adding the feature, use the metrics you set up in the previous section to validate your hypothesis.
+> This saved us months of engineering time and enabled us to understand how much we could gain if we built this.
+
+
## 3. Prioritize like a growth engineer
-Engineers are like bus drivers, helping move a product along its roadmap toward success. Growth engineers are like Uber drivers, bouncing from experiment to experiment stacking little wins that payoff in the long term.
+Engineers are like bus drivers, helping move a product along its roadmap toward success. Growth engineers are like taxi drivers, bouncing from experiment to experiment stacking little wins.
To understand what their work looks like, let's look at a recent example from our growth team:
-1. **Identify a target area.** Product analytics has seen some massive upgrades lately and we've also added our data warehouse. Onboarding for both these products hasn't kept up, so they identified this as an area to improve.
+1. **Identify a target area.** Product analytics has seen some massive upgrades lately and we've also added our [data warehouse](/data-warehouse). Onboarding for both these products hasn't kept up, so they identified this as an area to improve.
2. **Identify a metric that represents that target area.** They chose the percentage of new organizations that activate, which combines creating a dashboard, analyzing an insight, inviting a teammate, and more. They wanted to improve this metric while keeping retention the same or improving it.
-3. **Create hypotheses.** Dashboard templates help teams get value out of PostHog quickly. They hypothesized that adding a dashboard template to the onboarding flow using actions would lead to better activation.
+3. **Create hypotheses.** [Dashboard templates](/templates?filter=type&value=dashboard) help teams get value out of PostHog quickly. They hypothesized that adding a dashboard template to the onboarding flow using actions would lead to better activation.
4. **Implement as small of an experiment as reasonably possible.** They added a step in the onboarding flow to choose a dashboard template and fill out the variables by creating actions.
-> **Takeaway:** Now it is time to go from post-hoc analysis to proactive prioritization. With your target area, metric, and hypothesis in mind, develop a list of experiments to run that can improve your product. Think about how you can test your ideas in the smallest way possible.
->
-> For example, if you are trying to improve activation by changing the onboarding flow, could you test removing steps instead of adding new ones?
+### How to start prioritizing like a growth engineer
+
+You need to switch from post-hoc analysis to proactive prioritization.
+
+With your target area, metric, and hypothesis in mind, develop a list of experiments to run that can improve your product. Think about how you can test your ideas in the smallest way possible.
+
+For example, if you are trying to improve activation by changing the onboarding flow, could you test removing steps instead of adding new ones?
## 4. Trust the (experimentation) process
-Engineers might see the word "process" and shudder, but being data-driven requires an established process so you can trust the data when making decisions. When it comes to running experiments, growth engineers always make sure to have:
+Engineers might see the word "process" and shudder, but being data-driven requires an established process so you can trust the data when making decisions.
+
+When it comes to running experiments, growth engineers always make sure to have:
1. **A sufficiently large sample size of users.** This ensures you can hit statistical significance AKA your impact is better than random chance.
@@ -85,29 +105,28 @@ Engineers might see the word "process" and shudder, but being data-driven requir
4. **A way to split and log participants.** You want to randomly split test and control groups as well as only log participants in your results. [Feature flags](/feature-flags) help do this.
-> **Takeaway:** Try it! Set up your feature flags and logging. Craft a hypothesis and goal metric. Check that your sample size is big enough and your duration is long enough.
->
-> Going through this process reveals the reality of experimentation. It's not just about shipping changes and seeing what happens, it's a disciplined approach to improvement.
+### How to develop a experimentation process
+
+Try it! Set up your [feature flags and logging](/docs/experiments/installation). Craft a hypothesis and goal metric. Check that your sample size is big enough and your duration is long enough.
+
+Going through this process reveals the reality of experimentation. It's not just about shipping changes and seeing what happens, it's a disciplined approach to improvement.
## 5. Failure is not the end of the world
For a software engineer, failure means bugs, downtime, data corruption, and more nightmare-inducing issues. For growth engineers, it's just another day on the job.
-Many experiments fail. Often, a majority of experiments fail. At [Google](https://hbr.org/2017/09/the-surprising-power-of-online-experiments#:~:text=At%20Google%20and%20Bing%2C%20only%20about%2010%25%20to%2020%25%20of%20experiments%20generate%20positive%20results.), 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
+[Many experiments fail](https://newsletter.posthog.com/i/136043854/you-need-to-embrace-failure). Often, a majority of experiments fail. At [Google](https://hbr.org/2017/09/the-surprising-power-of-online-experiments#:~:text=At%20Google%20and%20Bing%2C%20only%20about%2010%25%20to%2020%25%20of%20experiments%20generate%20positive%20results.), 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
On top of the successes, failures are also opportunities to learn. As the saying goes "it's only a failure if you fail to learn." Rapid experimentation, and the gains it provides, are only possible when you embrace failure.
-> **Takeaway:** To get comfortable with failure:
-> 1. Test both sides of the experiment on yourself first.
-> 2. Test on a smaller group of users before scaling.
-> 3. Keep your experiments small so you feel less bad when they fail.
->
-> Remember, failure is core to being data-driven (the growth engineer's north star). Lying to yourself about what works and what doesn't will only hurt your product in the long run.
+### How to get more comfortable with failure
+
+1. Test both sides of the experiment on yourself first.
+
+2. Test on a smaller group of users before scaling.
-## More good reads
+3. Keep your experiments small so you feel less bad when they fail.
-- [Debugging conversion problems](https://mikebifulco.com/posts/debugging-a-conversion-problem-on-my-nextjs-site) - Mike
-Mike details his ongoing work to improve newsletter conversion on his site.
-- [A software engineer's guide to A/B testing](/product-engineers/ab-testing-guide-for-engineers) - Lior
+Remember, failure is core to being data-driven (the growth engineer's north star). Lying to yourself about what works and what doesn't will only hurt your product in the long run.
\ No newline at end of file
diff --git a/contents/product-engineers/ab-testing-mistakes.md b/contents/product-engineers/ab-testing-mistakes.md
index 1574657db0d0..ce4be6cc3602 100644
--- a/contents/product-engineers/ab-testing-mistakes.md
+++ b/contents/product-engineers/ab-testing-mistakes.md
@@ -18,7 +18,7 @@ Running experiments is equal parts powerful and terrifying.
Powerful because you can validate changes that will transform your product for the better; terrifying because there are so many ways to mess them up.
-I’ve run hundreds of A/B tests, both in my previous life as a growth engineer at Meta, and on my personal side project.
+I’ve run hundreds of A/B tests, both in my previous life as a [growth engineer](/newsletter/think-like-a-growth-engineer) at Meta, and on my personal side project.
These are some classic mistakes I’ve learned the hard way and how to avoid them.
diff --git a/contents/product-engineers/fixing-growth-problems.md b/contents/product-engineers/fixing-growth-problems.md
index 709f91b5fa52..7572be4c77e9 100644
--- a/contents/product-engineers/fixing-growth-problems.md
+++ b/contents/product-engineers/fixing-growth-problems.md
@@ -34,7 +34,7 @@ Slow velocity is usually a result of over-engineering. "Growth engineering is co
First, sit with the engineering team and [prioritize your technical debt](https://alexeymk.com/2021/04/01/a-toolset-for-tackling-technical-debt.html). Figure out what is *actually* slowing you down (or likely to) and by how much. Once you have a ranked list, empower your team to fix it and assign 10%-20% of engineering time to do so.
-Second (and more importantly), urge your team to take shortcuts. The role of a growth engineer isn't necessarily to build features, but to validate whether a feature should exist or not.
+Second (and more importantly), urge your team to take shortcuts. The role of a [growth engineer](/newsletter/think-like-a-growth-engineer) isn't necessarily to build features, but to validate whether a feature should exist or not.
As a team, look at your last 20 experiments and identify which ones you could have validated faster. Thomas Owers, former growth lead at [Let's Do This](https://www.letsdothis.com/), has [good advice](/blog/how-to-start-a-growth-team#thomass-golden-rule-make-your-code-changes-as-small-as-possible) on this:
From d278964b30b5b1eb0178bd82680616f9bafdcfba Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Fri, 27 Sep 2024 13:58:57 -0700
Subject: [PATCH 7/8] add image
---
contents/newsletter/think-like-a-growth-engineer.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
index 0eb69faa1c0d..1f8e8ce10556 100644
--- a/contents/newsletter/think-like-a-growth-engineer.md
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -4,6 +4,7 @@ date: 2024-09-16
author:
- ian-vanagas
featuredImage: >-
+ https://res.cloudinary.com/dmukukwp6/image/upload/growth_think_905cd0fa65.png
featuredImageType: full
tags:
- Engineering
From 9bbd03d92303892b080da37e9c219ef671a3a11c Mon Sep 17 00:00:00 2001
From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
Date: Fri, 27 Sep 2024 14:40:29 -0700
Subject: [PATCH 8/8] date
---
contents/newsletter/think-like-a-growth-engineer.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contents/newsletter/think-like-a-growth-engineer.md b/contents/newsletter/think-like-a-growth-engineer.md
index 1f8e8ce10556..f62c2093957c 100644
--- a/contents/newsletter/think-like-a-growth-engineer.md
+++ b/contents/newsletter/think-like-a-growth-engineer.md
@@ -1,6 +1,6 @@
---
title: How to think like a growth engineer
-date: 2024-09-16
+date: 2024-09-26
author:
- ian-vanagas
featuredImage: >-
@@ -130,4 +130,4 @@ On top of the successes, failures are also opportunities to learn. As the saying
Remember, failure is core to being data-driven (the growth engineer's north star). Lying to yourself about what works and what doesn't will only hurt your product in the long run.
-
\ No newline at end of file
+