Goals
Q4 2026 Goals
- Hit CSM Net Revenue Retention (NRR) of 110% using quarterly comparison method (CSMs)
- Hit and track all team revenue goals (Dana)
Take responsibility for Feature Request tracking
Ben Smith
Ben Smith
Our new Customer Analytics tool can track feature requests but some of older imported requests have already been implemented, some are duplicates, and there's no guidance on capturing new requests yet. I'll do a tidy up of the existing data and add some handbook guidance on capturing requests.
Build customer signals in PostHog Self-driving
Christophe Eynius Tranberg
Christophe Eynius Tranberg
Everyone in GTM is building their own agents and scouts. We have a lot of signals but they are not verified. Build the most valuable signals in PostHog self-driving so that everyone has access to reliable signals to drive customer research and intelligence.
We'll know we're successful when: A series of canonical scouts are configured and signals are feeding into Customer Analytics.
Make enablement part of shipping
Andre de Vries
Andre de Vries
The GTM team doesn't have a structured way of keeping up to date and trained on net new features and products, or big updates to existing ones. Today we mostly pick it up on Slack or at the company all hands demo. In Q4 I want to build a repeatable process so that product engineers, PMs and PMMs know that when a product or feature ships, enabling the field is part of that. Happy and trained staff leads to better customer conversations and better adoption of new features. I'm not the one delivering these sessions, that should be a collaboration between the product engineers, PMs and PMMs. My job is building the process and making it easy to follow.
We'll know we're successful when: One end-to-end enablement has been scheduled and delivered via the new process, with documentation, a handbook update and a recording of the session.
Are customers using the data they capture?
Ella Cullen
Ella Cullen
I want to find out whether our customers are actually using what they capture today in PostHog. The plan is to define what good usage looks like for each of our core products as three tiers, from basic use to repeatable, embedded use, drawing on our docs, user interviews and what we see across customers. I'll test the tiers against my own book and adjust as needed. I'll also turn the changes that are reliable into signals: based on the criteria, a customer could go from tier 0 to tier 1, or the other way around, and a scout will check for these changes and alert on them.
We'll know we're successful when: Core products have written tier definitions, I've mapped my book to them, and at least one behavioral signal is running as a scout and has led to a real customer conversation. Stretch: a playbook of specific recommendations for moving a customer from tier 0 to tier 2.
Make moving accounts to and from CS easier
Dana Zou
Dana Zou
It can be unclear when an account is ready to move between roles, so each account requires some investigation. RevOps is working on the ruleset for when an account should move between the GTM teams and I'll build the checklists / skills / workflows to make this process easier.
We'll know we're successful when: We discover fewer surprises when transitioning accounts and there's a set of checks team leads can use for whether an account is ready to move.
Automated health checks for customer implementations
Carles Salvador
Carles Salvador
How much value a customer gets from PostHog depends on how well they've implemented it: identification, groups, autocapture, event hygiene, reverse proxy and so on. Today CSMs review this by hand, account by account, and not always consistently, so gaps go unnoticed until they turn into a problem. In Q4 I'll build a lightweight health check that CSMs can run on any account to find implementation gaps and turn them into clear, actionable recommendations we can send to the customer.
We'll know we're successful when: The health check has been used on my own accounts and has caught implementation issues that had previously gone unnoticed.
Custom Training Material
Sean Deehan
Sean Deehan
Customers ask us to train their teams on PostHog all the time (at least from what I've seen), and every CSM builds the deck from scratch. The generic "intro to session replay" slides already exist in the docs. What nobody has is the deck for that customer - their event names, their flags, their actual funnel, with an exercise like "find the drop-off in your own onboarding funnel" that works in their project. In Q4 I'll build a skill that takes an account and a product and generates the agenda, slides and exercise sheet for a session, tailored to that customer and checked against their real project before it ships. Three products to start - replay, flags and experiments.
We'll know we're successful when: Three product modules are live and have each been used on a real customer session At least two other CSMs have run a session from generated material, with feedback captured afterwards Time from "customer asks for enablement" to "deck sent" is measurably shorter than it was in October
Handbook
Responsibilities
- Help users get up and running with PostHog, introducing the right PostHog people at the right time
- Guide and support customers in using PostHog for long term success
Customer
- People currently paying $20k+/year to use PostHog
- Smaller customers who are forecasted a first time bill of $500 or more
Output metrics
- Revenue retention
- Paying customer logo retention
Principles
No sales-y talk - we are direct, open and honest with customers. We share as much as possible publicly, rather than hiding it behind a mandatory demo call. We are honest when we don't know the answer, or if we're not sure that PostHog is the right solution for a customer.
Speed - we are frighteningly responsive. If a customer is in a rush, we do our best to work at their pace. We are clear about expectations, and do not promise what we cannot deliver to close a deal.
Engineers helping engineers - there is nothing more frustrating than talking to a salesperson who can't give you all the answers. We keep 'let me find out from the team' to an absolute minimum.
We don't use sales-y terminology like 'leads' - we are working with other human beings here. They are not sources of revenue to be 'converted'.
Being power users of PostHog is a must - otherwise we won't be credible. PostHog is a big and growing platform, so this is a challenge to stay on top of!











