Technical Customer Success Manager
Customer Success EU Team
Location
Remote (EMEA)
Timezone(s)
GMT +2 to GMT
About PostHog
PostHog is your product’s context layer. It ingests and stores your analytics, errors, replays, and business data so you and your agents can query and act on it.
We launched out of Y Combinator's W20 cohort. We've since shipped more than a dozen products, including:
A suite of analytics and observability tools, including product analytics, replay vision, AI observability, and error tracking
PostHog MCP for users and their agents to query and act on their product and business data
Data warehouse so users can query product and customer data together using custom SQL insights.
We are:
Product-led. More than 500K organizations have installed PostHog, mostly driven by word-of-mouth. We have intensely strong product-market fit.
Default alive. Revenue is growing incredibly quickly, and we're very efficient. We raise money to push ambition and grow faster, not to keep the lights on.
Well-funded. We've raised more than $180m from some of the world's top investors. We're set up for a long, ambitious journey.
We're focused on building an awesome product for end users, hiring exceptional teammates, shipping fast, and being as weird as possible.
Things we care about
Transparency: Everyone can read about our roadmap, how we pay (or even let go of) people, our strategy, and how we work, in our public company handbook. Internally, we share revenue, notes and slides from board meetings, and fundraising plans, so everyone has the context they need to make good decisions.
Autonomy: We don’t tell anyone what to do. Everyone chooses what to work on next based on what's going to have the biggest impact on our customers, and what they find interesting and motivating to work on. Engineers lead product teams and make product decisions. Teams are flexible and easy to change when needed.
Shipping fast: Why not now? We want to build a lot of products; we can't do that shipping at a normal pace. We've built the company around small teams – autonomous, highly-efficient groups of cracked engineers who can outship much larger companies because they own their products end-to-end.
Time for building: Nothing gets shipped in a meeting. We're a natively remote company. We default to async communication – PRs > Issues > Slack. Tuesdays and Thursdays are meeting-free days, and we prioritize heads down building time over perfect coordination. This will be the most productive job you've ever had.
Being weird: Weird means redesigning an already world-class website for the 5th time. It means shipping literally every product that relates to customer data. It means building an objectively unnecessary developer toy with dubious shareholder value. Doing weird stuff is a competitive advantage. And it's fun.
Who we’re looking for
A customer-obsessed person to take care of a large number of our larger customers. You’ll engage with them regularly to ensure their continued retention and growth.
You'll need to be incredibly helpful, technical enough to help our customers, and solve real problems without asking a sales engineer for help.
No going away and asking an expert by default. You will be the expert!
You’re great at building relationships with customers, understanding their priorities, and ensuring they are set up for success both today and in the long term.
We do not care what your old job title was. We care that you want to talk to customers, own the relationship and help them get more from PostHog.
Some of our best TCSMs used to ship code. Now they ship happy customers. Ex-dev, ex-TAM, ex-something-else? All good if you are technical and want to own customers, not just be near them!
What you’ll be doing
You’ll be the face of PostHog for anywhere from 25-40 paying customers in the $20k-$100k+ ARR range. Some of these customers will have come through our sales process and be well-known to us, while others will have self-served and never talked to us before!
It'll be your responsibility to ensure that both types of customers stay with us. That means taking care of the technical side (debugging, config advice), the commercial side (pricing questions, credit renewals), and the human side (multi-threading, managing escalations).
Day to day, it looks like:
Building relationships with your users. You should know who the key people are at each company, and they should know you.
Owning their feedback and making sure it gets to the wider PostHog team.
Investigating technical issues. You're the first person to dig into customer issues, often solving them yourself rather than immediately passing them to support.
Being super responsive to their Slack messages, support tickets, and emails.
Being their favorite ever Customer Success person to work with!
More broadly, you'll watch product usage and revenue data so customer health doesn't move into the red, and act early when it does. Your aim is to never be surprised when a customer tells us they are leaving. If you want to build automations to help you do your job here, go for it!
Interesting reads:
This role comprises a base salary component, plus a bonus for hitting/exceeding customer retention targets. The salary in our compensation calculator is the OTE (80/20).
What you won’t be doing
❌ Taking someone with you to every customer meeting. It’ll normally be you and the customer. Very occasionally, you might bring a product engineer with you, e.g. if they are one of our first customers paying for a new product.
❌ Aggressively pursuing expansion opportunities. This role is primarily focused on retention.
Requirements
Technically capable. You don't need to be an engineer, but you should be comfortable working with code. You troubleshoot issues customers run into (and sometimes even raise PRs yourself to fix bugs) and advise on configuration best practices across all PostHog products.
You get how product teams work. You know the roles, how they collaborate, and how they ship features - so you can help them use PostHog to solve real problems. For example, why running experiments matters, how to use product analytics and session replay together to find drop-off points and test fixes, or when error tracking helps teams ship better.
Strong customer focus. You need to help our users and remove any blockers to them using PostHog effectively – not route them elsewhere and move on.
Able to work at scale. You'll have around 40 customers. You can't treat them all the same, and you won't try to.
Nice to have
Experience working with similar technologies, i.e. developer tools more broadly, or specifically product analytics, session replay, feature flags, A/B testing, data warehouses, or data pipelines.
You’ve been in a Pre-sales or Technical Account Manager role before, bringing both technical expertise and commercial acumen.
If you have a disability, please let us know if there's any way we can make the interview process better for you - we're happy to accommodate!
Generous, transparent compensation & equity
Unlimited vacation (with a minimum!)
Two meeting-free days per week
Home office
Coworking credit
Private health, dental, and vision insurance.
Training budget
Access to our Hedge House
Carbon offsetting
Pension & 401k contributions
We hire and pay locally
Company offsites
Get more details about all our benefits on the Careers page.
Grow and retain the number of paying customers who fit our Ideal Customer Profile.
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 SmithBen 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 TranbergChristophe 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 VriesAndre 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 CullenElla 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 ZouDana 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 SalvadorCarles 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 DeehanSean 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