Conversation
Deploy preview
Push a fix or re-run the workflow to try again. Common culprits
|
|
Vale prose linter → found 4 errors, 2 warnings, 0 suggestions in your markdown Full report → Copy the linter results into an LLM to batch-fix issues. Linter being weird? Update the rules!
|
| Line | Severity | Message | Rule |
|---|---|---|---|
| 27:1 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 29:1 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 31:1 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
contents/teams/forward-deployed-engineering/objectives.mdx — 1 errors, 2 warnings, 0 suggestions
| Line | Severity | Message | Rule |
|---|---|---|---|
| 7:25 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 7:33 | warning | 'requesters' is a possible misspelling. | PostHogBase.Spelling |
| 7:48 | warning | 'FDEs' is a possible misspelling. | PostHogBase.Spelling |
| @@ -0,0 +1,35 @@ | |||
| --- | |||
| title: Onboarding | |||
There was a problem hiding this comment.
Should this be FDE or something that isn't 'Onboarding'?
There was a problem hiding this comment.
Whoops you can see I copy pasted this.
| ## Customers | ||
|
|
||
| * Large/high-growth customers who can benefit from the extra focus and attention. | ||
| * Customers willing to pay for engineer time (via professional services). |
There was a problem hiding this comment.
| * Customers willing to pay for engineer time (via professional services). | |
| * Potential new customers willing to pay for engineer time (via professional services). |
There was a problem hiding this comment.
It could also be existing customers?
There was a problem hiding this comment.
Yeah, I'd say we should be open to both.
|
|
||
| ## Output metrics | ||
|
|
||
| * Logo retention for customers who have been assigned a Forward Deployed Engineer. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
charlescook-ph
left a comment
charlescook-ph
left a comment
There was a problem hiding this comment.
Goals look good! Had some nits on the other bits.
Co-authored-by: Charles Cook <charles@posthog.com>
ordehi
left a comment
ordehi
left a comment
There was a problem hiding this comment.
Would like to consider some changes relating what we aim at as mentioned, but approving to unblock
|
|
||
| ## Output metrics | ||
|
|
||
| * Logo retention for customers who have been assigned a Forward Deployed Engineer. |
There was a problem hiding this comment.
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.
| * 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 |
There was a problem hiding this comment.
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.'
3 participants
Changes
Added FDE Team and Q2 Goals
Checklist
vercel.json