Newsletter

Our newsletter is called build mode. It's owned by Ian.

Sent and managed via Substack, we put together an issue planning content for each installment of the newsletter. One person writes it and Andy edits and publishes it.

The newsletter is long-form, original copy, often based on blog posts we already wrote. It focuses on product and business lessons and information for engineers.

We run ads to drive subscriptions for this newsletter.

Art from previous newsletters is in Figma and diagrams are in FigJam.

How to write a good newsletter

These aren’t rules, just things that have worked well in the past. They provide some guidance on writing a successful newsletter.

Topic

• Write about ideas, practices, and experiences unique to PostHog. Challenge conventional wisdom (ChatGPT is good for discovering what “conventional” is). For example, “Product management is broken. Engineers can fix it” goes against standard practice and details the way product management works at PostHog.

• Help our audience directly. Our audience is engineers, founders, aspiring founders. Helping them get a job or launch a startup works well. Buying software, less so.

• Let the examples guide you. It’s ideal to have strong examples in mind before you start. These can be from PostHog (like How we got our first 1,000 users) or from similar companies (like Doist, Gitlab, and Zapier in Habits of effective remote teams). It’s easy to say things, examples prove them.

Title

• The title is the frame for the entire piece. It is worth spending more effort on upfront. Come up with multiple options and get feedback on them if you can.

• Be bold and direct. Address common questions. Focus on a specific role (engineers, founders). In retrospect, “Using your own product is a superpower” is too boring and generic. Less is better: Gmail on mobile truncates titles at 35-40 characters

• Get readers curious to learn more. Highlight a gap between where readers are and where they want to be. Hint at exclusive or non-obvious information.

• Some title formats that have worked well:

  • Non-obvious lessons / advice [about topic]
  • Mistakes to avoid [doing a thing]
  • WTF is (thing) and what you should you care?
  • How to think like (person)
  • The magic of (thing)
  • What we learned about (blah) when doing (blah)
  • What nobody tells you about (thing)
  • X things we've learned about (thing)

Intro

• Why trust us to write about this? We can write about hiring because 900 people applied in the last two months. We can write about A/B testing because Lior has run hundreds of them. Build credibility.

• Use a counterintuitive take as a hook. If you’re writing about something we do differently than others, the intro is a great place to start. For example: "When Tim and I first started PostHog in 2020, I was adamant we would never hire a product manager."

• Clarify what the reader will get out of it. A playbook, framework, lessons learned, pitfalls to avoid. Better yet, what’s the benefit to them? More sales, a job, product-market fit?

Structure

• Headings, lists, and numbers are your friend. These help readers know where they are and create a sense of progress. 2, 3, 5, 7 are all a good number of points to aim for. 4 and 6 are awkward.

• Use takeaways. Help readers implement the ideas themselves. This makes posts more actionable. Non-obvious behaviors that will kill your startup does a good job of this.

• Use pattern breakers. Walls of text are hard to read. Make graphics in Excalidraw. Use hedgehogs. Add screenshots and quote blocks. Get more visually skilled people to help you if you need. Use these at the beginning and/or end of sections.

• Go deeper. Longer newsletters let us fully explore a concept. How we choose technologies ended up being ~1750 words and Product management is broken. Engineers can fix it was ~1900.

Style & tone

• Think about rhythm: Two long paragraphs back-to-back is tiring. Use bullet points to break things up where needed, and mix short, clear sentences with longer ones, so the pace doesn't become monotonous.

• Break up very hard to read sentences: Use a tool like Hemingway to identify sections that are very hard to read. Some long sentences aren't bad, but lots of them consecutively will drain the reader's attention. Aim for readability grade of 8 or less.

• Use footnotes tactically: They're useful for adding context that's useful, but not important enough to bog down your core narrative. If something is hard to explain and slowing things down, consider using a footnote. They're also a fun way to add jokes, rants, easter eggs, and references.

• Be opinionated: Sitting on the fence isn't interesting. It's ok for people to disagree with you, so avoid too much hedging.

• Use graphics and charts: These are great ways for explaining complex ideas and make for great social content. Create bad version and ask the

  
  Graphics Team
  
  Graphics Team to help you make it better.

• Be fun and lighthearted: We're writing about building software, not internet safety. Throw in jokes and memes occasionally. Again, footnotes and captions can be useful here.

• But use memes sparingly: Too many memes can become overwhelming and a distraction. One per article is probably enough – two if they're really good, or the article is on long / serious side.

• Address the reader directly: Say this "this will help you" rather than "this will help your company" or "this will help people". You're talking to one person, not a collective.

Publishing details

• Having a good post preview image is important. Either create one using hedgehogs from the Hoggies file in Figma or open an art request to have Lottie make one for you (give her at least 1 week to do so). This needs to be 1200x630 px for the posthog.com OG image and 1456x1048 px for the Substack preview image.

• We publish the newsletter on Substack and then add it to posthog.com/newsletter via GitHub.

• Make sure links in the newsletter point to posthog.com and include UTMs like ?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=enter_name_here.