惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Hackread – Cybersecurity News, Data Breaches, AI and More
U
Unit 42
Vercel News
Vercel News
Martin Fowler
Martin Fowler
云风的 BLOG
云风的 BLOG
爱范儿
爱范儿
MongoDB | Blog
MongoDB | Blog
J
Java Code Geeks
F
Fortinet All Blogs
MyScale Blog
MyScale Blog
C
Check Point Blog
N
Netflix TechBlog - Medium
Microsoft Azure Blog
Microsoft Azure Blog
aimingoo的专栏
aimingoo的专栏
博客园_首页
WordPress大学
WordPress大学
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
IT之家
IT之家
Last Week in AI
Last Week in AI
罗磊的独立博客
大猫的无限游戏
大猫的无限游戏
Jina AI
Jina AI
V
Visual Studio Blog
小众软件
小众软件

PostHog's RSS Feed

Training our own AI models - PostHog From 270GB RAM to 5GB: Moving local flag evaluation from Django to Rust The best analytics stack for vibe-coded apps The best MCP servers for startups, by workflow 4,063 errors closed without a human opening PostHog – here's what we learned - PostHog PostHog Code and the self-driving product - PostHog Why attacking your competitors online is dumb - PostHog The best real-time analytics platforms for developers, compared DuckDB vs ClickHouse: Why we use both at PostHog - PostHog PostHog's next chapter - PostHog Making Claude Cowork actually useful - PostHog PostHog vs Matomo in-depth tool comparison You're doing lifecycle emails wrong Untangling Tokio and Rayon in production: From 2s latency spikes to 94ms flat The best HIPAA-compliant A/B testing tools - PostHog A beginner's guide to testing AI agents - PostHog I hate the standup bot (so I built an agent to do it for me) - PostHog The best CDPs for developers, compared The best error tracking tools for developers, compared The best feature flag software for developers, compared 7 best session replay tools for mobile apps 7 best free open source business intelligence tools right now 7 best free and open source LLM observability tools PostHog vs LogRocket in-depth tool comparison The most popular PostHog alternatives, compared Open source (and self-hosted) session replay tools - PostHog The 9 best GA4 alternatives for apps and websites - PostHog PostHog vs Google Analytics 4 in-depth tool comparison How we built automatic clustering for LLM traces - PostHog The 7 best HIPAA-compliant analytics tools
The do's and don'ts of minimum viable product marketing -...
Joe Martin · 2026-05-18 · via PostHog's RSS Feed

PostHog is a much bigger company than when I joined in 2021 as the first product marketer – but while we've more than 10xed since then, the product marketing team has only 4xed. Yet we still somehow ship more launches per marketer per month than most companies do in a year.

This is possible because our marketers, like our engineers, emphasize shipping over collaboration. I call this minimum viable product marketing, which is kind of a joke but also kind of not.

Minimum viable product marketing isn't a clear set of rules. It's an anti-framework informed by years in teams that followed the advice of thought-leaders and that just ended up with a reputation as PowerPoint pushers. Here's how it works for product launches at PostHog.

There's no central process that defines how we think about products before we launch them. Instead, we're tactical: what are we actually going to do?

At PostHog, that means a launch checklist. We have a template – a recent example of it in action is the PostHog Code launch plan – but it's a starting point, not a destination. We change the plan for every launch because every launch is different.

Still, there are things I feel strongly about us doing for every launch...

Write an announcement. Your announcement may span multiple channels, like blogposts or social posts. Personally, I start with the email because it's the most intrusive to the user. That means it should be the shortest and that forces clarity. If the email is clear, the blog post will be. If it isn't, neither will be.

This is the hard bit, so I've written more about how I personally approach this below. Spoiler: It's basically just creative writing.

Write the title first. If you can't write the title, you don't know what you're announcing. The title is the only part of the post most readers will see, so it needs to be right. I find it helps not to spend time perfecting it: just get a vomit draft out quickly and go from there. Writing is rewriting, after all.

Focus on conflict. Conflict takes many forms, but it's ultimately at the root of every story worth telling. Maybe the conflict is the problem your product solves, or the competitors you're standing against. Maybe you're standing on principle or disrupting an industry. When we cut session replay pricing by more than 50%, we titled the post "We've decided to make less money." That's the conflict (us vs. shareholders) and the change (we're cutting prices) in eight words.

Think through the release experience. Are you going from beta to GA, or cold-launching? Are there early users that need to be thanked? Is there an existing customer who should hear from you first? These questions are not flourishes. They're the difference between an experience that leads to a renewal contract and one which leads to quiet churn.

Meet users where they are. Part of thinking through the release experience is deciding where to take your message. We've tried all sorts of channels over the years. What works for us: Hacker News, newsletters, small events, and social posts from real people. What doesn't: Product Hunt, podcasts, conferences, and corporate retweets. Which channels work best can depend on whether you're more product-led or sales-led, but if you're early stage just try a new one every time.

Tell the company. Internal announcements are not a formality. The people who'll be asked (like support, sales, and customer success) need to know what's shipped. For smaller orgs, this can be a message in a dedicated Slack channel. At PostHog's stage, this is starting to mean sharing social posts and internal education content, too.

Wire it into onboarding. Our email onboarding flow never goes above a 0.6% unsubscription rate. That makes it a very sustainable channel, so it should be kept up to date. New products get wired in ahead of launch and a workflow with 46 separate delays and 50+ decision events determines who gets what, when.

Write sales content later. This is one most teams get backwards. Testimonials and case studies before launch are like a carp — they smell fishy and they date quickly. The best content shows up three weeks after launch, when a real customer has had a genuinely interesting experience and the product itself has settled. We make time to chase these stories when they're worthwhile and then treat them as mini-launches themselves.

One-pagers and battlecards. Sales enablement is usually about marketing trying to control the sales team. We do sales differently though and don't feel the need to limit what they say with laminated comparison sheets. They just read the docs; your team should too.

Putting storytelling ahead of shipping. That means no delaying launches while you create a plan. A launch that goes out two weeks late so the video can be color-graded loses more momentum than the video buys; the video can ship late. The product will improve in the meantime.

Marketing-as-theater. Countdown clocks and pre-orders work for videogames, but not for B2B software. It is absolutely worth being weird and trying strange ideas, but not if it's a performance that harms the user experience.

Press releases. I used to be a tech journalist and I can assure you that no worthwhile story ever started with a press release. We don't do any PR at PostHog, but if a journalist matters for your launch: email them directly. Speak like a normal person and make the pitch no more than six sentences long, with a short Loom attached. Chase them once only.

Setting context. "We added X" beats "In today's increasingly competitive analytics landscape" If your first paragraph could be deleted and the post would still make sense, delete it. You should, in fact, delete most of what you've written. And don't ever say you're "excited to announce", because that's almost definitely a lie.

Creating consensus. Barring some notable exceptions, businesspeople are not experienced editors or marketers and do not need to be treated as such. Feedback should be listened to, but not every suggestion should be taken — especially if it suggests a solution.

PostHog's product marketing team is still small, but so far this has scaled well. Everyone has freedom to approach things in their own style and in this way we know we're always using the right tool for the job.

Is it chaotic? Sure.

Will it still work in another five years? I don't know!

What I do know is that product marketing is full of thought-leaders who want to inflate their importance by making their work more complicated and mysterious than it needs to be. The reality is that the job is basically just storytelling, and storytelling can be messy.

That's a good thing. It means all you really need is to know Orwell's sixth rule of writing and apply it vigorously. No fancy messaging matrices, fancy frameworks, or page-long personas needed.