Who we are building for

AKA our ideal customer profile or ICP.

We build for the highest-performing product teams (engineers, PMs, designers) building the most-loved products at high-growth startups. We focus specifically on the product engineers (full-stack engineers skewed towards the frontend), but it should be usable by everyone on the product team.

Example: PostHog anytime from Series B to IPO

Marketing and customer success should primarily focus on this ICP, but should also develop high-potential customers – customers that are likely to later become high-growth customers (e.g. James and Tim during YC). We should be in maintenance mode for hobbyists, such as engineers building side projects. We want to be the first tool that technical founders add to their product.

Why? We believe that the best tech companies are increasingly engineering-led. By building for the best product engineers, we'll create a positive feedback loop of being the best product for them. This is clearly differentiated from others in the space who are focused on less technical PMs. As more leading tech companies become engineering-led and have highly technical PMs, PostHog will become the clear product leader.

Our current ICP

Each team will focus more or less on different members of the product team. This is detailed on their team pages.

FAQs

Why double-down on product engineers vs. making it more accessible and easy to use?

Background

• We have good product-market fit with engineers and an okay fit with less technical product managers.

• Most of the existing product analytics tools are built for product managers who are less technical, not engineers.

• However, the best tech companies are increasingly engineering led, with all members of the product team being technical. We believe more companies will work like this in the future.

Principles

• We should double down on the best product engineers at the best product companies.

• Going incredibly far with a specific type of user instead of placating everybody means we'll get over the threshold for "I need to tell my engineer friends about this." We only get word-of-mouth growth by doing a remarkable job for a specific kind of user, not an average one for lots of people.

• We develop a strong feedback loop: by building for the best product engineers we'll attract more of the best product engineers and the best companies. This improves PostHog and drives more word-of-mouth growth from high authority individuals and companies.

• As more of the best companies become engineering-led and grow faster as a result, PostHog gains significant market share.

Counterargument

• We have good PMF with engineers and not yet with product people.

• Instead, we should make the tool simpler and more accessible to product managers so we can better work for them and companies with product manager-led cultures.

• This could potentially help us grow faster in the short-term. However, this is less convincing for long-term growth and less clearly differentiates PostHog from existing tools.

Who specifically should we keep in mind when building?

• We should focus on the high-expectation customer. "This isn’t an all encompassing persona, but rather the most discerning person within your target demographic. Most importantly, they will enjoy our product for its greatest benefit and help spread the word."

• Generally, we should build for the best product engineers building the most-loved products at high-growth startups.

• These kinds of users are speaking to customers, looking at data, and quickly building and shipping features. They operate collaboratively within a diverse team including designers, other PMs, marketers and executives. We want to be loved by the sophisticated power users and still good to use for the others on the team.

• For product analytics, product managers who are technical (ex-engineers, for example) are the power users of analytics. They have the desire and the time to go significantly deeper into the data.

What is a high-potential customer and why do they matter?

• Our product is very sticky. By being the default choice at the highest potential startups we can grow with them and learn from them. Other small-stage (but less high-potential) companies index on what they use.

• High-potential startups haven’t cracked product-market fit yet, but are rapidly iterating towards it. They are founded by excellent product people that likely played key IC roles in other companies or founded a company previously. Often in top accelerators.

• Compared to the individual contributor personas in high-growth startups, at high-potential startups the CTO/technical co-founder will often take more of a lead.

• We want to be the first tool that technical founders add to their product – e.g. James and Tim pivoting and exploring ideas before and during YC.

• Suggested criteria:

  • Small team <20 employees
  • Backed by leading accelerators or previously worked at top-tier startups/bigtech
  • $0-$100k/month in revenue

What is a hobbyist and why do they matter?

• The kind of people that build passion projects and explore new technologies drive technology decisions for their org or new startup. They are often vocal online or in their communities to promote word-of-mouth growth.

• Specifically: Hobbyists are engineers spending their nights and weekends building passion projects. Normally working solo or working with a friend – e.g. Ben White building Mealyo while he was a software engineering consultant.

• Suggested criteria:

  • Side-project or very early stage commercial project
  • Normally one person, three people max
  • Very little funding
  • Significant bonus points:
    • Their day job is at an ICP
    • They have a large active social media reach
    • They are in major tech cites 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.

• 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 use 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.