For the OKRs of each team please see the team pages e.g. Team Experimentation.
We discuss the OKRs in every sprint planning meeting - the team leads explain progress against each key result.
The basics
- All goals align to strategy
- 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.