PostHog Handbook Library / Company

924 words. Estimated reading time: 5 min.

# Setting quarterly goals

We plan objectives every quarter. The set the direction and overall objectives for PostHog, and then small teams set their own objectives that feed into these. Longer-term planning that the Blitzscale team does is covered separately in the annual planning guide.

### How quarterly planning works

1. ~3 weeks before the end of each quarter, the Blitzscale team meets to come up with larger goals for the company, which sometimes (but not always) trickle down to individual teams.
2. ~2 weeks before the end of the quarter, team leads should schedule planning meetings to go through these - these will be run by the team lead and include the relevant Blitzscale team member, following the template below. Each small team can change or propose alternate objectives, goals, and/or key results (we are not prescriptive about the exact terms used here - use these as a starting point).
3. After the planning meeting, the team lead creates a PR on their small team page with the new goals. Make sure you tag the relevant member of the Blitzscale team for review at a minimum.
4. Goal PRs need to be merged before the next quarter starts. We usually then run through the objectives in the first all hands of the next quarter.

In terms of accountability, Scott Lewis will notify all the small teams and make sure that the quarterly meetings happen (and that each small team has a PR), but he will not schedule the meetings for you.

> If you prep properly (see below), planning meetings should take 1 hour max. The meeting is not the end of the process - you may still have some back and forth on the PR, but the meeting should give the team lead enough info to write a good PR.

#### Planning template

