Prioritization

Last updated:

As there is a lot of autonomy at PostHog, it's useful to have a common framework for how to make prioritization decisions.

Our mission

Our mission is to increase the number of successful products in the world.

To achieve this, we will need revenue to be able to re-invest into making a better product.

Our vision (for 2023)

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

Our current focus / milestone

We're currently focused on "Nailing Funnels"

How do we shift focus between priorities?

We want to move fast and make sure we’re always focused on building what pushes us towards our vision. However, we also recognize that rapidly changing course or excessively pivoting can lead to incomplete or ineffective features and be demotivating.

We’re always looking to make the right decisions for the long term. However, we don’t believe in planning too far ahead as we’re continuously gathering new context.

After we’ve made significant progress towards our current milestone we will build a clear understanding of what we need to focus on next and why, at the end of each sprint we’ll ask ourselves if we’re likely to achieve the goal of our current milestone in the coming sprint. If so, we’ll also start preparing the context we need to move on to our next focus in the following sprint.

How is our product/market fit?

Below is a table of how we see our product/market fit for various sizes of companies and various job roles.

EnthusiastStartupScaleupEnterprise
Engineers / PMs with technical expertiseScalability
Advanced analytics
Scalability
Advanced analytics
Non-technical PMs, marketing, sales, businessToo technicalToo technical
Feature set / integrations
Too technical
Feature set / integrations
Too technical
Feature set / integrations
AnalystsDirect SQL access
Plugins for data lakes
Direct SQL access
Plugins for data lakes
Enterprise procurementSOC 2
VPC

As you can see, we have good product/market fit with engineers generally, and specifically for enthusiasts and startups.

Value

Now let's look at how building things for the different size companies helps us achieve our two goals:

  1. Increase the number of successful products in the world
  2. Increase revenue so we can re-invest in #1

Given scores from 1-5, here's how each type of company stacks up against those two values.

EnthusiastStartupScaleupEnterprise
Successful productsLow (1/5)Very high (5/5)High (4/5)Low (1/5)
RevenueLow (1/5)Mid (2/5)High (4/5)Very high (5/5)
CombinedLow (1/5)High (3/5)High (3.5/5)High (3/5)

Putting it together

When thinking of building a new feature, we can combine the product/market fit table and the priority table into one.

We have three options for each box:

  • Deprecate: stop supporting
  • Maintain: fix bugs but don't introduce new features
  • Grow: fix bugs, do marketing and make PostHog easier to get started with but don't build new features.
  • Build: all of the above + building new features specifically for these categories
EnthusiastStartupScaleupEnterprise
EngineersMaintainBuildBuildBuild
Non-technical rolesMaintainMaintainMaintain
AnalystsMaintainBuildBuild
Enterprise procurementN/ABuild

Comparing features

If you're trying to decide between two things to work on, a useful exercise can be the following:

  1. Estimate the number of successful products that could come out of each category globally (example numbers given)
  2. Estimate the amount of revenue we could grab from those categories (example numbers given)
  3. Estimate how many of the successful products we could create if we had this feature
  4. Estimate how much revenue we could get if we had this feature
  5. Repeat steps 1-4 for the feature you're trying to compare

For example, for our virtual private cloud feature we came up with the following numbers:

EnthusiastStartupScaleupEnterprise
Global successful products10m1m10k10k
Global revenue$0$240m$500m$4B
Additional successful products from feature0%5%5%10%51.5k
Additional revenue from feature0%15%15%30%$1,311m

The point of this exercise is not to come up with the 'correct' numbers. The point is to go through a thought exercise that'll help you figure out the impact of what you're working on.

The idea also isn't that you should do this for every feature you build. Instead, you'll now have a framework for how to think about the impact of what you're building.