Overview

If you work at PostHog, you are a brand ambassador. This brandbook outlines how to extend our brand to your personal responsibilities at PostHog.

What is brand?

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.

Every person who encounters PostHog forms an opinion. Brand is the accumulated weight of all those opinions.

This matters for two reasons:

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

1. 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.

Our mindset

Everything flows from two ideas:

"Yes and…" We expand ideas instead of shutting them down. When someone proposes something, the instinct is to find what's interesting about it and build on it – not critique it to death. This shapes how we design, how we write, and how we talk to each other.

"We can do this better ourselves." The best things get made by people who genuinely care about what they're making. When we ship something, it should feel like someone made this on purpose – not like it was generated, templated, or outsourced.

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:

| Feel like this | Not like this | | -------------- | ----------------------------------------- | | Opinionated | Diplomatic to the point of saying nothing | | Human | Corporate robot | | Slightly weird | Trying to be funny in a try-hard way | | Thoughtful | Random | | Direct | Fluffy | | Honest | Corporate fluff | | Playful | Childish or unprofessional | | Approachable | Arrogant |

Who we're talking to

Our primary audience is AI-pilled builders – product-minded, full-stack engineers with a slight bias toward the frontend – and product-minded builders more broadly. 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 developers, and for the rest, we're the bridge, giving everyone direct access to data and the power to ship.

This shapes everything. Developers...

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

The right model: you're talking to a smart, skeptical friend who happens to be a product builder. Not an enterprise buyer. Not an executive. A person.

When we are working on content (like blogs, docs, and tutorials) for a specific product, we should write it for the persona of that product, which might be different from our primary persona.

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

Nothing has changed about our overall positioning: PostHog makes _your_ product self-driving. This is the frame everyone at PostHog should use, across the product, website, marketing, content, and support. Product marketers can find the granular vocabulary rules and the per-tool playbooks in Positioning and selling.

Self-driving is the story

Self-driving is the narrative everything sits under. PostHog makes your product development self-driving – a better version of you, with your product and all its context in one place. It isn't a product or a tool you can point at. It's what PostHog is and enables. Don't write "PostHog is a self-driving product" or "the self-driving app" – keep the customer's product as the subject.

Because it's a capability, not a product, always write it lowercase and hyphenated: it's not "Self-Driving" or "self driving", it's "self-driving".

The elevator pitch

Use this when you are telling someone what PostHog does, e.g. at an event.

PostHog makes your product self-driving. It automatically diagnoses problems, fixes bugs, and generates pull requests – all without you having to prompt it.

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.

The four layers

Everything we offer is one of four things. Use these words exactly:

• Products – the surfaces a customer adopts; how you access self-driving. Today that's PostHog Web (app.posthog.com, where Inbox and PostHog AI live), PostHog Slack, PostHog MCP, PostHog CLI, and PostHog Desktop. PostHog Mobile is coming. The context warehouse is a product from a marketing perspective (its own PM/PMM, pricing, and so on), but on posthog.com we present it as the platform everything is built on, not as another item in this list.
• Tools – the functional capabilities accessed through the products: product analytics, session replay, feature flags, experiments, error tracking, surveys, web analytics, and so on (as granular as annotations or comments). We used to call these "apps."
• Context – the data that feeds the self-driving loop: events, recordings, errors, and logs from PostHog, plus other business data (Slack, code, Notion, support tickets, and so on). This is the fuel.
• Context warehouse – the data warehouse plus the full context-ingestion pipeline (modelling, data pipelines, batch exports, and so on). Don't say "PostHog Data Stack" – the warehouse, modelling, pipelines, and exports are all part of the broader context warehouse, and "Data Stack" isn't something we talk about externally.

In one line: self-driving is the story, products are how you access it, tools are the supporting capabilities, context is the fuel, and the context warehouse is the platform where context lives.

What we want people to believe

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 people debug and ship their product 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 them discover and understand issues and their context, but also feeds our self-driving loop.

This loop turns that data into signals, feeds those signals to an agent running in a sandbox, and automatically opens PRs that improve your product. Both our agents and the user can then use feature flags to roll out new features, experiments to measure impact, surveys to get feedback, and evals as checks.

We have all the tools and context in one. This means less time spent patching these tools together and paying for them all separately. When builders (and their agents) need a new tool, 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 tools — 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 tools or products. 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." It's "product analytics tool" or just "product analytics" whenever possible.

Messaging framework

This is our shared messaging framework. For the full context behind it, see the repositioning RFC.

• Product name and one line description
• PostHog makes your product self-driving. Hand off issues, the analysis, and the grunt work, and put your time where it counts - figuring out what customers want and shipping it.
• Market category
• Self-driving software product platforms.
• Competitive alternatives
• Anthropic (with very thin product context via MCP)
• Snowflake (without the coding)
• Amplitude Wave (without the business context or engineer focus)
• Anyone shipping 'self-healing' or 'self-improving' software
• Unique attributes -> value
• Agents that act unprompted, off your data -> your product improves without you driving every step, so your time goes to the creative work only you can do
• Your product and business context, unified in one context warehouse -> PRs grounded in how your product actually behaves, not generic slop -- and near-impossible to match without the data you already give us
• We train our own models -> lower cost to you, with open source models tuned for finding and fixing product bugs rather than general-purpose coding
• Open source and transparent -> no black box and no lock-in: you can read it, fork it, and see exactly what's running inside your product
• Who cares a lot?
• Engineers building products in AI-pilled software teams at any scale.