Introducing: Minimum Viable Product Marketing

contents/minimum-viable-product-marketing

@@ -0,0 +1,75 @@
+---
+title: "The do's and don'ts of minimum viable product marketing"
+date: 2026-05-18
+rootPage: /blog
+sidebar: Blog
+showTitle: true
+hideAnchor: true
+author:
+    - joe-martin
+featuredImage: >-
+    https://res.cloudinary.com/dmukukwp6/image/upload/w_800,c_limit,q_auto,f_auto/this_is_fine_6336efb0ae.jpg
+featuredImageType: full
+category: Inside PostHog
+tags:
+    - Marketing
+    - Guides
+---
+
+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](https://newsletter.posthog.com/p/the-hidden-danger-of-shipping-fast) than most companies do in a year. 
+
+This is possible because our marketers, like our engineers, [emphasize shipping over collaboration](https://newsletter.posthog.com/p/collaboration-sucks). 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. 
+
+## What we focus on
+
+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](https://github.com/PostHog/requests-for-comments-public/issues/513) – but it's a starting point, not a destination. We [change the plan for every launch](https://github.com/PostHog/requests-for-comments-public/issues/313) 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](/blog/session-replay-pricing) or [social posts](https://x.com/posthog/status/2051701057667871112). 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.](/blog/session-replay-pricing)" 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](/blog/how-we-built-email-onboarding) 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.
+
+## What we don't focus on
+
+**One-pagers and battlecards.** Sales enablement is usually about marketing trying to control the sales team. [We do sales differently](/founders/startup-sales-strategy) 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](https://www.investmentwriting.com/omit-needless-words-excerpt-from-strunks-the-elements-of-style/). And don't ever say you're "_excited to announce_", because that's almost definitely a lie.
+
+**Creating consensus.** Barring some [notable exceptions](/community/profiles/30208), 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](https://www.goodreads.com/quotes/477087-remember-when-people-tell-you-something-s-wrong-or-doesn-t-work).  
+
+## How can this possibly scale?
+
+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](https://sites.duke.edu/scientificwriting/orwells-6-rules/) and apply it vigorously. No fancy messaging matrices, fancy frameworks, or page-long personas needed.