-
Notifications
You must be signed in to change notification settings - Fork 775
Added FDE small team and Q2 goals #16142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| --- | ||
| title: Forward Deployed Engineering | ||
| sidebar: Handbook | ||
| showTitle: true | ||
| hideAnchor: false | ||
| template: team | ||
| --- | ||
|
|
||
| ## Responsibilities | ||
|
|
||
| * Auditing customer PostHog implementations for correctness, data quality, and privacy compliance. | ||
| * Helping customers implement PostHog in the best possible way. | ||
| * Shipping improvements to the PostHog product when customer patterns reveal friction worth fixing. | ||
|
|
||
| ## Customers | ||
|
|
||
| * Existing large and/or high-growth customers who can benefit from the extra focus and attention. | ||
| * Customers willing to pay for engineer time (via professional services). | ||
|
|
||
| ## Output metrics | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should also consider outcome metrics (or knit these into principles?) that map to the self-driving product direction. Two threads I'd suggest we think about: Reduced dependency: are customers needing less human intervention over time after FDE engagement? Measured by trends in ticket volume, topic mix, and self-service resolution rates. If our work is effective, customers should be operating the product more independently over time, not staying dependent on us. Accelerated time to value: after FDE engagement, did the customer reach production usage of the feature or product they were implementing faster than baseline? If the FDE's work is effective, customers should be getting to value quicker, not just getting unblocked. If we only track output metrics, we miss patterns like this: https://github.com/PostHog/fde/issues/2 where the real problem isn't whether we retained the logo but whether we moved the customer from a perception to 'I trust this product enough to expand into it on my own.' |
||
|
|
||
| * Logo retention for customers who have been assigned a Forward Deployed Engineer. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this sometimes feels like it's true today, but usage retention is probably a better metric? Sometimes (often?) @ordehi is working with customers who are not at risk of churn logo-wise.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I'd say we should aim at usage retention. However, there's a nuance here. We want a self-driving product, so the FDE should focus on what patterns move customers to that world. Retaining a customer because they need to keep pushing buttons to make the product work, or mere "entity creation" metrics, are blind to the actual impact the product has on the customer's goals. I want us to focus on eventually being able to track and improve the impact our product has on customers and to move that impact to a quicker TTV while being as self-driving as possible. |
||
| * Completed professional services engagements. | ||
|
|
||
| ## Principles | ||
|
|
||
| **Extreme customer focus** - you should love working customers as much as they love working with you. | ||
|
|
||
| **Deeply analytical** - some of the problems our customers face require a lot of investigation and digging around in data; a focused and analytical mindset is a must. | ||
|
|
||
| **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! | ||
|
|
||
| ## Slack channel | ||
|
|
||
| [#team-fde](https://posthog.slack.com/archives/C0ADE38DEFN) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| Forward Deployed Engineers lead short-term projects with our biggest customers to ensure they are using PostHog according to recommended patterns, reducing their reliance on our support team, and ensuring that customers get the most out of their PostHog usage. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| **Objective**: Hit the ground running as a real life small team | ||
|
|
||
| ## Q2 2026 Goals | ||
|
|
||
| - Hire and onboard one new team member (Simon) | ||
| - Deliver something of use back to the product / GTM org after every completed engagement (Joshua) | ||
| - Define FDE intake guide - for requesters and FDEs (Simon) | ||
| - After each FDE engagement we log qualitatively the impact manually (Joshua) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could also be existing customers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd say we should be open to both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me!