Make agents first-class citizens for onboarding and implementation – Matt BrookerMatt Brooker Rafael AudibertRafael Audibert

Note: Rafael will drive this goal while Matt is on parental leave.

Motivation: As an agent, it is hard to sign up, to implement PostHog correctly, and to know what to do with it. The wizard exists and it's amazing at installing PostHog. It is, however, hard to use the wizard as an agent because it's a TUI application. Also, agents don't usually use the wizard as their default way to implement PostHog. They prefer to implement it "from memory" rather than running the wizard or checking our docs.

What we'll ship:

• A production-ready headless CLI wizard that works with any user's coding agent
• Our skills exposed through a CLI, plus a way to make agents aware of it
• A provisioning API and authorization flows for agent-first onboarding via the wizard, which might include headless signups and a first-party OAuth app for the wizard
• Extensions to the wizard platform that the headless and cloud wizards need
• Broader evals of agents attempting to install PostHog when exposed to different scenarios (with/without Wizard/MCP/CLI/docs)

We'll know we're successful when:

• Agents can sign up, provision a project, and implement PostHog without a human opening a browser
• Agents reach for the wizard or our skills instead of implementing PostHog "from memory"
• We can compare how well agents implement PostHog depending on the scenario they are exposed to

Synergy:

• Wizard & Docs TeamWizard & Docs Team owns the underlying wizard platform and agent library, and the TUI wizard. We build the headless wizard on top of it and contribute platform extensions back
• Wizard & Docs TeamWizard & Docs Team is building an official benchmark for agents using our docs. Our evals cover MCP, CLI, and SDKs, and both teams will try Gauge if the pricing makes sense
• Context & MCP TeamContext & MCP Team is choosing the MCP architecture. The CLI and the MCP should expose the same skills and give agents the same experience
• Client Libraries TeamClient Libraries Team is rebuilding the SDKs around shared specifications. New SDKs (`@posthog/browser` v2, `@posthog/next` v1, and others) should be easy for agents to implement, and our evals should catch regressions in how agents use them

Improve the human journey through their time using PostHog – Fernando GomesFernando Gomes

Motivation: As a human, it is hard to know how to get set up and what you can do with PostHog. We have solved some of our onboarding issues and also our complicated sidebar, BUT PostHog is still rooted in a world where we portray our product in the same way we organize our teams internally. This is not how customers want to use the product. They want it to be organized the way their own product is organized instead.

What we'll ship:

• User-centric, task-oriented onboarding for the parts of your product you care about, instead of setting up each PostHog tool one by one
• A cloud in-app wizard for point implementations, such as adding a new product
• Handoffs between the wizard and the PostHog app, so users can start a task in one and finish it in the other. For example, the wizard detects data warehouse sources and users complete source creation in the app
• A review of the onboarding email flow for the current stage of PostHog
• A more careful onboarding flow for each new product you add

We'll know we're successful when:

• More new users reach their first meaningful use of PostHog, and they get there faster
• Users add a new product from the app with the cloud wizard instead of writing the code themselves
• Tasks that start in the wizard finish in the app (and the other way around) without users getting lost

Synergy:

• Wizard & Docs TeamWizard & Docs Team and Growth both own the handoffs between the wizard and the PostHog app
• Self-Driving TeamSelf-Driving Team wants a UI-first onboarding and runs the CLI wizard in a cloud sandbox. We share the cloud wizard infrastructure and the handoff from PostHog onboarding to Self-Driving onboarding
• Platform UX TeamPlatform UX Team is working to make PostHog web simple again. Together, we want to introduce spaces: customers split PostHog into the parts of their own product (e.g. checkout, onboarding, mobile app), and each space brings together the insights, replays, flags, and errors for that part. Spaces should become the default way to view PostHog, instead of the per-product split that mirrors how our teams are organized
• Error Tracking TeamError Tracking Team, Web Analytics TeamWeb Analytics Team, Feature Flags TeamFeature Flags Team, and Experiments TeamExperiments Team all want wizard-guided setup for their products. The cloud wizard should make that easy for them

Cross-sell PostHog products via agents – Rafael AudibertRafael Audibert

Motivation: After a codebase uses one product, how do we make sure agents suggest and implement the other PostHog products that go with it? We have a lot of products, and we have found different ways to cross-sell them to customers: in-app exposition, email campaigns, social media awareness posts, etc. Some of these methods, specifically the ones that happen in our UI, don't translate to a world where the main way customers interact with PostHog is via an agent. This goal is more abstract than the others, so we must try many things to see what sticks.

What we'll ship:

• New product and tool suggestions in MCP and CLI tool call responses
• Incremental skill surfacing that guides users to new products
• Cross-sell and incremental upgrade opportunities in the cloud in-app wizard
• Wizard signals (product and tech stack metadata from user codebases) used to enrich customer profiles and create opportunities for activation, cross-sell, and upgrades in the PostHog app
• More docs that agents can index

We'll know we're successful when:

• Agents suggest a second PostHog product without being asked, and users accept the suggestion
• Codebase signals from the wizard turn into in-app cross-sell and upgrade opportunities that convert

Synergy:

• Wizard & Docs TeamWizard & Docs Team is building a Jev / Decisions API wizard feature that tags user codebases with product and tech stack metadata. We use those signals downstream
• Wizard & Docs TeamWizard & Docs Team is turning docs into a skill library. Incremental skill surfacing builds on it
• Context & MCP TeamContext & MCP Team owns the MCP, where tool call responses can suggest new products
• Self-Driving TeamSelf-Driving Team reports already find problems in a customer's product. They are a natural place to suggest the PostHog product that solves them
• Surfaces TeamSurfaces Team runs agent sessions in PostHog Desktop, which is another place where agents can suggest new products
• Feature Flags TeamFeature Flags Team is shipping a "flag by default" skill that the wizard installs. It's a good model for how other products can cross-sell through agents

Motivation: After a user starts to use a product, how do we deepen their knowledge about that product so that the user uses it more? Each product team should own this for its own product, but not all of them do it well.

What we'll ship:

• A platform that makes it easy for product teams to deepen usage of their own product

Redesign the authentication and onboarding flows – Fernando GomesFernando Gomes

• Built new self-driving optimized onboarding
• Redesigned login/signup flow around the new website design
• Handoff from PostHog onboarding to self-driving onboarding
• Wizard cloud infrastructure

Measure success of the AI positioning at the company level – Rafael AudibertRafael Audibert

• Establish baseline of Code activation
• Monitor impact on existing revenue streams

Streamlined data layer for the RevOps flow – Matt BrookerMatt Brooker

• Model what kind of customer someone is to guide them towards the right onboarding process – Mine KansuMine Kansu
• Avoid keeping stale enriched data
• Replaced Clay with in-house enrichment model
• Built "AI-pilledness" pipeline in the new system