PostHog Handbook Library / Marketing

673 words. Estimated reading time: 3 min.

# Customer case studies

#### What makes a good case study?

Case studies should make our users look smart, our products look useful, and PostHog look like a company people actually want to talk to.

Things we don't care about:

- if they pay us or not (most customers don't)
- if they use every tool in the box (they might be a power user of only one tool)
- if they have a recognizable brand (big logos are nice, but more frequent, smaller stories often beat enterprise red tape)

Things we do care about:

- that PostHog has helped them achieve meaningful results
- that they represent who we build for
- that someone else might benefit from reading their story

> Case studies are typically owned by the . They live in `/contents/customers/` and appear on posthog.com/customers. If you have a suggestion for who we should interview, let us know in the marketing channel.

### Creating a case study

#### 1. Identify the right customer

Start by asking the PM for that product. PMs do lots of user interviews and can suggest warm leads. You can also post in company Slack channels, but give some context for what you're looking for.

#### 2. Make contact

Got a lead? Before reaching out, search for the company in Vitally. If they already have an assigned Account Executive or CSM, give that person a heads-up — they might already be working on something with the customer or have extra context on what to ask them about.

If there’s no one assigned in Vitally, you’re clear to go ahead and reach out directly.

Some customers have a dedicated Slack channel. If they do, that’s usually the fastest way to coordinate. Otherwise, send an email.

#### 3. Lay the groundwork

Someone agreed to chat? Hooray! Make a GitHub issue to draft some questions, tag any relevant sales/CS people, and note if you’ll need artwork later.

#### 4. Schedule the interview

Who you talk to for interviews doesn’t really matter. Speak to engineers, founders, PMs, or anyone who seems keen to chat. If you’re unsure who to interview, email a few people at the company and see who bites.

> We use Calendly for scheduling external meetings, such as demos or product feedback calls. If you need an account, ask Charles to invite you to the PostHog team account.

How to be a good interviewer:

1. Do some preliminary fact-finding (don't waste time asking general info about the interviewee's company and role)
2. Come prepared with good, open-ended questions
3. Relax and have a nice chat (30 minutes is plenty)

#### 5. After the call

Trust your gut — if it feels like a good story, it probably is. Worst case, it’s still user feedback to pass on to other small teams.

If it is worth turning into a case study, draft a PR right away while it's still fresh. Ask at least one teammate to review it to catch any grammar mistakes (or really bad jokes).

Best practices:

- Be specific - Use real numbers and measurable outcomes where possible
- Use quotes - Let the customer's voice come through
- Keep it concise - Aim for between 700-1400 words including quotes

#### 6. Review and approval

PR looking good? Tag the customer in Github for review. You're not asking for copy edits – just a quick fact check. Legal and PR teams will sometimes want to be looped in for approval as well. They might also request using Google Docs instead of GitHub.

Do what you need to do. The goal is to get the rubber stamp.

> If your draft might include anything private such as screenshots of customer dashboards, keep it in an internal repo like requests-for-comments-internal just to be safe.

#### 7. Publish!

Most people are excited to be featured and will sign off quickly. If you need artwork to go with the case study, use the art or brand request template

Once the case study is merged and live on the website, the last step is to send a merch credit to the participants as thank you.

That's it - you did it!

Canonical URL: https://posthog.com/handbook/marketing/customer-case-studies

GitHub source: contents/handbook/marketing/customer-case-studies.md

Content hash: `8a6377fddcdc0c38`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: PrivateLink, SmallTeam.