Overview

PostHog's brand is the total sum of how people experience us – from a first visit to posthog.com to an onboarding email, from how quickly we ship a bug fix someone complained about on X, to billboards, merch, event collateral, ads, and more.

This matters for two reasons:

1. Brand is a growth driver. It's one of the main reasons PostHog gets recommended. People who trust a brand talk about it. Developers who find us authentic fight for us in comment sections.

2. Trust is slow to build and fast to lose. A generic headline, a forced joke, a bad sticker, a robotic support reply – each of these chips away at the trust we've earned.

Taste

Taste is the most important principle PostHog has. "Polish" is surface-level – smooth gradients, perfect shadows, trendy layouts – the visual equivalent of buzzwords. "Taste" is deeper: making decisions that reflect a real point of view, caring about whether something is right and not just done, going the extra mile even if only one person notices.

Something made with taste looks like someone made this on purpose, especially in a world where more people are shipping AI slop.

What taste looks like in practice:

• Caring about details. Typography, spacing, alignment, whitespace – or the exact wording of an error message – these are felt even when not consciously noticed.
• Intentionality. Every element has a reason to be there.
• Going the extra mile. Especially for things most people won't notice (you'd be surprised how many actually do).
• Enjoying the work. When you enjoy making something, it shows.
• Knowing when trends are played out. Our visual identity is nostalgic and distinctive because we deliberately avoided what everyone else was chasing.

Brand personality

PostHog should feel:

Who we're talking to

Our primary audience is AI-pilled software teams. Many of them are technical founders or assume the role. It's incredibly important that we don't alienate them, as they're a driver of word-of-mouth growth.

We should assume our audience either has to do technical work or wants to, regardless of whether they can code. Most of them are engineers, and for the rest, we're the bridge, giving everyone direct access to data and the power to ship.

This shapes everything. Engineers...

• Distrust marketing by default. They've been burned by overpromising before.
• Prefer specificity over benefits language. "It does X" beats "It empowers you to unlock X."
• Can tell within seconds if something is authentic or corporate. They view source code for fun.
• React well to honesty, including honesty about limitations and tradeoffs.
• Respond to wit, but are allergic to forced humor.

For the full picture, see who we build for.

The Hacker News test

Before you ship anything – copy, design, a campaign, a policy – ask: how would this be received on Hacker News?

Hacker News is intensely logical and skeptical. They'll call out corporate spin, vague claims, and try-hard humor in seconds. If you think your thing would get roasted, change it. If it would hold up to scrutiny, ship it.

How we describe PostHog

PostHog is the context layer for your product. PostHog ingests and stores your analytics, errors, replays, and business data so you and your agents can query it and make changes.

This is the frame everyone at PostHog should use, everywhere.

Our products help customers do one of four things, which build on each other:

1. Get data in. PostHog ingests and stores your data, which can come directly from our own products or 3rd party sources.
2. Query the data with your agent. Ask PostHog AI or use the PostHog MCP to run queries.
3. Give the data to your agent to act on. We make the same data available via PostHog MCP so our users' agents can find issues and propose or take action.
4. Let PostHog self-drive. Use PostHog to ship changes, measure their effect, and repeat.

Start with the step that matches the customer's needs. Self-driving is an aspirational state, but the component parts are composable. If a customer wants to take Reports and pass them to their own agents to act on, that is totally fine. Our job is to give engineers a suite of tools they can pick and choose from.

The standard description

Use this whenever you need a longer standard description of PostHog, e.g. for a newsletter or press. We also embed this in all our blog posts.

PostHog is your product's context layer. With a full suite of developer tools – AI observability, product analytics, session replay, feature flags, experiments, error tracking, logs, and more – PostHog ingests and stores all the data agents need to diagnose problems, uncover opportunities, and ship fixes. A data warehouse and CDP tie it all together, unifying that context into one source agents can read across. You can steer it all from Slack, the web app, the desktop (PostHog Desktop), or your own editor via the MCP.

Product Analytics, Session Replay, Logs etc. are products. The surfaces that you interact with PostHog, like Web, Slack, MCP are apps.

Developer marketers can find the granular vocabulary rules and the per-product playbooks in Positioning and selling.

What we want people to know

Beyond literally communicating what PostHog is and what it does, we want to equip developers to build successful products. We do this by communicating the following:

• There is a lot of hard-earned knowledge in the startup and product space that builders don't know yet because it's not written for them. We've also learned a lot from building PostHog and from our customers. We want to share all this with them.
• We provide all the tools developers need to build successful products. All of them are powerful, but require expertise to use effectively. Some don't even know these tools exist. We help build this expertise by providing world-class docs, tutorials, and technical content.
• Anyone can build successful products. Developers don't need product managers or data analysts to tell them what to build. Formerly "non-technical" people don't need developers to write code for them. With the right tools and knowledge, anyone is capable of making product decisions themselves.
• Talking to users, shipping what they want fast, debugging and fixing issues, measuring impact, and iterating is the core loop of building successful products.
• PostHog aims to do "the right thing" for our users. We're self-serve with usage-based pricing. We don't have loss leaders and are in it for the long haul. We don't do sleazy marketing or sales tactics. We're open source and transparent. We don't want to be another boring B2B SaaS company, even if that is "optimal for the creation of shareholder value."

Why people pick PostHog

• We help engineers build better products, faster.
• PostHog already has all the data about how people use your product and how your product performs, like usage analytics, error tracking, session replays, logs, traces, and more. This lets you discover and understand issues and their context, but also feeds your self-driving loop.
• We have all the products and context in one. This means less time spent patching separate services together and paying for them all separately. When builders (and their agents) need a new capability, they can just use PostHog.
• Our team is technical and speaks the language of developers. Our engineers talk with customers to figure out what to build. Our support team are all former engineers and get into the nitty-gritty of issues. Our sales and CS teams are very technical too. They focus more on your use cases and implementation than steak dinners.
• We want engineers to self-serve. They can sign up and use all of the features of PostHog for free.

See Why buy PostHog and How we make users happy.

What we are not

PostHog could be a lot of things, and we have a lot of terms for the same things. This creates cognitive load and confusion, and we'd rather our audience use their energy elsewhere.

A few things to avoid when describing PostHog:

• Not "an analytics platform." PostHog has grown well beyond analytics. Lead with what we actually are: a platform that makes your product self-driving, with products — product analytics, session replay, feature flags, and more — that help people build successful products.
• Not a single product. We're a platform that makes your product self-driving — you (and your AI agents) ship improvements from your product's own context.
• Not a "product improvement platform." This is vague and buzzwordy.
• Not enterprise-first. We build for people who self-serve. We get in early and grow with our customers. We don't go out of our way to build niche features just to chase a large contract. Don't let copy, design, or tone drift toward enterprise-speak.
• Not a "dev tool platform." This makes it seem like we are just dev tools to use.
• Not a collection, group, set, bunch or any other collective noun of products or apps. We are not "product and data tools" as this isn't developer-focused enough. Product and data should refer to our customer's products and data.
• Not a "product analytics product." The doubled word reads badly – say "product analytics" on its own whenever possible.
• Not "a self-driving product." We help customers make their product self-driving.