# Newsletter - Handbook

Our newsletter is called Product for Engineers. It's owned by Andy.

Sent and managed via [Substack](https://newsletter.posthog.com/), 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](/handbook/marketing/open-source-sponsorship.md) to drive subscriptions for this newsletter.

Art from previous newsletters is in [Figma](https://www.figma.com/design/tNuNQ0STmx0ve4f1sAv4Ka/Blog-images?node-id=0-1&p=f&t=qHbYLFRHbl0v8wqW-0) and diagrams are in [FigJam](https://www.figma.com/board/b0ttECQMiQ6LlGKpIICUcM/Marketing-Jam?node-id=0-1&p=f&t=Uy3T3a4MXGY266zM-0).

## 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](https://newsletter.posthog.com/p/product-management-is-broken-engineers)” 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](https://newsletter.posthog.com/p/how-to-get-a-job-at-a-startup) or [launch a startup](https://newsletter.posthog.com/p/how-we-got-our-first-1000-users) works well. [Buying software](https://newsletter.posthog.com/p/how-software-salespeople-screw-you), 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](https://newsletter.posthog.com/p/how-we-got-our-first-1000-users)) or from similar companies (like Doist, Gitlab, and Zapier in [Habits of effective remote teams](https://newsletter.posthog.com/p/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](https://newsletter.posthog.com/p/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](https://newsletter.posthog.com/p/how-to-get-a-job-at-a-startup) because 900 people applied in the last two months. We can [write about A/B testing](https://newsletter.posthog.com/p/ab-testing-mistakes-i-learned-the) 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](https://newsletter.posthog.com/p/product-management-is-broken-engineers): "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](https://newsletter.posthog.com/p/non-obvious-behaviors-that-will-kill) does a good job of this.

-   **Use pattern breakers.** Walls of text are hard to read. Make graphics in [Excalidraw](https://excalidraw.com/). 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](https://newsletter.posthog.com/p/how-we-choose-technologies) ended up being ~1750 words and [Product management is broken. Engineers can fix it](https://newsletter.posthog.com/p/product-management-is-broken-engineers) 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](https://hemingwayapp.com/) 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 Cory 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](https://www.figma.com/design/I0VKEEjbkKUDSVzFus2Lpu/Hoggies?node-id=1-196&t=UZQMXMddH0DMLxqX-0) or [open an art request](/handbook/brand/art-requests.md) 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`.

### Community questions

Ask a question

### Was this page useful?

HelpfulCould be better