• Product
  • Pricing
  • Docs
  • Using PostHog
  • Community
  • Company
  • Login
  • Table of contents

  • Handbook
    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Small teams
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
    • Team structure
    • Customer Success
    • Exec
    • Experimentation
    • Growth
    • Infrastructure
    • Marketing
    • People & Ops
    • Pipeline
    • Product Analytics
    • Session Recording
    • Website & Docs
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Side gigs
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • How to interview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Working with product design
      • Releasing a new version
      • Handling incidents
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • How-to access PostHog Cloud infra
      • Developing the website
      • MDX setup
      • Markdown
      • Jobs
      • Overview
      • Data storage or what is a MergeTree
      • Data replication
      • Data ingestion
      • Working with JSON
      • Query performance
      • Operations
        • Overview
        • sharded_events
        • app_metrics
        • person_distinct_id
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
    • Overview
    • Product metrics
    • User feedback
    • Paid features
    • Releasing as beta
    • Our philosophy
    • Product design process
    • Designing posthog.com
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
    • Growth reviews
  • Table of contents

  • Handbook
    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Small teams
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
    • Team structure
    • Customer Success
    • Exec
    • Experimentation
    • Growth
    • Infrastructure
    • Marketing
    • People & Ops
    • Pipeline
    • Product Analytics
    • Session Recording
    • Website & Docs
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Side gigs
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • How to interview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Working with product design
      • Releasing a new version
      • Handling incidents
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • How-to access PostHog Cloud infra
      • Developing the website
      • MDX setup
      • Markdown
      • Jobs
      • Overview
      • Data storage or what is a MergeTree
      • Data replication
      • Data ingestion
      • Working with JSON
      • Query performance
      • Operations
        • Overview
        • sharded_events
        • app_metrics
        • person_distinct_id
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
    • Overview
    • Product metrics
    • User feedback
    • Paid features
    • Releasing as beta
    • Our philosophy
    • Product design process
    • Designing posthog.com
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
    • Growth reviews
  • Handbook
  • Strategy
  • Objectives

Objectives and key results

Last updated: Oct 21, 2022

On this page

  • The basics
  • How to set OKRs
  • Three ways we approach goals differently at PostHog
  • How you can help
  • Further reading: musings about metrics

Our mission is to

"Increase the number of successful products in the world."

Our vision for 2023 is:

“Everyone building a product has a clear path to making it successful without losing control of their data.”

Our Q4 2022 company wide objective:

Average 11% Month Over Month revenue growth through Q4 2022.

For the OKRs of each team please see the team pages e.g. Team Experimentation.

We discuss the OKRs in every all hands meeting - the team leads explain progress against each key result.

The basics

  • Everyone has goals they can remember
  • Everyone can control their goals
  • Focus on things with short feedback cycles
  • The goals we choose should stretch us

How to set OKRs

Objectives ('O') are what you're trying to achieve. "Ship 3 blog posts" is not an objective. "Build a blog we're proud of" could be.

Key Results ('KRs') are signs that we're en route. You may end up missing all Key Results, but hitting your Objective.

Three ways we approach goals differently at PostHog

  • Don't be bureaucratic. We can go into detail trying to get goals written out perfectly. If it won't materially change what people do, it's wasted energy.
  • For teams writing software, we've had better results from focussing on inputs ie ("Get X feature used by Y companies") or ("Complete SOC2") rather than outputs ("Improve retention of funnels by 10%"). Do consider you can go halfway ("Get 5 paying customers using X feature").
    • This differs from much of the generic guidance, largely created at places like Google with millions of users. We think this is because much of what we work on is v0.1 not v2. We're adding huge new features consistently, so we're not making slight optimizations in most cases.
    • Spending a week thinking about OKRs and making assumptions around how inputs will connect to outputs is better than spending half the quarter thinking about what we should do. Shipping stuff and seeing what happens will often give clearer answers than planning.
    • This isn't the case for "Go to Market" or GTM teams. We have been successful targeting ie "Average 700 new company sign ups a week" or "Add 3 x $20-70K/year customers per week". These are just way easier to make meaningful.
  • There is a narrative added to each goal. This gives context for why it matters. This helps in case the goal isn't right.

How you can help

  • Give direct feedback to a team member if there is working happening that doesn't help with goals. (Unless it's small and obviously valuable in some other way)
  • If your goals feel detached from what is important say something proactively.

Further reading: musings about metrics

  • All metrics are bad. They include both clear and hidden compromises which means they will not capture some of the
  • Use the least bad metric. Accept and call out risks.
  • Nothing is important if everything is important. Don't have lots of metrics.
  • Don't pick Key Results if we can't already measure them. If a Key Result involves a metric "TBD", then we'll never get around to measuring it.
  • You can iterate on metrics.
  • You don't need a target at first - measure for one cycle, then target later. Change goals.

Questions?

Was this page useful?

Authors

  • Paul Hultgren
    Paul Hultgren
  • Paul D'Ambra
    Paul D'Ambra
  • James Hawkins
    James Hawkins

Share

Jump to:

  • The basics
  • How to set OKRs
  • Three ways we approach goals differently at PostHog
  • How you can help
  • Further reading: musings about metrics
  • Questions?
  • Edit this page
  • Raise an issue
  • Toggle content width
  • Toggle dark mode
  • Product

  • Overview
  • Pricing
  • Product analytics
  • Session recording
  • A/B testing
  • Feature flags
  • Apps
  • Customer stories
  • PostHog vs...
  • Docs

  • Quickstart guide
  • Self-hosting
  • Installing PostHog
  • Building an app
  • API
  • Webhooks
  • How PostHog works
  • Data privacy
  • Using PostHog

  • Product manual
  • Apps manuals
  • Tutorials
  • Community

  • Questions?
  • Product roadmap
  • Contributors
  • Partners
  • Newsletter
  • Merch
  • PostHog FM
  • PostHog on GitHub
  • Handbook

  • Getting started
  • Company
  • Strategy
  • How we work
  • Small teams
  • People & Ops
  • Engineering
  • Product
  • Design
  • Marketing
  • Customer success
  • Company

  • About
  • Team
  • Investors
  • Press
  • Blog
  • FAQ
  • Support
  • Careers
© 2022 PostHog, Inc.
  • Code of conduct
  • Privacy policy
  • Terms