Content brand guidelines and messaging

What should we be trying to communicate about PostHog?

PostHog is a developer platform that helps people build successful products. We provide a suite of dev tools to help them do this.

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 developers 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 apps developers need to build successful products. All of them are powerful, but require expertise to use effectively. Some don't even know these apps exist. We help developers build this expertise by providing world-class docs, tutorials, and technical content.

• Developers can build successful products. They don't need product managers or data analysts to tell them what to build. They are capable of making product decisions themselves, but need the right tools and knowledge to help them do so.

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

Who is our audience?

Ideally, our ICP: the people building products at high-growth startups.

The primary persona of our audience is product engineers, product-minded full-stack engineers with a slight bias towards the frontend.

An important subset of this persona is technical founders. Great product engineers sort of act like technical founders anyway.

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.

Learn more in Who are we building for.

Why do developers, product engineers, and technical founders pick PostHog?

We help them debug and ship their product faster.

• The first part we do with automated error tracking and session replays, both of which let them discover and understand issues and their context.

• The second part we do with feature flags to rollout new features, experimentation to measure impact, and surveys to get feedback.

• As a bonus, we combine all this with product, web, and LLM analytics.

We have all the apps in one. This means less time spent patching these tools together and paying for them all separately. When engineers 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. We also work hard to have world-class docs and technical content that enables them to solve their own problems and come up with their own solutions.

See Why buy PostHog and How we make users happy.

Things PostHog is not

PostHog could be a lot of things. We also have a lot of terms for the same things. This creates cognitive load and confusion. We'd rather our audience use their energy elsewhere. To help them, avoid the following:

1. PostHog is not just an analytics platform or tool. Although we started with analytics, PostHog has grown well beyond this. We're not a product analytics or session replay tool either. Nor a "product improvement platform."

1. We are not a dev tool platform. This makes it seem like we are just dev tools to use.

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

1. It's not “product analytics product”, it's “product analytics app” or just “product analytics” whenever possible.

1. We are not focused on non-developer roles by default. We should assume our audience is developers, or technical enough to be one. More people than you think are engineers too, especially thanks to AI coding tools and automation platforms.