Blog: The self-driving product (and why we're launching PostHog Code)#16500
Conversation
Deploy preview
|
|
Vale prose linter → found 0 errors, 6 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 |
|---|---|---|---|
| 37:143 | warning | Capitalize 'Error Tracking' for PostHog's product. Use 'error tracking' for the general industry concept. | PostHogBase.ProductNames |
| 53:33 | warning | Capitalize 'Workflows' for PostHog's product. Use 'workflows' for the general industry concept. | PostHogBase.ProductNames |
| 53:102 | warning | Capitalize 'Error Tracking' for PostHog's product. Use 'error tracking' for the general industry concept. | PostHogBase.ProductNames |
| 57:262 | warning | 'triaging' is a possible misspelling. | PostHogBase.Spelling |
| 65:148 | warning | 'erroring' is a possible misspelling. | PostHogBase.Spelling |
| 95:93 | warning | Capitalize 'Experiments' for PostHog's product. Use 'experiments' for the general industry concept. | PostHogBase.ProductNames |
Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
… refined level descriptions Generated-By: PostHog Code Task-Id: 0dd9f3aa-77fb-4571-8663-bde2f930ab63
|
2 main things I'd change: I think this is about 40% too complex / academic feeling. can we make it feel simpler? I worry about drop off / disengagement. i think you can get the same points more concisely and you'll get a better read through rate i'd be a bit more detailed on what the product does and does not do. obviously this isn't the docs or whatever, but i think more precision here is what i'd fill the space with that the above frees up |
There was a problem hiding this comment.
Agree with James' feedback. At the moment it feels like part manifesto/thinkpiece and part launch announcement, where we'd be better off committing to just one. Leading with the specific thing we're trying to say will help.
I also think we can sharpen this by grounding the conversation in individuals rather than companies vague -- maybe we can add asides from the engineers to bring this out? Either way, getting this to feel more personal will help it feel more concrete.
I would also, more specifically...
-
Cut the the Level 0-5 walkthrough and compress it to one or two sentences. This may be a murder your darlings moment, but I don't think we need that many words building that abstraction.
-
Cut the "Product splits three ways" opening and jump straight to the actual one message we want to land (either manifesto or launch).
-
Specifically reduce the phrase complexity. I think simplicity will carry us farther than complexity in general. Right now this sits at a Flesch Reading Ease Score of 49.8 which is really high. We should get it closer to a high school level (this is a rough steer for getting it to sound less academic, not a rule).
Happy to do a closer read if useful!
|
Feedback received! I have simplified and killed many darlings. |
| @@ -0,0 +1,123 @@ | |||
| --- | |||
| date: "2026-04-20" | |||
Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>
andyvan-ph
left a comment
andyvan-ph
left a comment
There was a problem hiding this comment.
@cleo-pleurodon have done an edit pass on this.
This is already much clearer than the original draft. Main high-level bits:
-
We really need to ditch the six levels section. We can do that as its own thing somewhere, but it just adds a bunch of complexity where we don't need it. I think @joethreepwood suggested something similar. We should totally write this up properly, but it doesn't need to be in this post.
-
To accommodate removing that, we'll need some of that missing context into the "How we're defining self-driving". I can have a go at this if you prefer, but figured you'd prefer dibs on doing that.
Updated the release date and made minor text adjustments for clarity.
andyvan-ph
left a comment
andyvan-ph
left a comment
There was a problem hiding this comment.
couple of small suggestions left, but otherwise 👍
|
|
||
| There's a lot of work that distracts engineers from building things that could actually be put on cruise control: bugs, UX issues, small features, conversion-rate tweaks – things that drain engineering hours but rarely needs strategic input. | ||
|
|
||
| This is where product data does the heavy lifting. In a typical week, PostHog customers generate 100,000+ failed queries and ~1.5 million new error tracking issues. Each one is a signal an agent could act on. |
There was a problem hiding this comment.
| This is where product data does the heavy lifting. In a typical week, PostHog customers generate 100,000+ failed queries and ~1.5 million new error tracking issues. Each one is a signal an agent could act on. | |
| In a typical week, PostHog customers generate 100,000+ failed queries and ~1.5 million new error tracking issues. Each one is a signal an agent could act on. |
6 participants
Changes
Blog post to soft launch PostHog Code. Planning to publish on the 29th.
Important: Recent launch posts for new products at PostHog are typically either short and sweet (logs) or feature-based (workflows).
PostHog Code will get one like this too! But since the feature freeze won't happen until launch week, I don't have reliable content to screen capture and write a narrative around. This is the bridge (but hopefully it's a nice bridge).
Header image pending here
A note for @corywatilo
Claude advised to build a sibling component rather than extracting DownloadButton from code.tsx into a shared one. The /code DownloadButton is tightly coupled to page-level state (setConfetti via useApp()), so refactoring it would change /code's behavior. Both forms capture the same event with the same selectedProduct, so submissions from either surface should land in the same place — but they're now independent files. Please feel free to suggest a better solution!
Checklist