Content brand messaging

What should we be trying to communicate about PostHog?

PostHog makes your product self-driving. It pairs all the context needed to build a successful product with agents that find opportunities and ship fixes. You can use our Web, Slack, MCP, and Code products (with Mobile to come) to leverage our tools like product analytics, session replay, feature flags, experiments, error tracking, AI observability, logs, and more.

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 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 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 full persona — product engineers, the technical-founder subset, and how we talk to them — lives in Brand foundations.

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 we build for.

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

We help them 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 product autonomy loop.

This loops 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 use can then use feature flags to rollout 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 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, 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. The canonical what we are not list and the self-driving framing both live in brand foundations — start there. On top of those, a few content-specific things to avoid:

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 tool” or just “product analytics” whenever possible.

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