yindo/posthog.com
1
0
Fork 0
mirror of https://github.com/BillyOutlast/posthog.com.git synced 2026-02-04 03:11:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

DRAFT: redo ICP (#12802)

Browse Source 
* DRAFT: redo ICP

* Update contents/handbook/why-does-posthog-exist.md

Co-authored-by: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com>

* Update contents/handbook/why-does-posthog-exist.md

Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>

* Update contents/handbook/who-we-are-building-for.md

Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>

* Rewrite why

---------

Co-authored-by: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com>
Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>
This commit is contained in:
timgl
2025-10-06 13:36:21 +01:00
committed by GitHub
parent 18acb60465
commit 7eaacb06f3
3 changed files with 36 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
contents/handbook/which-products.md
View File

@@ -3,7 +3,6 @@ title: Deciding which products we build
sidebar: Handbook
showTitle: true
---
Providing all the tools in one is a core part of our strategy.
Shipping them in the right order is key to a fast return on investment from every new product.
@@ -41,14 +40,11 @@ Products we build into the platform must:
Ideally, but not necessarily, products we build should:
* Help customers to build more successful products. This doesn't _just_ mean writing code, it means commercial stuff too.
* Help us to offer all the tools in one - help us to, as quickly as possible, cover the "major" pieces of software that every startup uses.
* [Equip developers to ship successful products](/handbook/why-does-posthog-exist#our-mission)
* Specifically, any product that either helps them ship faster, or gives them more context to ship products without help from others.
* Help us to get in first - some tools are adopted earlier in the customer lifecycle than others. Starting with these avoids customers moving to competitors' products, then us having to migrate them over.
* Help us to be the source of truth - some products are great at providing additional data, or working on top of the existing data PostHog stores. This means your product will probably help make multiple other products more powerful.
* Increase the amount of data inside of PostHog. In some cases, that means building the product when we can get a large % of our users to switch over (like error tracking, logs), in other cases it just means integrating when switching costs or infrastructure requirements are high (like a production database, an auth product)
* Increase our luck surface area - some products have more upside than others, for example, API access may yield surprising results compared to a super narrowly scoped new product like a cookie banner product.
* Be very easy to integrate and turn on for existing customers. For example, users can enable the product without a code change.
* Have crappy competitors - successful companies but horrible products and/or sales experience.
![a diagram showing which products we could build in which order](https://res.cloudinary.com/dmukukwp6/image/upload/v1710055416/posthog.com/contents/images/product-order.png)
At earlier stage companies, technical founders will do _every_ role, so tools traditionally used by those further from engineering (i.e. support) are likely to get usage if built into PostHog's platform. In later stage companies, we need - for now - to remain closer to engineering tools. Do not be afraid of shipping non-traditional "engineering" oriented products.

17
contents/handbook/who-we-are-building-for.md
View File

@@ -4,7 +4,11 @@ sidebar: Handbook
showTitle: true
---
We build for the highest-performing **product teams** (engineers, PMs, designers) building the **most-loved products** at **high-growth startups**. This is our [ideal customer profile](/newsletter/ideal-customer-profile-framework) (or ICP). Within that ICP, we focus on the **product engineers** (full-stack engineers skewed towards the frontend) as our persona, though PostHog should be usable by everyone on the product team.
AKA our [ideal customer profile](/newsletter/ideal-customer-profile-framework) or ICP.
We build for the highest-performing **product engineers** (full-stack engineers skewed towards the frontend) building the **most-loved products** at **high-growth startups**.
We aren't focused on other members of the product team, such as PMs, designers, and data engineers, though we are aware they are oftentimes users of PostHog as well. We expect PostHog to be usable for them, but only prioritize their feature requests when they are in service of product engineering workflows and/or have been requested by product engineers as well.
> Example: PostHog anytime from Series B to IPO
@@ -19,7 +23,7 @@ Why? We believe that the best tech companies are increasingly engineering-led. B
| **Description** | Startups that have product-market fit and are quickly scaling up with new customers, hiring, and adding more revenue. |
| **Criteria** | - 15-500 employees<br />- $100k+/month in revenue _or_ very large number of consumer users<br />- Raised from leading investors<br />- Not yet IPO'ed |
| **Why they matter?** | - Able to efficiently monetize them<br />- Very quick sales cycle<br />- Act as key opinion leaders for earlier-stage startups/slower moving companies<br />- Strong opinions on what they need - helping us build a better product |
| **Examples** | PostHog anytime from their Series B to IPO, Linear, Ramp, Vercel, Retool |
| **Examples** | PostHog anytime from their Series B to IPO, Supabase, 11Labs |
Each team will focus more or less on different members of the product team. This is detailed on their team pages.
@@ -36,6 +40,7 @@ We build for the power users of the **product team**
**Should be usable by**:
- Designers
- Less technical product managers
- Data engineers
- Marketers
## FAQs
@@ -110,14 +115,8 @@ We build for the power users of the **product team**
- They have a large active social media reach
- They are in major tech cities e.g. San Francisco, Austin, New York, London, Berlin, etc.
### Why the data team?
- The data team is a team that we should experiment with for marketing and customer success. We have seen early signs of them being the champion within the org or the person responsible for paying.
- Data products are strategically advantageous to us. The product and customer data is used throughout the organization. By enabling the data team to serve other teams across the company (e.g. marketing, revenue ops) we form a strong moat and can enable the data team to be our advocates.
### What about marketing?
- The features should be usable by the marketing team, but we shouldn’t focus on building features specifically _for_ them. Generally, they have a different level of technical ability to our core power users.
- The features should be usable by the marketing team, but we shouldn’t focus on building features specifically _for_ them. Generally, they have a different level of technical ability to our core power users, and tools in the marketing stack tend to be extremely complicated (and hacky).
- There is an exception to the rule: If a feature will make PostHog more widely adopted in a company, and will decrease the risk of the company moving to a competitor, we should build the feature. Ultimately, this is in line with our wider strategy, because the more teams in a company using the same set of product data stored in PostHog vs a second tool, the more successfully the company will operate. Anti goal: Make PostHog _harder_ to use for product engineers by supporting features for non-ICP users.

62
contents/handbook/why-does-posthog-exist.md
View File

@@ -8,61 +8,49 @@ showTitle: true
Equip every developer to build successful products.
## A few words
## Why is that our mission?
On the surface, PostHog's products are a bunch of different SaaS tools, which work together better than anyone else’s. However, the secret to our success is our long term plan: automate how entire businesses operate by building around the unit they operate on - their customer data.
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.
Critical to making this happen is to deliver each tool without compromise - better, cheaper and with all the customer context in one place. The way to achieve this is very simple - shipping every product that teams use, from day one when there are just two technical cofounders. This is because if we get in with these developers, we’re upstream of every need they’ll have. The end result is that we can offer all the products in one place, with no need to charge as much as everyone else for each one, and most importantly with perfect quality customer data. An actual perfect 360 customer view.
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.
Even so, it’s right to question whether this actually does any good for the world. Are we really in need of better software? And beyond those in the most competitive industries, will perfect customer data actually make a difference to an everyday person’s ability to build a successful business?
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.
No and not really. However, that misses the point, unless you understand the secret master plan alluded to below. The strategy of PostHog is to get early stage software teams to use every single customer related product inside our platform, where we can easily generate a perfect customer data record. This means we can learn to configure and automate how all of these tools work. We can simplify the experience of running a business.
Then with each successive product, we can reach a wider and wider market and further simplify the experience of running a business until anyone can do it.
I’d like to address a repeated argument against shipping multiple products, let alone all of them.
### You can build more than a product or two
The world of tech is changing fast.
First, there’s just more money at better valuations than when this advice was created. Software companies, us included, have more leverage than ever before - with capital deployed well, we can do more than our predecessors.
Second, software development is far quicker.
Third, we’ve managed this very well so far.
We try to help engineers from the very beginning, when their product is just being built. We do that by having [generous free tiers](/pricing), and no need to talk to sales to get started.
## Our strategy
### 1. Be the source of truth for customer and product data
### 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 customer record. This has happened because the entire industry has focused on integration instead of consolidation.
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 people 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.
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 customer infrastructure - by providing _every_ tool related to customer data in one place, we can:
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
- Increase trust in data by eliminating complex data stacks
- Automate everything better than anyone else can, by using AI across this wider data context
- Continue to provide all the tools companies need as they grow
- 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 needed to build successful products
### 2. Provide every tool engineers need to build successful products
We aim to offer every tool software teams need to find, acquire, understand, support and sell to users so they can improve their product experience.
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.
By doing this, we wind up with the perfect customer data record. No integrations needed.
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.
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 customer infrastructure to early stage companies, and so should focus there by default.
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 product.
_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 that small software businesses need that relate to their customer data. We call this customer infrastructure. It's the tools and customer data together.
* Automate all of these tools - this is Max AI.
* (not here yet) Expand the range of products to meet the needs of teams that aren't software-focused.
* 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