Documentation

Last updated:

|Edit this page

Responsibilities

  • Product teams are responsible for ensuring their docs are up-to-date. This means:

    • Documenting new features when they're launched.
    • Correcting mistakes reported by users.
    • Clarifying documentation based on user feedback and support tickets.
    • Ensuring public betas have documentation which is linked to from feature preview menu
  • Content marketing is responsible for improving the docs. This means:

    • Reviewing draft documentation created by product teams.
    • Identifying and improving low quality documentation.
    • Ensuring screenshots and other visual elements are up-to-date.
    • Shipping supplementary docs and tutorials based on feedback and emerging use cases.
  • Website & Docs is responsible for design, organization, and discovery. This means:

    • The design and content of index pages.
    • The overall layout of docs and how they're organized.
    • In-page elements and components – e.g. light and dark mode screenshots.
    • Website search and other elements that help users find the answers they need.

Frequently asked questions

I'm really busy, can the content team write docs for me?

No. The content team isn't big enough to own all documentation. It also lacks the context necessary to document new features. First drafts of documentation must always come from the relevant product team.

If you need help updating documentation:

  • Write a draft that covers the basics, which the content team can then help review and polish.
  • In the event multiple docs pages need updating, create an example of changes needed and then request help to complete the rest.

Bottom line: It's much easier for the content team to improve a draft than write completely new documentation, especially when documenting new features. Pull requests > Issues.

Who should review docs updates?

For larger updates, please tag Lior and/or Ian from the content team, and Cory from the Website & Docs team, in addition to other relevant team members.

Questions?

Was this page useful?

Next article

PostHog community

We want to build a self-sustaining and scalable community of engaged users because it will enable us to own our audience in a way that third party social media platforms do not. Like brand or content, building a thriving community is a (very) long term bet, so we will need to both invest a lot of time up front and then wait to see what works and what doesn't. Our approach to building community at PostHog differs from most devtools in two ways: We are building our community around our website…

Read next article