Youre Doing Quarterly Planning Wrong
Engineers often dread the end of the quarter because it means one thing: quarterly planning. This can mean weeks of prep and tedious meetings, all of which distract from the actual work of shipping a product. With 26 small teams (and counting), we end up running quarterly planning a lot. We’ve had many opportunities to make mistakes and learn from them. We're sharing these lessons here, so you can learn faster than we did.
1. You don’t need the perfect planWe preface this entire piece with some wisdom written by our favorite generic exec, Charles, in our handbook:
Many engineers get stuck trying to make their goals perfect. They fail to realize that accomplishing goals isn't what matters; it's shipping a product that's valuable to users. Don't let wording, or picking a metric, block you. There are two lessons to take from this. The first is to not spend too much time planning. Our quarterly planning meetings take 60 to 90 mins max. About 20% is reviewing the past and 80% is talking about goals for next quarter. Prep takes about an hour and is entirely async. This means less time spent in meetings. 🥳 The second is not being afraid to change goals midway through the quarter. Sometimes we get our goals wrong and that's ok. Circumstances change, delays happen, engineers need the freedom to adjust.
We’re big fans of making important changes as quickly as possible. Team changes are announced in Slack, we test in production, we get MVPs in the hands of users. When a team realizes they need a different goal, they have the autonomy to change it themselves and immediately start working on it without an elaborate “change of goals” process. Again, it's not about perfectly matching the original goals set, but building a great product. It's better to change a goal to something useful than be stuck working on something useless because you said you would two months ago. 2. You have to prepare asynchronouslyGoals planning can really go off the rails in meetings, especially if:
Done like this, goals planning drags on forever and you end up rushing the important bits (i.e. what your goals should be) because you’ve sucked up a bunch of time thinking aloud and arguing about details.
We avoid this by ensuring that everyone writes down what they think before the meeting in a single shared doc that includes:
People can then read what everyone thinks, ask follow-up questions, and pitch ideas before the meeting, instead of arriving with zero context. As a result, our quarterly planning meetings are about discussing the thinking that's already been done, and making decisions. It’s more efficient, fun, and satisfying. 3. Avoid obsessing over metricsIn 2022, we required “OKRs” as part of quarterly planning, but eventually walked it back. We found engineers were agonizing over finding the right metrics, while also feeling like metrics didn't accurately reflect their subjective view of progress. We also realized that after setting OKRs, engineers would go off and figure out what to build. They needed to translate an OKR into a plan they could work on. It's a lot clearer and faster to just write that down instead. Even if you are forced to use OKRs, writing down a plan is still useful for guiding your work. We learned that setting OKRs just because “Google does it” doesn't mean it's the right thing to do. Teams are now free to set goals and measurement methods, including using precise metrics (even OKRs) where appropriate. This has resulted in team goals that focus more on "what we'll ship" like this:
This type of goal better aligns with our overall goal of shipping a great product that equips every developer to build successful products, not just making a number on a graph go up. 4. Focus on what you’re going to shipThere are a lot of traps to fall into when setting goals such as:
At PostHog, we mostly focus on things we'll ship. We try to have as few of these as possible and call out the areas we don't want to work on (anti-goals). Some examples of goals from Q2 2025 include:
Some might say these goals are "too vague" or "don't count as OKRs." Our response is that they work for us 🤷♂️ and that's what really matters. These goals support our focus on shipping things and getting feedback from users rather than obsessing over wording or arbitrary metrics. As a checking mechanism, we run monthly growth reviews for every product that look at key product and revenue metrics, like usage, MRR, retention, and NPS score. Teams can then adjust their goals if what they’re working on isn’t having a positive impact on things they care about most. 5. Don’t ignore your plan after writing itQuarterly planning is only as useful as the progress you make on it. If you're not checking in on your progress, you can't know if you'll be successful. Our teams are constantly checking in and referencing the goals they set. The main place they do this is in our biweekly engineering sprint planning. These check-ins include each goal and its current status:
Action points are required for any goal marked yellow or red.
Regularly checking on progress means:
6. Letting others own your planEarly in PostHog's life, an engineer wanted to build session replay. Our co-founder James thought it was a terrible idea. The engineer built it anyway and it ended up being wildly successful and changed the direction of the company. Since then, engineers are in charge of figuring out what to build. Neither execs nor product managers tell engineers what to build. It's up to engineers to decide, but this means they need to form a strong opinion of what they want to build. When it comes to quarterly planning, our process looks like the “W framework” created by Lenny Rachitsky and Nels Gilbreth. This process encourages teams and execs to work together in planning like this:
This process creates enough direction to make both the company and the small team successful, while also giving teams the ownership and autonomy to make product decisions for themselves. More mistakes to watch out for:
Words by Ian Vanagas, aka Ian Planagas. 🧠 More good reads for this quarter (or next)
|
