PostHog 营销负责人解答开发者营销常见问题

One of the baffling things about leading the marketing team at PostHog is how often I get asked for advice. People seem to look at PostHog and say "Wow, they have billboards across San Francisco, they must really know what they're doing" — but that's not how it feels on the inside.

There is no grand unified theory of marketing, here or anywhere else. Anyone who pretends otherwise is lying to you. Best I can figure, the only thing that makes marketing at PostHog different is that we're more transparent about this than most. And I've never even been to San Francisco!

Regardless, I keep getting asked to hop on quick calls with founders and developers to talk about marketing. I'm always happy to chat, but I thought it would be helpful to write down the answers my thoughts on the most common questions I get. All of it comes with the caveat that these are just my thoughts and that marketing at PostHog is a team effort.

"I built something and told people about it. What should I do now?"

Tell them again, probably.

Developers often treat a launch as a single event: you post it on Hacker News or Product Hunt, write a big X announcement, and then get back to building. But one launch is never enough. A launch is the start of the work, not the end of it.

When we were repositioning PostHog, we had the idea that every marketing message should land in three places, in three different ways. So launching our Slack agent, for example, didn't just go in the changelog one time — it also got a video and an automation that recommends it to users on our startup program. Like every launch we do, it got a GitHub issue which extended past the initial launch moment to include pre- and post-launch tactics.

Marketing at PostHog is like creating a piece of art: it never gets finished, just abandoned.

"What channels should I use?" / "What channels work?"

The short answer is an unhelpful "It depends".

The long and still unhelpful answer is "It depends what you're good at."

Non-marketers expect channel advice to be tiered somehow: start with small stuff like social posts, then graduate to medium stuff like events, then big stuff like billboards, then prestige stuff like TV. In reality you can use any channel whenever you want, they all take a lot of work to do well, and you should move between them based on what you can do best and what you can do authentically.

"What you can do best" just means leaning into your strengths. At PostHog, we didn't decide to build a newsletter because we thought it was the only channel that mattered, we were just writers who knew how to do that well. A big reason we lean so hard on writing is that James simply wrote a lot early on, it worked, and we went from there — other startups aren't so lucky. If we were a group of former TV executives, we'd have done something different.

"What you can do authentically" is harder to define, but is something you should know intuitively. If a channel doesn't feel like an authentic extension of your brand or your internal culture, listen to that. At PostHog we don't avoid webinars and gated whitepapers because those channels are ineffective — it's just that we think they're kind of lame and don't feel very PostHoggy.

"New users don't know about old features. What should I do?"

Oh my gosh, same. It's a real challenge for us too. PostHog does so much and we spend all our time talking about it, but somehow there are still people who think we're a self-hosted product analytics tool.

Two things I find helpful to bear in mind:

• It is often more effective to upgrade an existing user than acquire a new one, and
• Small gains compound, so don't overlook them.

Usually this means investing in your onboarding flows as a way to educate users about existing features as well as new ones. I've written elsewhere about what PostHog's email onboarding looks like and we're increasingly taking those lessons into other channels too, such as in-app messaging or the Wizard. It helps that onboarding at PostHog is unusually long — the flow sends a lot of emails over a long period of time, which gives us plenty of chances to introduce features a user hasn't touched yet.

Existing users who are long past onboarding need different surfaces, though. For them we send a monthly announcement email rounding up everything we've shipped, and we cross-sell other products in-app when someone's usage suggests they'd benefit from one they aren't using yet.

"How can I communicate small improvements without creating spam?"

Spam is a content or a targeting problem, not a volume problem. If your content is good enough and users can be targeted well enough, you could message them every day and be fine. With this in mind: talk to your users and ask them what content they would find valuable from what channels, when.

They're unlikely to tell you good solutions, but they're very likely to tell you what the problems are.

Not every improvement needs its own announcement, though. We batch small changes into the changelog, and save dedicated emails for things that change how someone actually works. Always question if an email actually needs to be sent before you send it.

"People are lazy. If people just searched/prompted, they would find my thing"

This might not be a marketing problem. Are you sure you're solving a problem that people actually need solved?

"How do you approach showing up in LLMs (AEO)?"

I do whatever Nat tells me to do.

"How do I market products that haven't launched yet?"

We call that pre-marketing. It's something I've specifically focused on this quarter, as you can see from my current goals. The basic system is:

• A public roadmap so people can see what we're building, or thinking of building.
• A way for them to sign up to a waitlist and self-serve into available betas.
• Automations informing users on a waitlist when something moves to alpha or beta.
• Automations asking users for periodic feedback on alphas or betas.
• Automations relaying this feedback to the relevant team internally.
• A way for users to pitch new ideas into the roadmap, which get surfaced internally.

Beyond this we also use some regular marketing surfaces, such as the monthly changelog email and onboarding emails, to highlight particular betas we're excited about.

We don't run paid marketing for betas. I've been game for trying it, but our biggest betas often change shape dramatically as we work on them so the messaging becomes very challenging.

"What data do you track to know you're successful?"

DeskHog was a vibes-led idea, not a data-led one

This sometimes surprises people, but the marketing team at PostHog is not often very data-led. I think this stems from my early career as a journalist, where I was mentored to chase good stories over better metrics. There are definitely other team leads (like Andy and Ian) who are more attuned to the data than I am — but, again, there is no single unified theory here.

This isn't to say we are data-blind, however. Marketing is responsible for new user sign-ups and we track that figure and a few others closely. But where we can, we prefer to judge the success of things by other factors, like "Did users say they enjoyed this?" and "Do we want to do this again?"

At a previous startup I worked at we discussed this a lot. Leadership wanted a metric to track the ROI of product marketers and required us to log how we spent time in 15 minute intervals. As a result, perverse incentives emerged and people started spending more time in meetings where work was collaboratively performed, but little was done.

At PostHog, we take the opposite approach and treat data, like AI, as a tool to use when appropriate, not as the go-to solution for every problem.

"How can we build a community around our product?"