Teams should fill in the previous quarter reflection async in the doc before the meeting starts. HOGS should be written privately and independently, in your own notes rather than the shared doc, then pasted in at the start of the session. Doing them privately first stops people from being skewed by each other's thinking before they've formed their own view. The meeting itself should be 20% reviewing the past, and 80% talking about goals for next quarter. Don't fall into the trap of spending most of your time reviewing and then rushing the goals right at the end.

    ## Last quarter objectives reflection (5 mins - do as a team)

    [Paste in previous quarter objectives from the team page]

    For each objective, write up a reflection - usually the person who was the lead on the objective should do this, but some might be shared.

    What else did we get done? List items from the changelog or PRs merged if they were significant items that deviated from the original goals (changing goals mid-quarter is okay!)

    You may also want to write some overall thoughts about how the quarter generally went.

    ## HOGS (10 minutes, written privately beforehand and pasted in at the **start** of the session)

    Everyone should write their HOGS **privately and independently** before the meeting, in your own notes rather than this doc, then paste them in at the start of the session. Keeping them private until then means people don't anchor on each other's thinking. Spend 10 minutes in the meeting silently reading through everyone’s HOGS during the meeting. Add any common themes or otherwise important items to the section below as you read, then only discuss the themes (there generally isn't time to discuss every line of the HOGS).

    Add entries under each question with your initials/name like: "- (your name): My comment"

    - Hope
      - What are you most excited about this quarter?
      - What exploration do you want to do?
      - For Error Tracking/Session Replay/Experiments/Conversations/Experiments/Conversations/Product Analytics/AI Observability:
        We want to make PostHog proactive. How do we programmatically emit signals - i.e. research prompts for an agent with code access & PostHog MCP – that will result in quality concrete code changes?
    - Obstruction
      - Is there anything embarrassing about your product?
      - What’s stopping you from shipping 2x what you’re shipping now?
      - Can your product be used by agents (Claude Code/Cursor/etc.) via our MCP server? What MCP tools or skills are missing right now?
    - Growth
      - What single thing would move the needle the most this quarter?
        - _If it’s more people, please expand on how many and exactly what type of hire you’d be looking for._
      - What are users asking for? Which of these are we ignoring?
        - _Check Vitally for feature requests (if applicable for your team/product)_
      - How will users interact with your product in 1 year's time and what can we do now to get this ready?
    - Sneak attack
      - Say a competitor beats your team’s product, what would that product do differently?
      - What are we not talking about enough?

    ## Themes (20 minutes - do as a team)

    What themes can we distill from the above HOGS list? What are categories of things we should consider working on? What are other things we might want to consider?

    ### Other things to consider

    - For engineering teams - did you do anything cool last quarter that other engineers could learn from? Consider adding a goal to [write about those things on our company blog](/handbook/engineering/writing-blogs)!
    - Have you done a pricing review for this product in the last year? If not, follow our [RFC template](https://github.com/PostHog/requests-for-comments-internal/blob/main/_TEMPLATES/request-for-comments-pricing-review.md) to do a pricing review this quarter.

    ## New goals (15 minutes - do as a team)

    This is an example - feel free to adapt as you need. Generally it is a good idea to have at least one person's name against each thing for accountability even if multiple people work on it - shared goals usually results in less getting shipped.

    Objective 1: PostHog in the EU
    Motivation: Unblock 1,000s of customers [link to data] who need to keep data in the EU but are not capable of self hosting.
    What we'll ship:
      - This thing (Name)
      - Another thing (Name)
      - Maybe another thing (Name)

If you aren't on a product team, replace 'product' with the equivalent 'thing' on your team - e.g. if you do recruitment, your 'product' is how we do recruitment at PostHog and your users are job applicants.

### Publishing and viewing goals

When a team has set their quarterly goals it is the responsibility of the team lead to document the goals on their team page, publicly. This enables teams to see what each other are working on, helps us hold teams accountable to their goals, and creates a shared sense of urgency and direction.

You can easily see what goals teams have set on the WIP page, which pulls all goals from the respective team pages.

Teams can choose to document their goals publicly in a number of formats, but below is a useful template for getting started. Individuals may also choose to create planning issues to track their work in greater detail.

    <details>
    <summary>Write the goal here (owner)</summary>

    - **Rationale:** Why is this important?
    - **What we'll ship:** Keep this brief
    - **We'll know we're successful when:** Metric or outcome

    </details>

### Good goal setting

- As few objectives as possible
- Motivation - explains why the objective is set
- Things we'll ship that show if we're en route to achieving an objective
- Objectives are simple - it's really clear if you are/aren't hitting them
- Objectives are ambitious - they move the needle for PostHog
- Hitting an overarching objective is more important than shipping specific things
- Things we'll ship are leading indicators and can be achieved quickly
- If you set specific targets, they should be specific and measurable if possible
- Setting anti-goals can be helpful to clarify what you are _not_ working on

Bear the following in mind:

- Use metrics only if they help you. Goals should be primarily output-based - the actual things that we will do and build.
- Don't fall into an existential crisis every time we do this exercise - while objectives are important, they're easy to change, so iterate if you need to mid-quarter
- All objectives are bad - they have many compromises, are fallible, easy to game, or may be affected by external factors, so use the least bad ones
- Use counter metrics where needed (X happens, but Y shouldn't happen)
- Don't have a lot of things to ship if you can't capture everything in one - just pick the most important one or two
- Don't set arbitrary targets that a team cannot achieve
- Consistently hitting ambitious objectives over the long term is an important factor in the pay review process, but if you miss extremely tough objectives and still achieve great things en route, that's also fine

### FAQ

#### What if I don't have time to do work towards my objectives because of customer support/urgent board reporting/something else?

Picking up the occasional thing that isn't technically going to help your goal is ok. This is because we're small and may not set 100% perfect goals. As ever, prioritize as you see fit. However, spending a bunch of time on a pet project is not - this means the planning process has failed.

### If my team repeatedly miss objectives, what happens?

Objectives should be ambitious but achievable - you should be able to hit them by challenging yourself, but not to the point of burnout. If your team is consistently missing objectives, they are too hard or possibly the wrong objectives for PostHog/your team.

Canonical URL: https://posthog.com/handbook/company/goal-setting

GitHub source: contents/handbook/company/goal-setting.md

Content hash: `f002113ac7f3dc94`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: SmallTeam, TeamMember.