PostHog Handbook Library / CS and Onboarding

2,033 words. Estimated reading time: 10 min.

# New starter onboarding

Auto TL;DR

## At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

1. Week 1 – how we talk about PostHog
2. Week 2 – in person onboarding, your customers
3. Weeks 3–4 – start working with your customers
4. What good looks like at the end of week 4
5. Month 2 and beyond
6. Learning PostHog
7. Product analytics
8. Implementation

Welcome to the PostHog Customer Success team! We only hire about 1 in 400 applicants, so you've done well to make it here!

Onboarding here is mostly self-serve - we won't sit you in a room for training for two weeks, and unlike a lot of companies, we'd prefer you get up and running with your book of customers quickly. If you're not sure who's supposed to make something below happen, the person responsible is almost certainly you.

Below is a rough plan for your first month - use it as a guide, not a contract. The handbook itself is a work in progress, so you'll find gaps as you ramp up, things you needed to know that weren't written down. That's normal, and when you find a gap your job is to fill it in so the next person has it easier.

### Week 1 – how we talk about PostHog

This week is about getting set up and learning how we talk about PostHog. You'll feel extremely unproductive, and that's fine - the aim is to set yourself up for in-person onboarding in Week 2. Read everything you can, work through the product fundamentals, and come to Week 2 with questions we can work through together.

Focus on:

- Setting up the day-to-day tools you'll be using - Vitally, Gong, Slack, Metabase. See sales and CS tools for set-up, and start copying other CSM's views and automations (or even better, build your own!)
- Reading the CS and sales sections of the handbook.
- Preparing your PostHog demo.
- Picking a recent customer call on Gong/BuildBetter to watch, and asking team members to add you to as many of their live calls as you can - the goal is exposure to how we talk about PostHog and how we talk to customers.
- Nailing the product fundamentals - use the framework as a guide and work through the onboarding exercise. Use the demo environments or your own PostHog project to test different features and use cases.
- Events, persons, and product analytics are the foundation for everything else - start here.
- Session replay, feature flags, and experiments are the next priority. They're PostHog's most mature products with the most overlap with everything else. But let your book guide you - if your customers are all-in on error tracking, logs, or AI observability, that's an opportunity to go deep early.
- Learn how to use the MCP across all products. This is increasingly how customers will interact with PostHog.
- Exploring Slack. We're public by default, so Slack is one of the richest resources you have. You'll find outreach messages that worked, prior conversations with customers, PostHog history on decisions like pricing changes, and context that didn't make it into the handbook.

How to think about each product. As you go through the fundamentals, for each product you're trying to be able to answer:

- The value add - why a customer would care
- Common use cases to demo
- How it's implemented and implementation quirks worth knowing
- Signs of poor implementation
- How it works alongside other PostHog products
- How to get value out of it
- What you can do with the MCP

### Week 2 – in-person onboarding, your customers

In-person onboarding typically happens this week (3-4 days led by your team lead). You'll get your book of customers, work through how to prioritise it, start digging in, and see how all the systems we use come together.

Focus on:

- Walking through your book of business with your team lead - prioritisation, where to start, who to reach out to first.
- Digging into individual customers - what they're using, where they are in the lifecycle, any open issues, recent conversations.
- Demo practice and feedback.
- Seeing how the systems we use (Vitally, PostHog data, Pylon, Zendesk) come together day-to-day.
- A no-stupid-questions session - bring everything you've been wondering about from Week 1.
- First look at signals - what Vitally tags and alerts are, how the team uses them. You won't be confidently responding to them yet, but that comes over the rest of the month.

### Weeks 3–4 – start working with your customers

This is when you start working with your customers. Reach out, take the first calls, pick up the questions that come in, and start figuring out what each customer needs from you. You'll learn more about the product as you go, but the main thing in these weeks is starting to be helpful to your customers.

Focus on:

- Reaching out to customers in your book to establish contact, scheduling handovers for any coming from existing owners. Getting started with customers covers the playbook for early outreach and intro calls.
- Picking up customer questions and tickets as they come in - this is where the bulk of customer work happens. See handling customer issues for how tickets flow.
- Evaluating implementations as you go - is the customer set up well, are they getting value? The foundation check and health check are the structured ways to do this.
- Refining your demo with each conversation.
- Starting to respond to Vitally signals on your book - what triggers your attention, what's the right next move? You'll feel confused at first, and that's fine, the goal is to start building a feel for it.

Ship your first handbook PR. Somewhere along the way you'll find a gap or mistake in the handbook, or want to add a new page entirely. Write it up and open a PR. The point isn't the PR itself, it's that the handbook only stays useful if everyone adds to it. Not knowing something isn't a failing, but leaving it undocumented for the next person is.

### What good looks like at the end of week 4

This is the bar for end of month 1.

You have a clear read on your book:

- Who's responsive and who isn't
- Who you'd build a strong relationship with
- Who knows you're there
- Where the expansion opportunities sit

You're up and running with customers:

- Made contact with every customer in your book of business
- Handling tickets and customer questions across the products your book uses, with help when needed
- Doing demos for those products
- Evaluating customer implementations and seeing where to improve them
- Understanding how pricing works and the levers you have for cost optimization

You're working with Vitally signals. You know what the signals are and have a sense of how to prioritise and work through them.

