Who we are building for

Last updated:

|Edit this page

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 in the product team.

Example: PostHog anytime from their 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 which are focused on less technical PMs. As more of the leading tech companies adopt being engineering-led and having highly technical PMs, PostHog will become the clear product leader.

Our current ICP

High-growth startup
DescriptionStartups that have product-market fit and are quickly scaling up with new customers, hiring, and adding more revenue.
Criteria- 15-500 employees
- $100k+/month in revenue OR very large number of consumer users
- Raised from leading investors
- Not yet IPO’ed
Why they matter?- Able to efficiently monetize them
- Very quick sales cycle
- Act as key opinion leaders for earlier-stage startups/slower moving companies
- Strong opinions on what they need - helping us build a better product
Job roleWe build for the power users of the the product team

Primary focus

- Product engineers (full-stack engineer skewing front-end)
- PMs (those that are highly technical)

Should be usable by:
- Designers
- Less technical PMs
- Marketers
ExamplesPostHog anytime from their Series B to IPO, Linear, Ramp, Vercel, Retool

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 ok 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 company are increasingly engineering led, with all members of the product team being technical. We believe more companies will work like this in future.

Principles

  • We should double-down on the best product engineers at the best product companies.
  • Going incredibly far with a more specific user type instead of placating every body means that 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, 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/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 much simpler and more accessible to product managers so we can better work for them and the 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 kind 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-engineer type) are the power users of analytics (further evidence in the data analysis of paying users). 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 it (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.
  • Example: 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 a passion project. Normally working solo or working with a friend.
  • Example: Ben White building Mealyo while he was a software engineering consultant
  • Suggested criteria:
    • Side-project or very early stage commercial project
    • Normally 1 person, 3 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 as we have seen early signs of them being the champion within the org or the person responsible for paying.
  • Additionally, the 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 very different level of technical ability to our core power users.

Questions?

Was this page useful?

Next article

How we make users happy

User happiness is of fundamental importance. So, how do we achieve this? Building products that people want First, someone internally will suggest an idea. Sometimes this will come from James and Tim, but it has just as frequently come from anyone else on the team. If it requires a new team to build it – which it usually will – we'll start by hiring an ex-founder who is technical. We'll onboard them into the existing team that has the most overlap. This helps get them used to working with our…

Read next article