PostHog Handbook Library

655 words. Estimated reading time: 3 min.

# Why does PostHog exist? Our mission and strategy

### Our mission

Equip every developer to build successful products.

### Why is that our mission?

Since the beginning, we've believed that engineers should be way more involved in making product decisions than they've been historically. In order to help them do that, we've built a collection of tools for engineers.

Similar tools to the ones we've built have existed for a long time, but they were always built with other users in mind. By building things like product analytics, session replays, feature flags and a data warehouse for engineers first, we give engineers the ability to make product decisions themselves. This massively increases the speed at which engineers can make good decisions.

The other way PostHog helps engineers is by combining _all_ the tools they need into one product. This avoids a ton of work integrating and linking up various products, both when integrating and ongoingly.

We try to help engineers from the very beginning, when their product is just being built. We do that by having generous free tiers, and no need to talk to sales to get started.

### Our strategy

#### 1. Be the source of truth for all product context

Building a successful product is hard; doing so when you don't understand your customers is even harder. It's wild that no one has already provided a complete record of everything engineers need to ship products. This has happened because the entire industry has focused on integration instead of consolidation.

Traditionally, as companies scale, their data warehouse becomes the source of truth, and non-warehouse native tools (like product analytics) become less relevant as engineers lose trust in the data they collect, simply because they are misused and divorced from the source of truth. Every company winds up with a huge mess of data spaghetti, with their business logic still spread across dozens or hundreds of tools.

We provide developer infrastructure - by providing _every_ tool engineers need in one place, we can:

- Enhance the utility of all the tools when used together by engineering teams
- Increase trust in data by eliminating complex data stacks that engineers have to navigate
- Automate everything better than anyone else can, by using AI across this wider context
- Continue to provide all the tools engineering teams need as they grow

#### 2. Provide every tool engineers need to build successful products

We aim to offer every tool engineering teams need to debug, understand, and improve their products. From session replay for debugging to feature flags for safe deployments, we help engineers ship better code faster.

We can then get our AI to work across all of them together, whilst making every individual tool cheaper than the rest of the market - since we provide so many we can charge less. This means engineers get better tools at a fraction of the cost of piecing together solutions from multiple vendors.

#### 3. Get in first

Since developers exist first in a startup, by getting in with them early, we are naturally upstream of every other tool they might have considered using. Although anyone can pick up our products (and lots of mature companies certainly do), this means we can best deliver developer infrastructure to early stage companies, and so should focus there by default.

_Once_ we land a customer, we then let them pull _us_ upmarket as they grow. But not before. We don't want to hire a big enterprise sales team and go upmarket before our existing customers are there. This keeps us efficient and able to stay focused on building tools that engineers actually want to use.

#### 4. Automate the iteration process

Because we have all the context on both users and the product, we can automate large chunks of the cycle of shipping -> observing -> iterating.

### Secret master plan

- Ship every tool and all the data that engineering teams need to understand their product and users
- Use that to speed up the cycle of shipping -> observing -> iterating
- Eventually, automate the entire cycle

Canonical URL: https://posthog.com/handbook/why-does-posthog-exist

GitHub source: contents/handbook/why-does-posthog-exist.md

Content hash: `826a47e11c0afe3c`