6.5 KiB
| title | sidebar | showTitle |
|---|---|---|
| Prioritization | Handbook | 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:
- Increase the number of successful products in the world
- 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:
- Estimate the number of successful products that could come out of each category globally (example numbers given)
- Estimate the amount of revenue we could grab from those categories (example numbers given)
- Estimate how many of the successful products we could create if we had this feature
- Estimate how much revenue we could get if we had this feature
- 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.