You're sharing with the team. You're posting wins, learnings, opportunities for feedback, and anything else valuable in our shared channels. You were hired because we think you can improve our team, so don't be afraid to share opinions and approaches.

### Month 2 and beyond

By the end of month 2:

- Saved your first 'we're going to churn' - it's going to happen, but you're going to save them!
- Be independently working with your entire book to solve tricky technical problems with minimal assistance
- Focusing strategically on your customers - engaging with accounts based on risk and growth opportunity, not just reacting to tickets and signals

By the end of month 3:

- On track to consistently hit your retention targets
- You've suggested and made changes to our systems that enable you to do your job better
- Think about customer health scores and add/change anything you learn here

### Learning PostHog

PostHog has a lot of products, and you can't learn them all upfront, so trying to will just frustrate you. The lenses in Week 1 are the bar for each product you do learn; this section is how to figure out which products to focus on, and what to do when you hit something you don't know.

Find out the products your customers are using. Once you have your book of business, you can see this in Vitally in a few places: the product usage widget in the CSM dashboard, the paid products widget in the default 360 dashboard, or the `paid products` trait. These look at paid usage only and won't include free-tier usage, though most of our customers aren't in free tier anyway. There's no point going deep on session replay initially if none of your customers use it, so use your book to guide what to prioritise first.

Start with the foundations, then focus on what your book uses. Events, persons, and product analytics are useful regardless of who your customers are. Session replay, feature flags, and experiments are the next priority - they're PostHog's most mature products and have the most overlap with everything else. Past that, prioritise the products that show up most in your book, that keep coming up in customer conversations, and that have expansion opportunities. Implementation, billing, and MCP are worth learning alongside all of the above.

When you hit something you don't know:

- Read the docs
- Search Slack — you'll find that someone might've already asked the same question or documented the answer in a thread
- Post in #team-customer-success

Below is a per-product reading list to work through. Add and modify as you go - products are added frequently and the list goes out of date fast.

#### Product analytics

1. Quick primer on Product analytics
2. Creating insights:

- Trends, Funnels
- User Paths
- Wildcard groups
- Path cleaning Rules
- Retention, Stickiness, Lifecycle
- How to filter out test users?

1. Persons

- What are persons and how are they created?
- Identify()
- identified vs anonymous events
- Pricing

1. Groups – what is it? what is the use case? how is it charged?
2. Session replay – masking, cutting costs, filtering
3. Toolbar – heatmaps, actions

#### Implementation

1. How is PostHog implemented?
2. Autocapture – how do you customize autocapture? How do you leverage autocapture?
3. What are custom events? How do you set custom properties?
4. What is identify? How do you set custom person properties? How do you merge users? What is alias?
5. What are groups? How do you set group properties?
6. What are cohorts? How do you create cohorts (static and dynamic)? How are they different from groups?
7. Projects, organizations and access controls
8. More advanced use cases:

- Cross-domain tracking
- reverse proxy
- cookie consent (EU)

#### Billing

1. How to estimate costs
2. Pre-paid credits
3. Billing Limits

#### Feature flags

1. Creating and using them in code

- How do I ensure flags are loaded before capturing any events?
- Can you evaluate feature flags using properties that haven't been ingested yet?

1. Locally testing feature flags using toolbar
2. Insights based on feature flags:

- Some users have access to a beta feature. How do I filter insights for these users?

1. Local evaluation
2. Client-side bootstrapping
3. Troubleshooting

#### Experiments

1. Creating an experiment from PostHog UI
2. Understanding MDE, primary metrics, secondary metrics, interpreting results
3. Traffic allocation - configuring it and validating it. What are some reasons why 80/20 split may not be an 80/20 split?
4. Returning users: user sees variant A in session 1, does not convert; user sees variant B in session 2, does convert

- Does this happen? Can the same user see different variants in different sessions? If so, how does this affect the results?

1. No-code web experiments

- Implementation requirements
- Landing page experiments – how to deal with flickering of content when page is first loaded?

#### AI Observability

1. Implementing with your LLM SDK

- Privacy options

1. Generations vs traces vs spans vs sessions
2. LLM Cost Analysis

- How do we accommodate custom LLM pricing?

1. Insight analysis

#### Error tracking

1. Implementing error tracking
2. Stack traces

- Uploading source maps
- Releases

1. Exceptions vs issues

- What is a fingerprint?

#### Other products and features

1. Platform packages (Boost/Scale/Enterprise/Teams)
2. Data pipelines

- Sources
- Destinations
- Transformations

1. Surveys

- How surveys works with feature flags/experiments

1. Workflows
2. Logs
3. SPA (single page apps)
4. API

### Alerting setup (for team leads)

We have certain automations in Vitally that your team lead needs to add you to. Please ask your team lead to add you.

- Vitally name trait playbook: create a new branch that matches assigned CSM to new team member. In this branch, add action to update account trait `CSM name` to name of the new team member. This is used to populate account owner info in tickets created by customers we own, so support knows who to reach out to.

Canonical URL: https://posthog.com/handbook/cs-and-onboarding/new-hire-onboarding

GitHub source: contents/handbook/cs-and-onboarding/new-hire-onboarding.md

Content hash: `2bf3c21d0f3ba574`

Static reader notes

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