How to Do Healthy Product Growth Work
The purpose of this note is to lay out a philosophy to grow a product by focusing on user value (as opposed to hacks) and to explain why this type of growth is inextricably tied to a deep understanding of people-problems.
Imagine that your manager just told you that your team needs to buckle down and “focus on growth”. Your stomach churns. You begin to imagine the magnificent product work you had planned for the future flying out the window, never to be fully realized. All of the negative connotations that follow the word “Growth” start circling in your head: hacky, unprincipled, metric-obsessed, low-quality…the list goes on. You wonder when we’ll get back to “real” product work.
“Healthy” growth not only doesn’t look anything like the type of work you may imagine in the scenario above, and is even something worth being excited about if you want to bring the value of your product to more people throughout the world. The sad part is that many of the descriptions in the previous paragraph are well-deserved when people and teams lose track of why they are trying to grow their product (and the metric(s) they think represents the value of that product): to solve a problem in people’s lives that their product can do better than any other.
I believe in healthy growth as a way to unlock product value for people, so in this note, I’ll share my approach in 3 steps:
- Decide how you’ll measure user value.
- Build a map of how people get value from your product.
- Involve all roles in driving growth.
1. Define and Measure User Value
Before doing any growth work, you first need to understand 1) what value people get from your product and 2) how you’ll measure success at scale. (1) is defining the value that your product drives, it should ideally be done before you code anything and written down in your PRD, and requires extensive thinking and research. Basically, (1) takes time and is a topic in-and-of itself, but this note will focus on (2) (but please, if you haven’t defined and understood the value of your product, don’t move on to step 2). Because growth work requires iteration you need to experiment and hypothesize quickly, and in order to do that you need near instant feedback from people on the features and systems that your team builds. Enter: metrics.
In order to have coherent conversations across your team, XFN partners, and the key stakeholders in the company, you need a north star metric for your product. While it’s usually impossible to capture the value your product provides in one clean metric, it’s important to have a primary metric that gives you a quick view as to whether or not you’re headed in the right direction.
In addition to a north star goal metric, you’ll want to create a set of operational metrics and counter-metrics throughout your growth funnel to understand whether or not the metric is growing because people are finding value or simply because you’re overwhelming them with opportunities to engage with your product. I like to have one operational metric and counter-metric for each stage of the funnel to ensure you and your team can quickly diagnose what’s broken and how new features help (or don’t).
A simplified example from Facebook Live (the product I first worked on when I joined Facebook). With Facebook Live we were trying to connect more people to what’s happening in the world around them right now. A north star metric could be “Live Watch Time” (amount of minutes people watch content while it’s live). While this metric is helpful (if people are watching it, it’s likely valuable), you could also imagine a scenario where the metric would go up but people aren’t actually deriving value (e.g. seeing far too much Live content in their News Feed would increase Watch Time but wouldn’t mean that people were getting value from it). A counter-metric like “watch time per video viewed” would ensure that when someone does see a Live Video, it’s valuable to them.
2. Build a Map of How People Get Value from Your Product
Now that you have metrics to see if people are getting value, many people will just start throwing darts against the board, but this is the wrong way to start a growth effort. Most of the things you try won’t work (which is fine) but, what’s worse, when something does or doesn’t work you won’t have a clear understanding of why it worked and what you should do next. In order to avoid this state, healthy growth starts with a deep understanding of people’s behavior, the ecosystem that we place them in, and the people problems that arise out of this combination.
Every product is (or at least should be) created to bring value to people. Growth work is about understanding what that value chain is, where it breaks down, and how to fix and/or create it. In order to build that value chain, you need to blend the knowledge of what people think and want synthesized (qualitative, from User Research) with the behavioral data of what people do with your product (quantitative, with Data Science) to identify where your features may be inefficient, falling short, or simply not yet exist to address a need.
Putting it into practice, let’s go back to the Facebook Live example and break down the value that we are trying to drive (Live Watch Time) into the reasons why people didn’t find value from the product so that we can better understand how to attack the problem. Within each problem, we create a MECE view of all of the reasons that the described scenario may be true. The interim outcome of the above process would look something like the below (all numbers are made up and this view is a bit thin, but it should give you an idea of how to do this work).
A simplified view of how we may break down why people who were interested in the Live content available did not watch it
Once we have this view, we can understand how big a certain problem is and prioritize our time accordingly. Now that we’ve broken down the problem into its core components (not fully in the example above, but you get the point), we can size out where we should focus more of our efforts. For example, we may learn that the main reason people don’t watch Live content is because people simply aren’t connected to Pages that go Live. This discovery means that any strategies based on the assumption that we’re simply not delivering content well when someone is connected to a Page wouldn’t be as impactful as discovery work and therefore should be deprioritized.
3. Involve All Roles In Driving Growth
Now that you have a way to measure success and a skeleton of user value to help you identify and prioritize problems, you can start executing! A key mistake I see teams make is to leave all the execution to the Engineers; execution requires all roles on the team to pitch in.
User Research helps us understand and develop vocabulary around what problems people are facing which improves the visual model of the value chain above that we have. If you’re having trouble figuring out what the branches are in the value chain visualization above, start with your User Research team and listen to what people are telling you. If you have a good sense of what the branches are but aren’t sure where those problems show up (which blocks you from analyzing data), have researchers dig into specific flows and tasks with people to see how they approach it.
Design, in addition to driving the vision of how new features can work, can also break features and flows into components to help the team hone in on where our products don’t fully meet the needs of the people who use them. If you see poor performance in a certain area, work with your designer to understand how each component is supposed to help the person get the value that they want and then think through ways to tweak components in the flow to test your assumptions. For example, if you see that people aren’t sharing Live Broadcasts, is it because they don’t know how to start, know how but can’t complete the action, can complete it but don’t know what will happen when it’s done, or don’t want to share in the first place. Each part of the flow can influence these aspects and therefore different experiments are needed to test.
Data Science can help understand how a certain experiment impacts people, but more importantly they can identify problems that people have and size how large those problems are, both of which help teams prioritize the highest impact work. If you have a sense of what problems to solve but don’t know where to start, work with Data Science to validate/invalidate hypotheses as to how people could get more value out of your product.
Engineering obviously can build the experiments to validate whether or not hypothesized levers are real, but they can also look into the technical aspects that are hampering growth (like load time). One thing that engineering can quickly help with is a “headroom test”. Depending on your testing capabilities (and depending on what feature you’re testing…you don’t want to create a poor user experience), you can run a headroom test to see how valuable a lever is. For example if you’re trying to grow app installs and aren’t sure if it’s top of the funnel or bottom of the funnel, you could amp up advertising at the top of the funnel to an unsustainable amount to see what the best case scenario is of fixing your advertising conversion. If even the unsustainable amount of impressions doesn’t help, you should start your efforts elsewhere.
Summary
Assuming you have defined the value that people can get from your product, the 3 general steps above should provide a framework to get your product from used by some to valued by many. Let me know what I missed in the comments!
