--- title: Prioritization sidebar: Handbook showTitle: true --- 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. ## 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.
Enthusiast Startup Scaleup Enterprise
Engineers / PMs with technical expertise Scalability
Advanced analytics
Scalability
Advanced analytics
Non-technical PMs, marketing, sales, business Too technical Too technical
Feature set / integrations
Too technical
Feature set / integrations
Too technical
Feature set / integrations
Analysts Direct SQL access
Plugins for data lakes
Direct SQL access
Plugins for data lakes
Enterprise procurement SOC 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.
Enthusiast Startup Scaleup Enterprise
Successful products Low (1/5) Very high (5/5) High (4/5) Low (1/5)
Revenue Low (1/5) Mid (2/5) High (4/5) Very high (5/5)
Combined Low (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
Enthusiast Startup Scaleup Enterprise
Engineers Maintain Build Build Build
Non-technical roles Maintain Maintain Maintain
Analysts Maintain Build Build
Enterprise procurement N/A Build
## 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:
Enthusiast Startup Scaleup Enterprise
Global successful products 10m 1m 10k 10k
Global revenue $0 $240m $500m $4B
Additional successful products from feature 0% 5% 5% 10% 51.5k
Additional revenue from feature 0% 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.