PostHog Handbook Library / Brand

1,263 words. Estimated reading time: 6 min.

# Brand foundations

Auto TL;DR

## At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

1. What is brand?
2. Our mindset
3. Taste
4. Brand personality
5. Who we're talking to
6. The Hacker News test
7. How we describe PostHog
8. Self driving is the story

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

A design 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 – 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 product engineers – 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.

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.

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 standard description

Use this whenever you need a standard description of PostHog:

#### 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 Web (app.posthog.com, where Inbox and PostHog AI live), Slack, MCP, and Code (PostHog Code; becomes Desktop in future, once it has non-coding use cases). 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 are not

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.

Canonical URL: https://posthog.com/handbook/brand/foundations

GitHub source: contents/handbook/brand/foundations.md

Content hash: `03904be539d44ea4`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: AboutPostHog.