Product growth myth busting: Why good growth work can drive product quality
The tension between product growth and quality is common for any team trying to scale usage. But these concepts shouldn’t be misaligned. Good growth work drives product quality, while reasonable definitions of quality should be deferential to metrics.
This note defines what it means to apply a “growth” approach to a product, and ensure it supports quality.
tl;dr
“Growth” means data-driven optimization. We place a laser-focus on increasing a specific metric, and on iterative experimentation backed by a clear hypothesis.
Growth and Quality are two sides of the same coin. People misconstrue growth work as detracting from a focus on our users through hacky, short-term gains, but growing a metric over the long term requires caring about sustainable improvements that drive user value.
“Growth” means data-driven optimization
Product growth is the practice of data-driven, iterative optimization to grow a specific metric. There are a few attributes that differentiate growth from conventional development:
Growth Tenet #1: Data-driven development with a laser-focus on increasing a specific metric.
Growth work starts by enumerating the levers we have to influence the metric, then prioritize work based on what can make the biggest impact on it. Of course, this means that picking a good metric is essential; in fact, I posit it’s the most important decision growth teams make.
Growth Tenet #2: Iterative experimentation backed by a clear hypothesis.
Growth means testing single-changes to an interface. Each experiment tests a specific hypothesis, yielding learnings around what works and what doesn’t. This has a few notable implications:
Hypotheses correspond to the problem you’re solving for users. Aimlessly modifying the UI would get you nowhere.
Not everything you build will deliver impact, but you should view conclusive resolution to a hypothesis as its own success. Quickly wind down invalidated experiments, and use the learnings to inform future work.
Quantity (and velocity) beget quality. You need to test a lot of stuff to deliver meaningful results at scale. To achieve this, you need to move quickly. That means being especially careful to minimize scope and the upfront investment on an experiment in favor of true MVPs. You should also aspire for replicable process that allows us to move quickly.
Growth and Quality are two sides of the same coin
Myth #1: Focusing on metrics detracts from a focus on users
If there’s one misconception to correct, it’s that metrics and quality are in tension. Experiential product quality should be defined as how effectively a product solves user needs and results in positive attitudes toward the product. Metrics are objective ways to measure progress achieving goals, and can help achieve these outcomes.
If your metric represents an outcome that is misaligned with this definition of quality, you need a better metric. Of note, ensure your metric is globally optimal (i.e. represents outcomes that are good for the product holistically) and not locally so (i.e. represents outcomes good for a specific feature, at the expense of your product’s value).
Myth #2: Growth is all about “growth hacking”
Growth hacking implies you trick users into doing something they don’t want to do. This work, sometimes called “dark patterns,” is not only ethically questionable, but also bad for business. Manipulative growth tactics lead to a short term spike that’s eroded in favor of long term churn. Instead, create sustainable growth by tracking long term impact and only shipping things that yield sustained step or angle changes.
This is not to say you shouldn’t employ design changes that are “growthy.” For example, effective CTAs and notifications can be useful tactics! Clear buttons can direct users to take the action in their best interest, while notifications can alert users to something worthy of their attention. Moderation and clear principles ensuring intentionality are key.
Myth #3: Growth thrashes users
Experimenting is a fast and focused way to improve the product. Forgoing any change in favor of stagnation is a path to paralysis where you never make the product better for our users.
It doesn’t come without tradeoffs, but there are many ways to minimize disruption. Consider experimenting on the smallest possible audience within the constraint of sufficient statistical power, or avoiding experimentation on certain key user cohorts (especially if you’re an enterprise product).