How to use goal-setting to turbocharge your team’s output

Co-written by Alexis* and Adrienne

Early in my career, goal setting for my product team used to terrify me. It didn’t help that I* worked for Facebook, a company known for taking goals very seriously. Every six months when the goal setting season came around, I would get stressed about writing the right goal with my team and the fear of failure: what if we set a goal and our team doesn’t hit it? 

Fast forward to 2020, goals have a completely different meaning for me. Rather than a constraint, goals are just a concise expression of two things: a team’s (1) prioritization and (2) speed. Its main function is to communicate a product team’s intentions for the next 6 months across the company. If you’re able to set a thoughtful goal and maintain an environment where the goal is taken seriously, a goal goes a long way influencing a product team’s behavior and output in the way you’ve intended

1. Prioritization

Suppose you’re a PM for the Facebook Pages team. There are several things you could care about: number of Pages, number of users, number of posts, number of commenters. A thoughtful goal aligns the team on a single version of success and a narrow set of ways to get there. Let’s say you set a goal of “100M daily active commenters on Pages.” This signals your team’s thesis that you want to make Facebook Pages successful by way of commenters, and the most impactful thing anyone can do at this time is increasing commenters. This makes it easier for teammates to prioritize work that increases daily active commenters, and even more important, confidently pause projects with unclear returns to that goal. 

2. Speed

The specific metric goal (e.g. 100M) communicates the speed at which teammates should move in a 6 month period. If there are 10M daily active commenters now and the goal is to achieve 100M in 6 months, then the team better move fast. The only way to achieve such an ambitious goal is by making bets on high-risk/high-return projects, and re-evaluating a team's processes to drastically increase efficiency and output. A team may set such an aggressive goal, if they are confident about product market fit and explosive growth is their primary strategy. 

In an alternate world, let’s say the daily active commenters are already at 98M and it’s growing at a healthy rate; and the goal is to reach 100M in 6 months. Here, you’re signaling that the team can move at a steadier pace. Teammates would be incentivized to invest in safer projects with known returns. A team may choose a non-aggressive goal to communicate that they may want to free up capacity for incubating another project in the long term, but not drop the ball in an otherwise healthy product. 

But even after internalizing that goals are just an expression of prioritization and speed, I still found it difficult to be bold. It wasn’t the fear of failure anymore, but it was the natural draw to the familiar. I was sometimes tempted to low-ball the goal target, but I knew that wasn't the right thing to do: that would negatively influence my product team and prevent them from being bold and innovative. So I had to add one more framework to goal setting.  A goal should not only be an expression of prioritization and speed, but also it should scare you. 

Once you set a goal, ask: Does it scare you?

A few years ago, I brought a goal draft to my manager whom I respect a lot. He looked at it and said, “I think you can do more. It’s okay to be scared.” You know a goal is good when it’s scary. Let’s take an extreme example, and say you’re deciding between a 5% growth goal and a 20% growth goal. If a 5% goal sounds solid and accomplishable, then that means it’s not scary enough. While such a goal can keep your team’s morale high and allow you to celebrate small wins, the flip side is that it doesn’t push your team’s thinking. You could probably achieve 5% growth by doing what you were always doing. However, if the goal is 20% growth, then your team is forced to think beyond existing frameworks, must question prior assumptions and experiment with new solutions. This is the behavior you want to incentivize.

Looking back, I realized I was terrified by goals because I felt attached to the outcome of trying to hit a goal. I also realized that I could never 100% control the outcome, but I could still work with my team to set the most thoughtful and ambitious goal possible, and create a safe environment for my talented teammates to fearlessly charge towards it. At the end of the day, goals are a powerful mechanism for influencing a product team’s behavior and output.