You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -21,168 +21,125 @@ This means each product engineering team writes and maintains their own product
21
21
22
22
</details>
23
23
24
-
## Goals for Q4 2025
25
24
26
-
<details>
27
-
<summary>Even better SDK reference docs</summary>
28
-
29
-
**Owner:** Vincent Ge
30
-
31
-
**Motivation:** We’ve got all the infrastructure to keep shipping SDK references. Now we want them to be versioned, updated automatically on push to master, and hosted in each SDK’s repo.
32
-
33
-
**What we'll ship**
34
-
35
-
* References for Flutter, Android, iOS, GoLang. (still by popularity)
36
-
* CI workflows + website code to automatically keep references up to date.
37
-
* Selectors to view references by version. This is important for teams that choose to remain on older SDK versions.
38
-
39
-
**We'll know we're successful when**
40
-
41
-
* THE definitive source of truth for human and LLM readers for popular SDKs.
42
-
* Versioned references published when new SDK versions are released, without any human in-the-loop.
43
-
44
-
</details>
25
+
## Goals for Q1 2026
45
26
46
27
<details>
47
-
<summary>Usable API reference docs</summary>
28
+
<summary>Next milestones for the AI Wizard</summary>
48
29
49
-
**Owner:**Vincent Ge
30
+
**Owner:**<TeamMembername="Danilo Campos"photo />
50
31
51
-
**Motivation:**LLM based tools need these. Companies that want to deeply integrate with PostHog as a developer tool will need these. Doesn't need to be pretty, but information must be accurate.
32
+
**Motivation:**People are ecstatic about the Wizard, but we can’t give the best version of it to people who aren’t running Next.js. We’ve made investments all along the infrastructure, now it’s a matter of building and plugging in the content, then testing it. It's time to ship the v2 Wizard with even more features to as many people as possible.
52
33
53
34
**What we'll ship:**
54
-
55
-
* Investigate how we generate SDK specs right now
56
-
* Examine past feedback about APIs
57
-
* Ship code and copy updates to correct *only* the parts that are wrong
58
-
* Make the website API references page slightly prettier
59
-
60
-
**We'll know we're successful when**
61
-
62
-
* A developer or LLM can use the API docs without being mislead.
**Motivation:** We now own onboarding, wizard, and docs. They have a few problems:
72
-
73
-
* They’re inconsistent. The information should be generally the exact same. You should be able to start in onboarding, move to docs, and then to wizard and see the same general instructions/approach. This builds trust and makes installation easier to follow.
74
-
* They’re hard to maintain. We have 3 copies of the same information.
75
-
* They lack clear checkpoints. No self-checking mechanisms that help readers/LLMs understand if they’re succeeding.
76
-
77
-
**What we'll ship**
78
-
79
-
* A standardized set of “instructions” for humans and machines. Similar to GitHub Spec-Kit, but less general. [See RFC](https://github.com/PostHog/meta/pull/362)
80
-
* A way to define clear checkpoints for humans and LLMs to follow. Including APIs and MCP tools if necessary.
81
-
* Website, monorepo, and wizard updates where applicable to consume this.
82
-
83
-
**We'll know we're successful when**
84
-
85
-
* A single source to update for instructions.
86
-
* LLMs and humans aren’t lost when they implement PostHog in their apps.
87
-
* Technical writing teams are jealous we built this first.
35
+
- Broader support for frameworks and languages: Next.js, React, Node, Python, and mobile platforms like React Native, iOS, and Android
36
+
- Expanded support for PostHog products like LLMA, feature flags, experiments, and surveys
37
+
- In-app actions, dashboard creation, and updates to projects via OAuth
38
+
- Updated CLI UX with a new onboarding flow and more flags and options
39
+
- New Wizard skills like migration, troubleshooting, and diagnostics
40
+
- Detection of 3rd party integrations (e.g. find Stripe integration and send data back to PostHog and then recommend CDP and data warehouse syncs)
41
+
- Improvements to internal DX and tools like examples repo, workbench, CI/CD, and testing
42
+
43
+
**We'll know we're successful when:**
44
+
- User feedback maintains the high energy we expect
45
+
- Adding new frameworks, skills, or products to the Wizard is straightforward
46
+
- Other companies duplicate our approach
47
+
- Wizard installs and PostHog activations increase
88
48
89
49
</details>
90
50
91
51
<details>
92
-
<summary>Next-generation wizard</summary>
52
+
<summary>Platform docs: Overhaul the getting started section</summary>
**Motivation**: The wizard’s architecture is a dead-end. It’s too hard to maintain, and it can’t support more ambitious integrations in its current form. The code, prompts and context to support integrations are tightly coupled, making maintenance expensive. Error correction is non-existent, so our success comes down to luck. While that luck is overall good, with 80% or more wizard runs happy and healthy, there’s still thousands of people who end up with a bad outcome.
56
+
**Motivation:** The current [getting started section](https://posthog.com/docs/getting-started/install) of our platform docs hasn't been meaningfully updated in months. More urgently, it does a bad job of getting users onboarded to the Posthog *platform*. It narrowly focuses on installs, methods like capture and identify, and reverse proxies, but even these concepts are poorly explained together. We need content that provides stronger guidance for core Posthog concepts and a clearer sequence for the cross-product, cross-framework steps a developer needs to take to get up and running.
97
57
98
-
**What we'll ship**
99
-
100
-
* A wrapped Claude Code SDK CLI tool that uses our MCP for prompting and context provisioning, able to error correct its output in realtime.
101
-
* Fully-runnable example project code per framework
102
-
103
-
**We'll know we're successful when**:
58
+
**What we'll ship:**
59
+
- A complete content overhaul of the current [Install and configure](https://posthog.com/docs/getting-started/install) section
60
+
- Information architecture changes to reorganize the sidebar and existing content
61
+
- An emphasis on the Wizard to demonstrate and guide PostHog onboarding
104
62
105
-
* Users can’t believe how deep yet CORRECT our auto-integration is
106
-
* Feedback about poor integration experiences decreases dramatically
107
-
* We can easily support additional product integrations by adding high-level prompts and docs resources
63
+
**We'll know we're successful when:**
64
+
- It makes sense to read the platform getting started section *first*, before visiting individual product docs
65
+
- Developers are able to see meaningful data and insights in PostHog by following the new getting started section
66
+
- The Wizard is clearly positioned as the canonical, end-to-end onboarding path for the PostHog platform
108
67
109
68
</details>
110
69
111
70
<details>
112
-
<summary>Make the error tracking docs even better</summary>
113
-
114
-
**Owner:** Sarah Sanders, Edwin Lim
71
+
<summary>Platform docs: AI education and jobs-to-be-done</summary>
115
72
116
-
**Motivation**: I know I know. I think it’s worth investing a bit more time into raising the product docs bar from "very good" to "holy shit". I don’t think we’re far away now that we’ve built the *foundation* (Hari Seldon would be proud). We won’t get the chance to do this with other products, at least not for a long while. A lot of this work can be reused for other Q4 projects.
73
+
**Owner:** <TeamMembername="Edwin Lim"photo />
117
74
118
-
**What we’ll ship:**
75
+
**Motivation:**As hyped and exciting as the paradigm shift is, most developers are still learning the basics of what AI can do for them, their jobs, and their products. With an AI fleet that consists of the Wizard, PostHog AI, our MCP, LLMA, and Array, we are uniquely positioned to educate developers on how to apply AI to real use cases and jobs-to-be-done entirely within the PostHog ecosystem. Our platform docs can become an exemplary resource for AI usage and product building for engineers.
119
76
120
-
* Flagship use-case guides, example app, more docs components, robust troubleshooting, cross-product tutorials, deep-dive blog post, etc.
121
-
122
-
**We'll know we're successful when**:
77
+
**What we'll ship:**
78
+
- A new, strongly-opinionated section in the platform docs that primarily focuses on the use of AI and PostHog together
79
+
- Learning tracks that are organized by developer jobs-to-be-done and use cases that span multiple products
80
+
- Multi-product guides that heavily emphasize using AI tools like the Wizard, MCP, and PostHog AI to accelerate or automate
123
81
124
-
* Other product teams want their docs to look like error tracking docs
125
-
* Users mention how good the error tracking docs are
82
+
**We'll know we're successful when:**
83
+
- Our customer-facing teams send these docs to prospects or users interested in PostHog
84
+
- Developers associate the PostHog platform with practical, end-to-end AI usage for building products
85
+
- It spiritually connects with the Winning with PostHog and Getting HogPilled content
126
86
127
87
</details>
128
88
129
89
<details>
130
-
<summary>Docs Markdown service</summary>
131
-
132
-
**Owner:** Edwin Lim
90
+
<summary>Revamp product installations and getting started content</summary>
133
91
134
-
**Motivation**: AI agents need high-quality, focused context on demand in order to do all their work. LLMS.txt is actually an amazing dev tool instead of a AEO tool. Let’s turn all our docs into a context service.
**Motivation:**We have a new architecture for maintaining and rendering product installation content in our docs and in our app. But only LLMA is using it today. Migrating the other products will let us standardize installation content and directly feed the Wizard with the same Markdown source.
137
95
138
-
* Utility scripts or workflows that creates a versioned directory of our docs for download
139
-
* Multiple versions for different tokenized use cases (e.g., prose vs. just code snippets)
96
+
**What we'll ship:**
97
+
- Move installation docs to new shared rendering architecture for product analytics, web analytics, session replay, feature flags, experiments, error tracking, data warehouse, and surveys
98
+
- Update examples repo to fetch the new installation docs for the Wizard to use as context
99
+
- Marginal improvements to the existing content or getting started sections
140
100
141
-
**We'll know we're successful when**:
101
+
**We'll know we're successful when:**
102
+
- Products have installation content in the new shared rendering architecture
103
+
- The Wizard is able to auto-implement the migrated products using the Markdown source as context
104
+
- The Wizard is able to auto-implement the migrated products in multiple languages
105
+
- Onboarding content becomes more consistent and maintainable and engineers are happy to update it
142
106
143
-
* Agents like the Wizard or Claude Code perform better by using this context service
144
107
145
108
</details>
146
109
147
110
<details>
148
-
<summary>Example apps library + AI commandments</summary>
111
+
<summary>Improve docs for event setup like identify, session tracking, and properties</summary>
149
112
150
-
**Owner:**Edwin Lim, Danilo Campos
113
+
**Owner:**<TeamMembername="Vincent Ge"photo />
151
114
152
-
**Motivation**: We need example apps. Even before the AI agent craze, our platform is starved for runnable applications with PostHog integrations that developers can learn from. Now AI agents need example apps for context.
115
+
**Motivation:** Some of our most important docs are the most confusing 🫠. Creating a clean, sensible PostHog setup is highly dependent on not screwing up basic setups like identification and cross-platform session tracking. These steps are crucial to make any sense of your PostHog data. We need to improve these docs to make sure developers can get up and running with PostHog effectively.
153
116
154
117
**What we'll ship:**
118
+
- Improvements to identify, person properties, schema management, and other core event setup docs
119
+
- Update examples repo to fetch the new docs for the Wizard to use as context
120
+
- Information architecture changes to reorganize the sidebar for product analytics docs
155
121
156
-
* Example apps in multiple frameworks that are annotated with code comments
157
-
* Markdown file writeups that detail the application’s architecture, use cases, and implementation for LLMs and humans to learn from
158
-
* End-to-end tests that verify the code is running even when PostHog SDKs update
159
-
* A maintained list of AI commandments: prompts with curated instructions for each example app that the agent can follow for best practices
160
-
* A docs component that quotes code snippets from the example apps, replacing ad-hoc code examples in the docs
161
-
162
-
**We'll know we're successful when**:
163
-
164
-
* Agents are performing better when using these example apps as context
165
-
* We're using the code
166
-
* Users mention how good the error tracking docs are
122
+
**We'll know we're successful when:**
123
+
- Developers are less confused by the core mechanics for PostHog event setup
124
+
- The Wizard can use the new docs to auto-implement event setup
167
125
168
126
</details>
169
127
170
128
<details>
171
-
<summary>Docs for new products and launches</summary>
**Motivation**: We're shipping new, flagship products this quarter – especially developer and AI-focused ones like Array, logs, and Max AI with deep research. Marketing team also has upcoming product launches. These all need high-quality docs to go well.
133
+
**Motivation:** Take three. We have like 6+ new products being launched or going GA in 2026. We're also increasing our headcount by 200+, most of which is engineering. Product docs need to be self-serve in order to scale. Full stop. It's critical that we get engineers and other teams contributing docs regularly by making the process clear and easy for them. The team alone probably can't ship 2x what we're doing now, but we as a company absolutely can.
176
134
177
135
**What we'll ship:**
178
-
179
-
* MVP set of docs for each new product; overview, getting started, concepts, guides, AI, and resources, etc.
180
-
* Potentially ship a new AI docs section to unify our collection of AI dev tools like Max AI, Array, Wizard, MCP, and more
181
-
182
-
**We'll know we're successful when**:
183
-
184
-
* Users adopt new products without friction
185
-
* Positive feedback from users during and after each product launch
186
-
* PostHog is better positioned as platform for dev tools and AI
136
+
- The best team handbook in the company that details how we write product docs
137
+
- A collection of templates, resources, and runbooks to help product docs be self-serve
138
+
- Tooling to maintain docs like a prose linter, automated PR reviews, and screenshot validation
139
+
140
+
**We'll know we're successful when:**
141
+
- New products are launched with a strongline baseline of docs
142
+
- Engineers have a clear understanding of how to write docs and loop in our team
143
+
- An early system for monitoring docs quality and consistency
0 commit comments