From 1569270ba7c27274e7087538514f284f953c1252 Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Tue, 21 Jul 2026 16:29:25 -0400 Subject: [PATCH 1/5] update handbook with PostHog Desktop rename and cleaned up some stray em dashes --- contents/blog/self-driving-product.mdx | 4 + contents/handbook/brand/foundations.md | 2 +- contents/handbook/brand/tone.md | 8 +- contents/handbook/company/do-more-weird.mdx | 2 +- .../handbook/engineering/ai/ai-platform.md | 12 +- .../handbook/engineering/ai/architecture.md | 12 +- .../handbook/engineering/ai/implementation.md | 16 +- contents/handbook/engineering/ai/products.md | 38 ++--- .../handbook/engineering/ai/team-structure.md | 24 +-- .../engineering/development-process.md | 2 +- .../handbook/engineering/how-we-review.md | 2 +- .../engineering/operations/support-hero.md | 2 +- .../growth/sales/how-to-pitch-self-driving.md | 4 +- .../growth/sales/product-enablement.md | 2 +- .../turning-knowledge-into-agent-skills.md | 2 +- .../marketing/positioning/analytics.md | 32 ++-- .../marketing/positioning/data-pipelines.md | 38 ++--- .../marketing/positioning/data-warehouse.md | 54 +++---- .../handbook/marketing/positioning/desktop.md | 141 ++++++++++++++++++ .../marketing/positioning/endpoints.md | 4 +- .../marketing/positioning/experiments.md | 26 ++-- .../marketing/positioning/feature-flags.md | 36 ++--- .../handbook/marketing/positioning/index.md | 23 +-- .../marketing/positioning/llm-analytics.md | 46 +++--- .../marketing/positioning/posthog-ai.md | 42 +++--- .../marketing/positioning/session-replay.md | 34 ++--- contents/handbook/people/spending-money.md | 2 +- contents/handbook/story.md | 4 +- src/navs/index.js | 4 + 29 files changed, 384 insertions(+), 234 deletions(-) create mode 100644 contents/handbook/marketing/positioning/desktop.md diff --git a/contents/blog/self-driving-product.mdx b/contents/blog/self-driving-product.mdx index d7442f2d77b8..958140c4805c 100644 --- a/contents/blog/self-driving-product.mdx +++ b/contents/blog/self-driving-product.mdx @@ -16,6 +16,10 @@ tags: - PostHog news --- +
+

Update: PostHog Code is now PostHog Desktop – it does a lot more than just write code these days. This post still uses the old name, since that's what we called it at launch.

+
+ Today, [PostHog Code](/desktop) enters beta. It's a desktop app that runs coding agents on top of your product data. The obvious stuff ships itself. The tricky stuff shows up as a prioritized to-do list for you to steer. diff --git a/contents/handbook/brand/foundations.md b/contents/handbook/brand/foundations.md index f4280f5b20ad..378f119028b8 100644 --- a/contents/handbook/brand/foundations.md +++ b/contents/handbook/brand/foundations.md @@ -99,7 +99,7 @@ Use this whenever you need a standard description of PostHog: Everything we offer is one of four things. Use these words exactly: -- **Products** – the surfaces a customer adopts; how you access self-driving. Today that's **Web** (app.posthog.com, where Inbox and PostHog AI live), **Slack**, **MCP**, **CLI**, and **Code** (PostHog Code; becomes **Desktop** in future, once it has non-coding use cases). **Mobile** is coming. The **context warehouse** is a product from a marketing perspective (its own PM/PMM, pricing, and so on), but on posthog.com we present it as the platform everything is built on, *not* as another item in this list. +- **Products** – the surfaces a customer adopts; how you access self-driving. Today that's **Web** (app.posthog.com, where Inbox and PostHog AI live), **Slack**, **MCP**, **CLI**, and **Desktop** (PostHog Desktop, formerly PostHog Code – started coding-focused and expanding to non-coding use cases over time). **Mobile** is coming. The **context warehouse** is a product from a marketing perspective (its own PM/PMM, pricing, and so on), but on posthog.com we present it as the platform everything is built on, *not* as another item in this list. - **Tools** – the functional capabilities accessed through the products: product analytics, session replay, feature flags, experiments, error tracking, surveys, web analytics, and so on (as granular as annotations or comments). We used to call these "apps." - **Context** – the data that feeds the self-driving loop: events, recordings, errors, and logs from PostHog, plus other business data (Slack, code, Notion, support tickets, and so on). This is the fuel. - **Context warehouse** – the data warehouse plus the full context-ingestion pipeline (modelling, data pipelines, batch exports, and so on). Don't say "**PostHog Data Stack**" – the warehouse, modelling, pipelines, and exports are all part of the broader context warehouse, and "Data Stack" isn't something we talk about externally. diff --git a/contents/handbook/brand/tone.md b/contents/handbook/brand/tone.md index ec00c4983bae..8ed56879cddb 100644 --- a/contents/handbook/brand/tone.md +++ b/contents/handbook/brand/tone.md @@ -115,12 +115,12 @@ On that last one: PostHog makes _your_ product self-driving. Keep the customer's "PostHog has more than two dozen varied products for your needs. They are:" - "Introducing PostHog Code, the product editor that:
• Understands your product
• Identifies usage patterns
• Triages bugs and errors for you
• Creates PRs to fix them
• Continuously monitors and improves your product" - "PostHog Code is the product editor that understands your product, identifies usage patterns, triages bugs and errors for you, creates PRs to fix them, and continuously monitors and improves your product." + "Introducing PostHog Desktop, the product editor that:
• Understands your product
• Identifies usage patterns
• Triages bugs and errors for you
• Creates PRs to fix them
• Continuously monitors and improves your product" + "PostHog Desktop is the product editor that understands your product, identifies usage patterns, triages bugs and errors for you, creates PRs to fix them, and continuously monitors and improves your product." - "Fable 5's in PostHog Code (again)" - "We're proud to announce that Fable 5 is now available in PostHog Code. Happy coding!" + "Fable 5's in PostHog Desktop (again)" + "We're proud to announce that Fable 5 is now available in PostHog Desktop. Happy coding!" (reply) "this is incredible" diff --git a/contents/handbook/company/do-more-weird.mdx b/contents/handbook/company/do-more-weird.mdx index ff45a3fb1e62..23f02b4a39b0 100644 --- a/contents/handbook/company/do-more-weird.mdx +++ b/contents/handbook/company/do-more-weird.mdx @@ -27,7 +27,7 @@ Weird ideas are fragile, so the most important feedback you can give if you see - Creating James Hawkins action figures and [filming an ad](https://www.youtube.com/watch?v=xxBqKIBBxQw) for them - Creating a fake boardroom along with fake board meeting for another conference - Putting the HackerNews feed into [the Wizard](/wizard) -- Making PostHog Code say "meep" +- Making PostHog Desktop say "meep" - [DPA generator](/dpa) with fairy tale, Taylor Swift, and Gen Z slang versions - Having a [feet pics](/feet-pics) page (which ranked on Google for "feet pics" for a while) - [Hedgehog Mode](/sparks-joy/hedgehog-mode) and accompanying [documentary](https://www.youtube.com/watch?v=dGaSxBs3OsU) diff --git a/contents/handbook/engineering/ai/ai-platform.md b/contents/handbook/engineering/ai/ai-platform.md index da565ae7a38e..514cd76f939d 100644 --- a/contents/handbook/engineering/ai/ai-platform.md +++ b/contents/handbook/engineering/ai/ai-platform.md @@ -72,7 +72,7 @@ These are the AI features users interact with directly: - **[PostHog AI](/handbook/engineering/ai/products#posthog-ai)**: In-app conversational agent for interacting with PostHog - **[Deep research](/handbook/engineering/ai/products#deep-research)**: Automated investigative research for complex, open-ended problems - **[Session summaries](/handbook/engineering/ai/products#session-summaries)**: Batch analysis of session recordings to find patterns -- **[PostHog Code](/handbook/engineering/ai/products#posthog-code)**: Agent development environment that gives each task its own isolated workspace +- **[PostHog Desktop](/handbook/engineering/ai/products#posthog-desktop)**: Agent development environment that gives each task its own isolated workspace - **[Wizard](/handbook/engineering/ai/products#wizard)**: CLI tool for automated PostHog installation and setup - **[MCP Server](/handbook/engineering/ai/products#mcp)**: Protocol integration for third-party AI tools like Claude Code @@ -88,8 +88,8 @@ The shared components that power all products: How everything connects together: - Products share the same agent features through the MCP server -- Task generation systems (from Deep Research, Session Summaries, PostHog signals) feed PostHog Code -- The Wizard and PostHog Code consume MCP tools to interact with PostHog +- Task generation systems (from Deep Research, Session Summaries, PostHog signals) feed PostHog Desktop +- The Wizard and PostHog Desktop consume MCP tools to interact with PostHog For a detailed technical overview, see [AI platform architecture](/handbook/engineering/ai/architecture). @@ -119,13 +119,13 @@ Analyze hundreds of session recordings in minutes instead of hours. Session summ [Learn more →](/handbook/engineering/ai/products#session-summaries) -### PostHog Code [Beta] +### PostHog Desktop [Beta] An agent development environment that solves the messy workflow problem of engineering with coding agents. Each task gets its own isolated workspace where an agent works — you can guide the agent, review changes, and switch between workspaces, with everything related to a task in one place instead of across your terminal, editor, and GitHub. **Best for**: Product engineers who work on multiple tasks simultaneously and already use agents heavily **Status**: Beta | **Pricing**: Usage-based (AI credits, no markup) with free tier -[Learn more →](/handbook/engineering/ai/products#posthog-code) +[Learn more →](/handbook/engineering/ai/products#posthog-desktop) ### Wizard [General availability] Get PostHog set up in minutes instead of hours. The Wizard detects your tech stack, generates integration code, verifies the installation, and gets you collecting data with minimal manual work. @@ -168,7 +168,7 @@ For a list of key concepts definitions, see the [Glossary](/handbook/engineering The AI platform is actively evolving. Major initiatives include: - **Third-party context integration**: Connect PostHog AI to Slack, Zendesk, and other tools for richer context -- **PostHog Code expansion**: Moving from alpha dogfooding to broader availability +- **PostHog Desktop expansion**: Moving from alpha dogfooding to broader availability - **Deep research refinement**: Improving research strategies and denoising algorithms - **Mode expansion**: Adding more specialized agent modes as product teams identify needs diff --git a/contents/handbook/engineering/ai/architecture.md b/contents/handbook/engineering/ai/architecture.md index b7588938eb04..48e8697ee526 100644 --- a/contents/handbook/engineering/ai/architecture.md +++ b/contents/handbook/engineering/ai/architecture.md @@ -16,7 +16,7 @@ graph TB PostHogAIUI[PostHog AI
In-app Agent] DeepResearch[Deep Research] SessionSum[Session Summaries] - PostHogCode[PostHog Code
Desktop App] + PostHogCode[PostHog Desktop] Wizard[Wizard
CLI Tool] ClaudeCode[Claude Code /
Other AI Tools] end @@ -54,9 +54,9 @@ graph TB 1. **The agent uses dynamic modes**: The single-loop agent architecture uses dynamically loadable modes that expose PostHog capabilities. -2. **MCP provides universal access**: The MCP server makes agent features accessible to any MCP-compatible client. PostHog AI, PostHog Code, Session Summaries, Wizard, and third-party tools like Claude Code all consume the same MCP server. +2. **MCP provides universal access**: The MCP server makes agent features accessible to any MCP-compatible client. PostHog AI, PostHog Desktop, Session Summaries, Wizard, and third-party tools like Claude Code all consume the same MCP server. -3. **Task generation feeds PostHog Code**: Signals from PostHog data, PostHog AI conversations, and Deep Research investigations are processed into structured tasks that PostHog Code can execute. +3. **Task generation feeds PostHog Desktop**: Signals from PostHog data, PostHog AI conversations, and Deep Research investigations are processed into structured tasks that PostHog Desktop can execute. 4. **Shared features**: Every surface consumes the same agent features through the MCP, ensuring consistency across the platform. @@ -172,11 +172,11 @@ The problem we needed to solve: PostHog AI and the MCP server were developed by The solution is an abstraction layer. Agent modes expose both high-level LLM tools (like "create a funnel with these parameters") and low-level API endpoint tools (like "call POST /api/projects/{id}/insights"). Both PostHog AI and the MCP have access to the same features, just through different interfaces. -## How PostHog Code and Wizard fit in +## How PostHog Desktop and Wizard fit in -Both PostHog Code and the Wizard currently consume the MCP. This integration gives them access to all the agent modes we're building. If Claude Code (which PostHog Code uses for code generation) ever becomes a bottleneck, we could swap in PostHog's own single-loop agent since they share the same mental model. We'd need to copy over Claude Code's terminal and file system tools (bash, grep, etc.) and add them as core tools. +Both PostHog Desktop and the Wizard currently consume the MCP. This integration gives them access to all the agent modes we're building. If Claude Code (which PostHog Desktop uses for code generation) ever becomes a bottleneck, we could swap in PostHog's own single-loop agent since they share the same mental model. We'd need to copy over Claude Code's terminal and file system tools (bash, grep, etc.) and add them as core tools. -We could also tag modes for specific interfaces. For example, a `CodingMode(tags=["posthog-code"])` would only be exposed to the PostHog Code agent, not to PostHog AI, because it's specific to code generation workflows. +We could also tag modes for specific interfaces. For example, a `CodingMode(tags=["posthog-code"])` would only be exposed to the PostHog Desktop agent, not to PostHog AI, because it's specific to code generation workflows. ## Glossary diff --git a/contents/handbook/engineering/ai/implementation.md b/contents/handbook/engineering/ai/implementation.md index a7cd2f43ae93..02241749c647 100644 --- a/contents/handbook/engineering/ai/implementation.md +++ b/contents/handbook/engineering/ai/implementation.md @@ -8,7 +8,7 @@ This page provides implementation guidance for building AI features at PostHog. ## How PostHog AI works across surfaces -PostHog AI isn't a single product – it's a platform that works wherever customers work. Through a combination of MCP tools and skills, PostHog AI is available across any agent of the customer's choice: PostHog AI in the web, PostHog Code, Claude Code, Cursor, Codex, and others. +PostHog AI isn't a single product – it's a platform that works wherever customers work. Through a combination of MCP tools and skills, PostHog AI is available across any agent of the customer's choice: PostHog AI in the web, PostHog Desktop, Claude Code, Cursor, Codex, and others. All of these surfaces share the same underlying capabilities. The MCP server exposes PostHog's API as atomic tools, and skills teach agents how to compose those tools into workflows. When a product team adds a new MCP tool or writes a new skill, every surface benefits automatically. @@ -22,9 +22,9 @@ PostHog AI in the web is a sandboxed coding agent built on the Agents SDK (Claud - **User-created custom skills and capabilities** – customers can create their own skills to teach the agent domain-specific workflows. - **Generative UI for complex needs** – for the most complex UI requirements, the agent can generate custom visualizations and interfaces on the fly. -### PostHog Code +### PostHog Desktop -PostHog Code is a desktop agent that turns PostHog signals into shipped code. It watches PostHog for problems (errors, frustration patterns, user feedback) and automatically creates tasks, generates fixes, and opens pull requests with human oversight at key decision points. +PostHog Desktop is a desktop agent that turns PostHog signals into shipped code. It watches PostHog for problems (errors, frustration patterns, user feedback) and automatically creates tasks, generates fixes, and opens pull requests with human oversight at key decision points. ### Third-party agents @@ -98,13 +98,13 @@ So that users can learn how to use PostHog without worrying about being charged, ### How users should think about our products -**PostHog AI** is the main PostHog product for AI interactions. You can use it in the web for the richest experience, through PostHog Code for code-generation workflows, or through any third-party agent via MCP. The web UX is best for sharing, navigation, and linking between AI results and PostHog artifacts. PostHog AI is also trained on PostHog-specific patterns and your actual usage data, so it provides higher quality, more contextual results than a general-purpose AI. +**PostHog AI** is the main PostHog product for AI interactions. You can use it in the web for the richest experience, through PostHog Desktop for code-generation workflows, or through any third-party agent via MCP. The web UX is best for sharing, navigation, and linking between AI results and PostHog artifacts. PostHog AI is also trained on PostHog-specific patterns and your actual usage data, so it provides higher quality, more contextual results than a general-purpose AI. **Deep research** is a feature available within PostHog AI, but also accessible through its own dedicated UI if you want to jump straight into research. Use it for open-ended investigative work where you're trying to understand a complex problem. **Session summaries** is callable from PostHog AI and Deep research, and also has its own UI. Use it when you need to analyze many session recordings and extract patterns or issues. -**PostHog Code** is a desktop product for single-engineer use. It's separate from PostHog AI because the workflow is different – you're not asking questions, you're letting an AI agent watch PostHog for problems and automatically fix them in your codebase. Think of it as an AI assistant that lives in your development environment. +**PostHog Desktop** is a desktop product for single-engineer use. It's separate from PostHog AI because the workflow is different – you're not asking questions, you're letting an AI agent watch PostHog for problems and automatically fix them in your codebase. Think of it as an AI assistant that lives in your development environment. **MCP** is for users who prefer to work in third-party tools like Claude Code, Cursor, or Codex. You get access to PostHog's data and can combine it with other MCP servers (like Hubspot or Zendesk). The trade-off is you don't get PostHog AI's polished UX or PostHog-specific optimizations. @@ -114,7 +114,7 @@ So that users can learn how to use PostHog without worrying about being charged, 2. **Write YAML configs and skills.** Use the monorepo Claude Code skills to scaffold tool definitions and write skills (TODO: dedicated skill for this). 3. **Build skills and dump them locally.** Run `hogli build:skills` to render all skills, then unzip them into `.agents/skills/` so Claude Code can pick them up during local testing: `unzip -o products/posthog_ai/dist/skills.zip -d .agents/skills/`. 4. **Test with headless agents, not UIs.** Forget about UIs – that's for humans. Test your tools and skills by talking to Claude Code or another headless agent. If the agent can accomplish the job, the capability works. -5. **Test with PostHog Code.** Sign in to a local environment in PostHog Code and verify the end-to-end workflow. +5. **Test with PostHog Desktop.** Sign in to a local environment in PostHog Desktop and verify the end-to-end workflow. 6. **Alternatively, add the local MCP server to Claude Code.** Run `claude mcp add --transport http posthog-local http://localhost:8787/mcp` to point Claude Code at your local MCP server. @@ -122,11 +122,11 @@ So that users can learn how to use PostHog without worrying about being charged, ### Third-party context integration -We want to connect PostHog AI to third-party tools for additional context. Imagine PostHog AI analyzing data across PostHog, Slack messages, and Zendesk tickets to understand not just what users are doing, but what they're saying and reporting. This data could also generate signals for PostHog Code – if users are complaining about a bug in Slack and PostHog sees errors in the same area, that's a strong signal to investigate and potentially fix automatically. +We want to connect PostHog AI to third-party tools for additional context. Imagine PostHog AI analyzing data across PostHog, Slack messages, and Zendesk tickets to understand not just what users are doing, but what they're saying and reporting. This data could also generate signals for PostHog Desktop – if users are complaining about a bug in Slack and PostHog sees errors in the same area, that's a strong signal to investigate and potentially fix automatically. ### Continuous instrumentation -The Wizard's future evolution involves continuous instrumentation – watching your codebase and suggesting event tracking for new features, filling gaps in existing tracking, and standardizing event patterns. This could integrate with PostHog Code to automatically handle PostHog instrumentation when generating code. +The Wizard's future evolution involves continuous instrumentation – watching your codebase and suggesting event tracking for new features, filling gaps in existing tracking, and standardizing event patterns. This could integrate with PostHog Desktop to automatically handle PostHog instrumentation when generating code. ### Research improvements diff --git a/contents/handbook/engineering/ai/products.md b/contents/handbook/engineering/ai/products.md index 0a33c08eb02f..ffcd06b146f2 100644 --- a/contents/handbook/engineering/ai/products.md +++ b/contents/handbook/engineering/ai/products.md @@ -228,19 +228,19 @@ Access Session Summaries through PostHog AI, Deep Research, or its dedicated UI Session summaries is in alpha. The PostHog AI team owns Session summaries. It's working well for error and frustration detection, and early users report finding issues they would have missed. We're refining the clustering algorithms (sometimes it groups issues too broadly or too narrowly) and integrating video and GIF analysis to support findings with visual confirmation. -## PostHog Code [Under development] +## PostHog Desktop [Under development] -PostHog Code is our most ambitious bet: an agent development environment that turns PostHog data into shipped code. The vision is to free product engineers from distractions so they can focus on what they love — building great features — by automating all the chores that eat up their day. +PostHog Desktop is our most ambitious bet: an agent development environment that turns PostHog data into shipped code. The vision is to free product engineers from distractions so they can focus on what they love — building great features — by automating all the chores that eat up their day. ### The problem we're solving Today, product engineers spend most of their day managing random inputs: Slack messages, GitHub notifications, tickets, emails, and alerts from various monitoring tools. This work is essential but time-consuming. Experienced AI-native engineers have already evolved a workaround — they practice "structured development," creating PRDs, breaking work into tasks, and shipping incrementally. Tools like [Claude Code](https://www.claude.com/product/claude-code) or [Cursor](https://cursor.com/) only work well when given clean context and well-defined tasks. -PostHog Code aims to productize that discipline, turning chaos into structured, buildable work. +PostHog Desktop aims to productize that discipline, turning chaos into structured, buildable work. ### Who we're building for -PostHog Code is designed for experienced product engineers who already use AI coding tools regularly. We're explicitly not targeting non-technical "vibe coders" or hobbyist users. Our initial customer profile is early-stage startups with 2-10 engineers and hundreds to low thousands of users. We'll expand to larger startups later as internal workflows and scale requirements become more complex. +PostHog Desktop is designed for experienced product engineers who already use AI coding tools regularly. We're explicitly not targeting non-technical "vibe coders" or hobbyist users. Our initial customer profile is early-stage startups with 2-10 engineers and hundreds to low thousands of users. We'll expand to larger startups later as internal workflows and scale requirements become more complex. ### How it works: From Signals to shipped code @@ -254,27 +254,27 @@ Here's the flow: 3. **Task execution**: Once a task is defined, it gets assigned to a workflow. Different tasks need different approaches — a well-defined bug fix might be a one-shot fix with human QA, while a vague feature request might need definition, breaking into chunks, gradual shipping behind a flag, and automated feedback collection. -4. **Coding**: PostHog Code uses an agent running in a cloud sandbox (though we support local execution too). The agent clones your repo, reads your codebase for context, makes changes, writes tests, and opens a pull request. Changes are automatically wrapped in feature flags when appropriate. +4. **Coding**: PostHog Desktop uses an agent running in a cloud sandbox (though we support local execution too). The agent clones your repo, reads your codebase for context, makes changes, writes tests, and opens a pull request. Changes are automatically wrapped in feature flags when appropriate. -5. **Human oversight**: You're always in control. The desktop app shows you what PostHog Code is working on, lets you review and edit tasks, and requires your approval before shipping. This "human-in-the-loop" approach means you can trust PostHog Code to work in the background while you sleep, but nothing ships without your sign-off. +5. **Human oversight**: You're always in control. The desktop app shows you what PostHog Desktop is working on, lets you review and edit tasks, and requires your approval before shipping. This "human-in-the-loop" approach means you can trust PostHog Desktop to work in the background while you sleep, but nothing ships without your sign-off. ### Why a desktop app? -This is a crucial design decision. We could have built PostHog Code directly into the PostHog web app, and it would work. But it wouldn't generate the adoption we need. +This is a crucial design decision. We could have built PostHog Desktop directly into the PostHog web app, and it would work. But it wouldn't generate the adoption we need. -Desktop apps win because of bottom-up adoption. Individual engineers can choose tools that make them more productive in a permissionless, frictionless way. A desktop app feels like a personal tool — like VS Code, Cursor, or your terminal — rather than a team product that requires management buy-in. Engineers already make personal choices about vim vs VSCode, which terminal to use, which AI coding assistant to try. PostHog Code slots into that category. +Desktop apps win because of bottom-up adoption. Individual engineers can choose tools that make them more productive in a permissionless, frictionless way. A desktop app feels like a personal tool — like VS Code, Cursor, or your terminal — rather than a team product that requires management buy-in. Engineers already make personal choices about vim vs VSCode, which terminal to use, which AI coding assistant to try. PostHog Desktop slots into that category. -The UX also matters more for tools you use all day, not just a few times a week. PostHog Code is designed to feel like something between Warp, Ghostty, and Cursor: super fast, keyboard-first with lots of shortcuts, easy to navigate with tabs and split windows. Think of it as having the directness of a CLI but with the richness of a UI when you need it. +The UX also matters more for tools you use all day, not just a few times a week. PostHog Desktop is designed to feel like something between Warp, Ghostty, and Cursor: super fast, keyboard-first with lots of shortcuts, easy to navigate with tabs and split windows. Think of it as having the directness of a CLI but with the richness of a UI when you need it. ### The interface -PostHog Code is tab-based with the home tab being a task list. You navigate with arrow keys, click a task to open it in a new tab with a two-pane view: task details on the left (title, description, tags, origin, PR link) and a live log of activities on the right. When a task is in progress, it streams output to this log so you can watch the agent work. There's also a workflow builder view where you can see tasks moving through stages kanban-style. +PostHog Desktop is tab-based with the home tab being a task list. You navigate with arrow keys, click a task to open it in a new tab with a two-pane view: task details on the left (title, description, tags, origin, PR link) and a live log of activities on the right. When a task is in progress, it streams output to this log so you can watch the agent work. There's also a workflow builder view where you can see tasks moving through stages kanban-style. ### Technical architecture -PostHog Code is built as an Electron app for speed, familiarity (React), and cross-platform ease. When a task kicks off, we have two execution options: +PostHog Desktop is built as an Electron app for speed, familiarity (React), and cross-platform ease. When a task kicks off, we have two execution options: -**Cloud agent** (preferred): Tasks execute in a cloud sandbox owned by the PostHog AI team. The agent runs in an isolated environment, clones the repo, does its work, and pushes to a branch. The downside is you need to grant GitHub app access. The upside is truly magical — PostHog Code can work on tasks while you sleep, and you wake up to PRs ready for review. +**Cloud agent** (preferred): Tasks execute in a cloud sandbox owned by the PostHog AI team. The agent runs in an isolated environment, clones the repo, does its work, and pushes to a branch. The downside is you need to grant GitHub app access. The upside is truly magical — PostHog Desktop can work on tasks while you sleep, and you wake up to PRs ready for review. **Local agent** (more permissionless): We spin up Claude Code-like execution in the background on your local filesystem. This is the most permissionless version, closest to how developers use Claude Code today. We still give it access to the MCP and PostHog tools, and we likely need to proxy through our infrastructure to maintain control and provide a smooth experience. @@ -284,7 +284,7 @@ We support both modes, but push for cloud execution as the optimal experience. ```mermaid graph TB - subgraph "PostHog Code Desktop App (Electron)" + subgraph "PostHog Desktop (Electron app)" UI[Task List UI] Backend[Backend Service] end @@ -323,17 +323,17 @@ graph TB ### What kinds of tasks? -PostHog Code isn't just for data-driven bug fixes. The system for shipping a fix is the same as the system for shipping any feature. A vague task needs definition, then breaking into chunks, then shipping with proper releases planned. A small, well-defined task just needs a one-shot fix and QA. +PostHog Desktop isn't just for data-driven bug fixes. The system for shipping a fix is the same as the system for shipping any feature. A vague task needs definition, then breaking into chunks, then shipping with proper releases planned. A small, well-defined task just needs a one-shot fix and QA. -Even inspiration-driven features (not from user data) benefit from PostHog Code's workflow: add event tracking, ship behind a flag, automatically message users for feedback, set up an experiment to measure impact. PostHog Code productizes best practices for shipping features, not just fixing bugs. +Even inspiration-driven features (not from user data) benefit from PostHog Desktop's workflow: add event tracking, ship behind a flag, automatically message users for feedback, set up an experiment to measure impact. PostHog Desktop productizes best practices for shipping features, not just fixing bugs. ### Current status -Right now we're focused on dogfooding — getting the to build everything using PostHog Code itself. This lets us refine product quality and identify friction fast. +Right now we're focused on dogfooding — getting the to build everything using PostHog Desktop itself. This lets us refine product quality and identify friction fast. -### For engineers not using PostHog Code +### For engineers not using PostHog Desktop -When PostHog Code isn't the right fit (maybe you don't trust AI to ship code automatically, or your workflow is very particular), we offer "copy prompt" features throughout PostHog. In error tracking, for example, you can generate an AI prompt to fix an error and paste it into your own code editor. This bridges the gap for engineers who want AI assistance but prefer to maintain manual control. +When PostHog Desktop isn't the right fit (maybe you don't trust AI to ship code automatically, or your workflow is very particular), we offer "copy prompt" features throughout PostHog. In error tracking, for example, you can generate an AI prompt to fix an error and paste it into your own code editor. This bridges the gap for engineers who want AI assistance but prefer to maintain manual control. ### Ownership @@ -395,7 +395,7 @@ The Wizard's long-term vision is much broader than one-time setup. Imagine: - **Continuous instrumentation**: The Wizard could watch your codebase and suggest event tracking for new features. "I noticed you added a new checkout flow — want me to add tracking events?" - **Instrumentation improvements**: "Your signup flow isn't tracking all the steps — I can add events to fill the gaps." - **Best practices**: "You're tracking events in 5 different ways. I can standardize this for you." -- **Integration with PostHog Code**: The Wizard is already integrated into PostHog Code, handling PostHog instrumentation automatically when generating code (feature flags, experiments, custom events). +- **Integration with PostHog Desktop**: The Wizard is already integrated into PostHog Desktop, handling PostHog instrumentation automatically when generating code (feature flags, experiments, custom events). This would turn the Wizard from a one-time setup tool into an ongoing assistant that keeps your PostHog instrumentation clean and comprehensive. diff --git a/contents/handbook/engineering/ai/team-structure.md b/contents/handbook/engineering/ai/team-structure.md index 39c101270a01..793786514312 100644 --- a/contents/handbook/engineering/ai/team-structure.md +++ b/contents/handbook/engineering/ai/team-structure.md @@ -30,15 +30,15 @@ The PostHog Desktop team owns the desktop app and the task execution pipeline. - [Write skills](/handbook/engineering/ai/writing-skills) that teach agents how to accomplish jobs in your domain - Build UI for specific personas using MCP Apps when needed -Once you ship a tool or skill, it's automatically available across every surface – PostHog AI in the web, PostHog Code, Claude Code, Cursor, and any other MCP-compatible agent. +Once you ship a tool or skill, it's automatically available across every surface – PostHog AI in the web, PostHog Desktop, Claude Code, Cursor, and any other MCP-compatible agent. ## How the teams connect Together, these teams form the [product autonomy loop](/handbook/engineering/ai/ai-platform#vision-product-autonomy): -- **Signals** surfaces useful data from PostHog, creates a task with context, and the cloud agent works on it. You review and iterate in PostHog Code. -- **PostHog AI** owns the background sandboxed agents and can start coding agent tasks during chats. These tasks are inspectable in both the web product and PostHog Code. -- **PostHog Code** is where engineers review, guide, and manage agent work across all their tasks in one place. +- **Signals** surfaces useful data from PostHog, creates a task with context, and the cloud agent works on it. You review and iterate in PostHog Desktop. +- **PostHog AI** owns the background sandboxed agents and can start coding agent tasks during chats. These tasks are inspectable in both the web product and PostHog Desktop. +- **PostHog Desktop** is where engineers review, guide, and manage agent work across all their tasks in one place. - **Product teams** ship their own MCP tools and skills independently. Once shipped, these are automatically available across every surface. ## Integration vectors for product teams @@ -51,7 +51,7 @@ The most obvious and lowest-effort vector. Expose your product's APIs through th **Effort**: Low -**Consumers**: PostHog AI, PostHog Code, coding agents (Claude Code, Codex, etc.), Wizard, vibecoding platforms (Lovable, Replit, etc.), ChatGPT & Claude Desktop, and more. +**Consumers**: PostHog AI, PostHog Desktop, coding agents (Claude Code, Codex, etc.), Wizard, vibecoding platforms (Lovable, Replit, etc.), ChatGPT & Claude Desktop, and more. ### Skills: Teach agents how to do jobs @@ -59,23 +59,23 @@ If you've already exposed your APIs, the next step is explaining how an agent sh **Effort**: Medium, but the impact is very high. -**Consumers**: PostHog AI, PostHog Code, coding agents (Claude Code, Codex, etc.), ChatGPT & Claude Desktop, and more. +**Consumers**: PostHog AI, PostHog Desktop, coding agents (Claude Code, Codex, etc.), ChatGPT & Claude Desktop, and more. ### Signals: Feed the autonomy loop -If your product produces actionable or near-actionable signals — an insight threshold reached, a new error-tracking issue, a frustration pattern detected — use the signals API so agents can discover these hints and act on them later. Signals are what enable the [product autonomy loop](/handbook/engineering/ai/ai-platform#vision-product-autonomy). PostHog Code acts on plans generated from these signals. +If your product produces actionable or near-actionable signals — an insight threshold reached, a new error-tracking issue, a frustration pattern detected — use the signals API so agents can discover these hints and act on them later. Signals are what enable the [product autonomy loop](/handbook/engineering/ai/ai-platform#vision-product-autonomy). PostHog Desktop acts on plans generated from these signals. **Effort**: Low to medium. -**Consumers**: PostHog Code (local development) and PostHog AI (background agents). +**Consumers**: PostHog Desktop (local development) and PostHog AI (background agents). -### PostHog Code: Features for the agentic development environment +### PostHog Desktop: Features for the agentic development environment -PostHog Code is an agentic development environment where coding agents work on tasks in isolated workspaces. If your product area can make those agents smarter or the engineer's workflow faster, you can build features directly into it. Think PR reviews that check session recordings for regressions, QA steps that verify instrumentation coverage, or task prioritization that weighs your product's signals. This is the highest-effort vector but also the most deeply integrated. +PostHog Desktop is an agentic development environment where coding agents work on tasks in isolated workspaces. If your product area can make those agents smarter or the engineer's workflow faster, you can build features directly into it. Think PR reviews that check session recordings for regressions, QA steps that verify instrumentation coverage, or task prioritization that weighs your product's signals. This is the highest-effort vector but also the most deeply integrated. **Effort**: High. -**Consumers**: PostHog Code. +**Consumers**: PostHog Desktop. ### Automations & background agents @@ -83,7 +83,7 @@ Run PostHog AI based on triggers from PostHog Workflows, CRON, Temporal, etc., t **Effort**: Medium to high. -**Consumers**: Your persona using the web browser (UI), PostHog AI, PostHog Code, coding agents (Claude Code, Codex, etc.), Wizard, vibecoding platforms (Lovable, Replit, etc.), ChatGPT & Claude Desktop, and more. +**Consumers**: Your persona using the web browser (UI), PostHog AI, PostHog Desktop, coding agents (Claude Code, Codex, etc.), Wizard, vibecoding platforms (Lovable, Replit, etc.), ChatGPT & Claude Desktop, and more. ## How to get started diff --git a/contents/handbook/engineering/development-process.md b/contents/handbook/engineering/development-process.md index bd9a3fac89fb..c609f7a9cf36 100644 --- a/contents/handbook/engineering/development-process.md +++ b/contents/handbook/engineering/development-process.md @@ -119,7 +119,7 @@ When you have a piece of code ready to be reviewed, create a PR. Link the PR to All PRs should be attributable to a human author as far as possible, even if they were assisted by an agent. -Fully automatically generated PRs might come from an agent like PostHog Code or from systems like Dependabot. These PRs are fine, but they should be clearly labelled as such and include a clear description of the changes being made and any relevant context about the generation process. These PRs should in turn never be attributed to a human author, as the changes were not directly or indirectly made by a human. +Fully automatically generated PRs might come from an agent like PostHog Desktop or from systems like Dependabot. These PRs are fine, but they should be clearly labelled as such and include a clear description of the changes being made and any relevant context about the generation process. These PRs should in turn never be attributed to a human author, as the changes were not directly or indirectly made by a human. For external contributors, our [AI contributions policy](https://github.com/PostHog/posthog/blob/master/AI_POLICY.md) covers expectations around AI-assisted PRs. diff --git a/contents/handbook/engineering/how-we-review.md b/contents/handbook/engineering/how-we-review.md index 1e39bfc9dcd8..8b795a29daa7 100644 --- a/contents/handbook/engineering/how-we-review.md +++ b/contents/handbook/engineering/how-we-review.md @@ -10,7 +10,7 @@ Almost all PRs made to PostHog repositories need a review before merging. We do ## Review requirements -PRs can be written by humans or by agents (like PostHog Code). See [Creating PRs](/handbook/engineering/development-process#creating-prs) for how we distinguish AI-assisted human-authored PRs from fully automatically generated agent-authored PRs. Either way, the normal rule is that every PR needs a review before merging, and a human always merges. If you need an urgent review, ask in the `#dev-stamp-exchange` Slack channel. For true emergencies where no one else is available, an admin can bypass review requirements. +PRs can be written by humans or by agents (like PostHog Desktop). See [Creating PRs](/handbook/engineering/development-process#creating-prs) for how we distinguish AI-assisted human-authored PRs from fully automatically generated agent-authored PRs. Either way, the normal rule is that every PR needs a review before merging, and a human always merges. If you need an urgent review, ask in the `#dev-stamp-exchange` Slack channel. For true emergencies where no one else is available, an admin can bypass review requirements. Who should review depends on who wrote the code: diff --git a/contents/handbook/engineering/operations/support-hero.md b/contents/handbook/engineering/operations/support-hero.md index 87e1aed2b438..a7d01076c3cc 100644 --- a/contents/handbook/engineering/operations/support-hero.md +++ b/contents/handbook/engineering/operations/support-hero.md @@ -69,7 +69,7 @@ It might be an intense week, but you're also going to solve so many real problem Check the `#papercuts` Slack channel during your rotation and pick up any reports that relate to your team's area. For each one, pick one of the following: -- **Reply** to the reporter acknowledging the papercut, then either get a fix shipped or open a GitHub issue to track it if it needs more scoping. How you get the fix out is up to you – prompting PostHog Code is often the fastest path, but feel free to fix it however you like. +- **Reply** to the reporter acknowledging the papercut, then either get a fix shipped or open a GitHub issue to track it if it needs more scoping. How you get the fix out is up to you – prompting PostHog Desktop is often the fastest path, but feel free to fix it however you like. - **React with ❌** to reject the papercut (for example, if the behavior is intentional). A brief reply explaining why is appreciated. - **React with ✅** once you've shipped a fix or improvement. diff --git a/contents/handbook/growth/sales/how-to-pitch-self-driving.md b/contents/handbook/growth/sales/how-to-pitch-self-driving.md index 1861257ae884..fd0f8e6aab44 100644 --- a/contents/handbook/growth/sales/how-to-pitch-self-driving.md +++ b/contents/handbook/growth/sales/how-to-pitch-self-driving.md @@ -42,14 +42,14 @@ The honest catch for us is that a reverse demo only works once there's enough cl The whole demo depends on there being real signals to work from, so set that up before the call: - Ask them to turn on error tracking and session replays for a window of time ahead of the call, so the agent has fresh, real signals to act on by the time you meet. -- Have them get PostHog Code downloaded and their GitHub and PostHog connected, so they can kick off a PR live. +- Have them get PostHog Desktop downloaded and their GitHub and PostHog connected, so they can kick off a PR live. - Frame the cost honestly: offer to credit any usage on errors and replays during the demo window, since you need them on to show it at its best, and they can turn them back off after. If it wows them, they'll want to keep them on anyway, and that's the flywheel starting. #### Running it Let them drive the whole way. You narrate, they click. -1. Have them open the PostHog Code inbox. +1. Have them open the PostHog Desktop inbox. 2. Walk them through what they're seeing in the reports and PRs tabs, using their own data. 3. Have them pick a report to inspect and kick off a PR from it themselves. 4. Explain the self-driving part: they can set it up to handle bugfix and maintenance PRs automatically, while humans still drive product decisions and new features. (This is the same line as "robots do maintenance, humans do creative work" below, made concrete.) diff --git a/contents/handbook/growth/sales/product-enablement.md b/contents/handbook/growth/sales/product-enablement.md index a534c2e73f6a..cb1fba5d9b3c 100644 --- a/contents/handbook/growth/sales/product-enablement.md +++ b/contents/handbook/growth/sales/product-enablement.md @@ -82,7 +82,7 @@ All content should include a "last updated" date so team members know they're wo | Data warehouse | Ryan | - | | AI Observability | Leo | - | | Workflows | Phil | - | -| PostHog Code | Landon | - | +| PostHog Desktop | Landon | - | | Logs | Sean | - | | Legal and Compliance | Christophe | - | diff --git a/contents/handbook/growth/sales/turning-knowledge-into-agent-skills.md b/contents/handbook/growth/sales/turning-knowledge-into-agent-skills.md index a6b189ae1038..45c59ceff397 100644 --- a/contents/handbook/growth/sales/turning-knowledge-into-agent-skills.md +++ b/contents/handbook/growth/sales/turning-knowledge-into-agent-skills.md @@ -4,7 +4,7 @@ sidebar: Handbook showTitle: true --- -Our documentation is a critical piece of PostHog's **context flywheel** – a system that connects our codebase to our docs, which then feeds into our AI agents, the [Wizard](/handbook/wizard-and-docs/developing-the-wizard), and PostHog Code. When documentation is outdated, the agents that help customers integrate PostHog become outdated too. +Our documentation is a critical piece of PostHog's **context flywheel** – a system that connects our codebase to our docs, which then feeds into our AI agents, the [Wizard](/handbook/wizard-and-docs/developing-the-wizard), and PostHog Desktop. When documentation is outdated, the agents that help customers integrate PostHog become outdated too. This means your knowledge directly powers our AI tools. When you write down what you know, it doesn't just help humans – it helps robots help customers faster. diff --git a/contents/handbook/marketing/positioning/analytics.md b/contents/handbook/marketing/positioning/analytics.md index f71a2c74ac70..c7adaaad2fb8 100644 --- a/contents/handbook/marketing/positioning/analytics.md +++ b/contents/handbook/marketing/positioning/analytics.md @@ -8,13 +8,13 @@ showTitle: true ## Elevator pitch -PostHog Analytics covers funnels, retention, trends, user paths, correlation analysis, and SQL — with autocapture so you never miss the event that mattered. Every graph links directly to the session recordings and feature flag states behind it. And because analytics is built into the same platform as replay, flags, experiments, and the data warehouse, agents can query it mid-loop without switching tools. +PostHog Analytics covers funnels, retention, trends, user paths, correlation analysis, and SQL – with autocapture so you never miss the event that mattered. Every graph links directly to the session recordings and feature flag states behind it. And because analytics is built into the same platform as replay, flags, experiments, and the data warehouse, agents can query it mid-loop without switching tools. Amplitude and Mixpanel tell you what happened. PostHog tells you what happened *and* lets you act on it. ## The unique belief (in terms of analytics) -PostHog is building the infrastructure for self-driving product development. The [product autonomy loop](/blog/self-driving-product) — signals in, work out, evaluation, repeat — only closes if agents can measure whether their changes worked. Analytics isn't the end of the workflow; it's the truth the entire system runs on. Every funnel, retention chart, and correlation PostHog generates is a queryable signal. PostHog Code re-queries those same dashboards post-merge to evaluate its own work, or you can manually query the data yourself either via the MCP or with PostHog AI. +PostHog is building the infrastructure for self-driving product development. The [product autonomy loop](/blog/self-driving-product) – signals in, work out, evaluation, repeat – only closes if agents can measure whether their changes worked. Analytics isn't the end of the workflow; it's the truth the entire system runs on. Every funnel, retention chart, and correlation PostHog generates is a queryable signal. PostHog Desktop re-queries those same dashboards post-merge to evaluate its own work, or you can manually query the data yourself either via the MCP or with PostHog AI. Analytics is the memory of everything users have done. Self-driving development is impossible without it. @@ -28,7 +28,7 @@ Analytics is the memory of everything users have done. Self-driving development ### Who this isn't for -- Teams who need advanced cohort modeling and data science workflows — other platforms have more mature statistical tooling here. +- Teams who need advanced cohort modeling and data science workflows – other platforms have more mature statistical tooling here. - Enterprises needing deep data governance (e.g. warehouse native requirements) without also adopting the broader PostHog platform. ## Messaging @@ -37,33 +37,33 @@ Analytics is the memory of everything users have done. Self-driving development **Problem:** Agents that only generate insights and dashboards are read-only. The product autonomy loop requires a system that can query product metrics, interpret the result, and use it to decide whether a change worked. -**Solution:** PostHog exposes every insight, dashboard, and HogQL query to PostHog Code, the MCP, and other agent runtimes. Agents can build dashboards, check event volume, and measure impact, and suggest changes based on results — all from within the loop, without human intervention. +**Solution:** PostHog exposes every insight, dashboard, and HogQL query to PostHog Desktop, the MCP, and other agent runtimes. Agents can build dashboards, check event volume, and measure impact, and suggest changes based on results – all from within the loop, without human intervention. **Supporting features:** - MCP: lets agents query PostHog from Claude Code, Cursor, and any MCP-compatible runtime - HogQL: full SQL access on your event stream - Autocapture: instrument your product retrospectively, not just prospectively -- PostHog Code: The self-driving product development platform +- PostHog Desktop: The self-driving product development platform ### Message 2: Autocapture means you never miss the signal that mattered **Problem:** Traditional analytics starts too early and answers too late. You have to instrument an event before you know it matters, then wait around for data after the decision window has closed. -**Solution:** PostHog's autocapture records clicks, pageviews, form submissions, and rage clicks from the moment you install the SDK — no manual instrumentation required. You can always go back and analyze behavior you didn't know you'd need. And installation is easy with the Wizard! +**Solution:** PostHog's autocapture records clicks, pageviews, form submissions, and rage clicks from the moment you install the SDK – no manual instrumentation required. You can always go back and analyze behavior you didn't know you'd need. And installation is easy with the Wizard! **Supporting features:** - Autocapture on web and mobile -- Retroactive event definition — define events from captured data after the fact +- Retroactive event definition – define events from captured data after the fact - PostHog AI: ask questions about your data in plain English -### Message 3: One platform — analytics, replay, flags, experiments, warehouse +### Message 3: One platform – analytics, replay, flags, experiments, warehouse **Problem:** Amplitude + FullStory + LaunchDarkly + Optimizely + Segment = five vendors, five bills, five contracts, five sets of data that don't talk to each other without custom integrations. **Solution:** PostHog covers the full product intelligence loop in one platform. Every metric links to the sessions behind it. Every experiment is built on feature flags. Every flag state is queryable alongside product events. **Supporting features:** -- 1M events/month free, forever — no time limit +- 1M events/month free, forever – no time limit - No seat-based pricing - Group analytics for B2B account-level insights - Direct SQL access via HogQL and the data warehouse @@ -75,9 +75,9 @@ Analytics is the memory of everything users have done. Self-driving development **Their approach:** Deep analytics with advanced behavioral cohorts, data science integrations, and a mature product. Seat-based pricing. No native feature flags. **Where PostHog wins:** -- Usage-based pricing — no seat charges as your team grows +- Usage-based pricing – no seat charges as your team grows - Native session replay, feature flags, and experiments included -- PostHog Code agent integration; Amplitude has no equivalent +- PostHog Desktop agent integration; Amplitude has no equivalent - 1M events/month free tier is more generous than Amplitude's ### vs Mixpanel @@ -85,11 +85,11 @@ Analytics is the memory of everything users have done. Self-driving development **Their approach:** Clean, event-centric analytics with strong mobile support. No native feature flags. MTU-based pricing can surprise at scale. **Where PostHog wins:** -- No MTU pricing — pay per event, not per user, with a huge free tier +- No MTU pricing – pay per event, not per user, with a huge free tier - Experiments, feature flags, and more included - Full SQL access without a separate data warehouse - Also we have a data warehouse -- Mixpanel has no equivalent to PostHog Code +- Mixpanel has no equivalent to PostHog Desktop ## Objections @@ -97,11 +97,11 @@ Analytics is the memory of everything users have done. Self-driving development **Follow-up:** Which features specifically? Let's check what you actually use. -**Answer:** Some Amplitude-specific features are more mature — particularly advanced funnel modeling and data science integrations. But PostHog ships quickly and we can rapidly improve our open source product. We also offer a wide range of features beyond analytics, including replay, flags, error-tracking, and more - each of which can be queried with analytics. The total cost comparison almost always favors PostHog, and while Amplitude may have a handful of extra features it's unlikely they'll be ones you need. +**Answer:** Some Amplitude-specific features are more mature – particularly advanced funnel modeling and data science integrations. But PostHog ships quickly and we can rapidly improve our open source product. We also offer a wide range of features beyond analytics, including replay, flags, error-tracking, and more - each of which can be queried with analytics. The total cost comparison almost always favors PostHog, and while Amplitude may have a handful of extra features it's unlikely they'll be ones you need. ### "We need SQL access" -**Answer:** HogQL gives you full SQL on your event stream — joins, aggregations, window functions. Same interface, no separate warehouse needed. For more complex queries, PostHog's data warehouse unifies product events with Stripe, HubSpot, and other sources. +**Answer:** HogQL gives you full SQL on your event stream – joins, aggregations, window functions. Same interface, no separate warehouse needed. For more complex queries, PostHog's data warehouse unifies product events with Stripe, HubSpot, and other sources. ### "We're already on GA4" @@ -117,4 +117,4 @@ Analytics is the memory of everything users have done. Self-driving development Enterprise analytics customers get volume discounts, ~20% annual prepay, group analytics, SSO, advanced access controls, EU data residency, SOC 2, and HIPAA BAA. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules). -The enterprise pitch is consolidation: PostHog replaces analytics, session replay, feature flags, and experiments with one contract, one data model, and one platform that agents can query natively. That's four vendors consolidated, four renegotiations eliminated, and one platform that gets more capable as PostHog Code matures. +The enterprise pitch is consolidation: PostHog replaces analytics, session replay, feature flags, and experiments with one contract, one data model, and one platform that agents can query natively. That's four vendors consolidated, four renegotiations eliminated, and one platform that gets more capable as PostHog Desktop matures. diff --git a/contents/handbook/marketing/positioning/data-pipelines.md b/contents/handbook/marketing/positioning/data-pipelines.md index 966aabab5764..d6598cd590a2 100644 --- a/contents/handbook/marketing/positioning/data-pipelines.md +++ b/contents/handbook/marketing/positioning/data-pipelines.md @@ -4,7 +4,7 @@ sidebar: Handbook showTitle: true --- -> Data pipelines are part of the broader [context warehouse](/handbook/marketing/positioning/data-warehouse) — the platform that ingests and stores your context. This page covers the pipelines specifically. +> Data pipelines are part of the broader [context warehouse](/handbook/marketing/positioning/data-warehouse) – the platform that ingests and stores your context. This page covers the pipelines specifically. *For the canonical frame everyone at PostHog uses – the self-driving story and standard description – see [Brand foundations](/handbook/brand/foundations#how-we-describe-posthog).* @@ -12,13 +12,13 @@ showTitle: true PostHog's data pipelines move data into and out of PostHog without forcing you to buy a separate CDP, ETL tool, or reverse-ETL service. Sources are free, destinations and batch exports are usage-priced, transformations run on Hog functions inside the same platform that runs your analytics, replay, flags, experiments, warehouse, and agents. -That bundling is the pitch. Segment and Rudderstack only move data. PostHog moves it, lets you act on it, and feeds the agents that act on your behalf — typically 5–10x cheaper than Segment at equivalent volume. +That bundling is the pitch. Segment and Rudderstack only move data. PostHog moves it, lets you act on it, and feeds the agents that act on your behalf – typically 5–10x cheaper than Segment at equivalent volume. ## The unique belief (in terms of data pipelines) -PostHog is [a doing company](/blog/posthogs-next-chapter). Agents already create the majority of dashboards through PostHog AI and MCP. PostHog Code runs the [product autonomy loop](/blog/self-driving-product): signals in, work out, evaluation, repeat. +PostHog is [a doing company](/blog/posthogs-next-chapter). Agents already create the majority of dashboards through PostHog AI and MCP. PostHog Desktop runs the [product autonomy loop](/blog/self-driving-product): signals in, work out, evaluation, repeat. -That loop only closes if the agent can see the whole picture. Errors and replays don't tell you which customer to prioritize — revenue from Stripe, plan from HubSpot, tickets from Zendesk, spend from Google do. That data lives outside PostHog. So do some of the systems PostHog may need to push signals into. +That loop only closes if the agent can see the whole picture. Errors and replays don't tell you which customer to prioritize – revenue from Stripe, plan from HubSpot, tickets from Zendesk, spend from Google do. That data lives outside PostHog. So do some of the systems PostHog may need to push signals into. **Data pipelines are how PostHog becomes infrastructure for self-driving development.** Sources bring business context in. Destinations and batch exports push enriched signals back out. Without pipelines the autonomy loop is half-blind. Segment and Rudderstack just move data. PostHog moves it *and* runs the agents that act on it. @@ -33,9 +33,9 @@ That loop only closes if the agent can see the whole picture. Errors and replays ### Who this isn't for -- Teams that need 700+ destinations on day one — Segment wins on breadth. -- Mature data orgs with deep tracking-plan governance needs — Segment Protocols is more mature. -- Teams who only want a CDP and don't care about the rest of PostHog — the bundle is the whole point. +- Teams that need 700+ destinations on day one – Segment wins on breadth. +- Mature data orgs with deep tracking-plan governance needs – Segment Protocols is more mature. +- Teams who only want a CDP and don't care about the rest of PostHog – the bundle is the whole point. ## Messaging @@ -43,7 +43,7 @@ That loop only closes if the agent can see the whole picture. Errors and replays **Problem:** Agents that don't see revenue, plan tier, or support history can't prioritize. They see a stack trace, not the fact that the error hit your top customer. -**Solution:** Sources pull Stripe, HubSpot, Salesforce, Zendesk, and 40+ other systems into PostHog so every signal carries its business context — for your engineers and your agents. +**Solution:** Sources pull Stripe, HubSpot, Salesforce, Zendesk, and 40+ other systems into PostHog so every signal carries its business context – for your engineers and your agents. **Supporting features:** - 44 sources, free to import @@ -56,14 +56,14 @@ That loop only closes if the agent can see the whole picture. Errors and replays **Problem:** Segment + Mixpanel + LaunchDarkly + Fivetran + Hightouch + BI = six vendors, six bills, six renegotiations, and a data-engineering queue that grows every time someone wants a new destination. -**Solution:** PostHog covers the whole loop — analytics, replay, flags, experiments, warehouse, CDP, agents — in one platform. Destinations fan out from the same event stream. Product teams self-serve. +**Solution:** PostHog covers the whole loop – analytics, replay, flags, experiments, warehouse, CDP, agents – in one platform. Destinations fan out from the same event stream. Product teams self-serve. **Supporting features:** - 145+ integrations (44 sources, 41 real-time destinations, 7 batch-export targets) - Hog functions in JS or Hog - One SDK, one event schema - Contract buyouts when you commit annually -- Open source — build your own integration +- Open source – build your own integration ### Message 3: Predictable pricing, production-grade reliability @@ -74,18 +74,18 @@ That loop only closes if the agent can see the whole picture. Errors and replays **Supporting features:** - Sources free, generous usage tiers - Billing limits per product -- Temporal-backed exports — see [the engineering writeup](/blog/temporal-exports) +- Temporal-backed exports – see [the engineering writeup](/blog/temporal-exports) - We only ever lower prices ## Battle cards ### vs Segment (Twilio) -**Their approach:** The original CDP. 700+ destinations, mature identity resolution, Protocols for governance, Personas/Engage for audiences. MTU-based pricing — anonymous visitors count. +**Their approach:** The original CDP. 700+ destinations, mature identity resolution, Protocols for governance, Personas/Engage for audiences. MTU-based pricing – anonymous visitors count. **Where PostHog wins:** - Bundled with analytics, replay, flags, experiments, warehouse, agents -- Per-event pricing — no MTU surprises for B2C +- Per-event pricing – no MTU surprises for B2C - Sources are free - Pricing is published, not quote-locked @@ -96,7 +96,7 @@ That loop only closes if the agent can see the whole picture. Errors and replays **Where PostHog wins:** - Customer wants analytics, replay, flags, experiments in the same tool - Customer doesn't have a mature warehouse to anchor warehouse-first -- Customer cares about agent-readiness — MCP, PostHog AI, PostHog Code +- Customer cares about agent-readiness – MCP, PostHog AI, PostHog Desktop ### vs Fivetran @@ -116,7 +116,7 @@ That loop only closes if the agent can see the whole picture. Errors and replays **Answer:** Almost every customer uses fewer than 10. PostHog covers the common ones natively; Hog functions and webhooks cover anything with an HTTP API. The 700-vs-145 framing rarely survives a specific list. -### "We already use Segment / Rudderstack / Fivetran — why switch?" +### "We already use Segment / Rudderstack / Fivetran – why switch?" **Follow-up:** What are you paying today across CDP, analytics, flags, experiments, and ETL? How much engineering time goes into the pipeline? @@ -124,9 +124,9 @@ That loop only closes if the agent can see the whole picture. Errors and replays **Proof point:** [Rebtel](/customers/rebtel) migrated off mParticle + Snowflake + dbt with a phased plan. [Great Expectations](/customers/great-expectations) consolidated lead enrichment onto PostHog + Databricks. -### "Reliability — we've been burned by ETL before" +### "Reliability – we've been burned by ETL before" -**Follow-up:** What does reliable mean — at-least-once, exactly-once, replayability, observability? +**Follow-up:** What does reliable mean – at-least-once, exactly-once, replayability, observability? **Answer:** At-least-once with retries, exponential backoff, dead-letter queues, monitoring. The export system was rebuilt on Temporal in 2024 specifically to fix the duplicate-data and locking problems home-rolled ETL hits at scale. Our support team is engineers. @@ -134,8 +134,8 @@ That loop only closes if the agent can see the whole picture. Errors and replays ## Selling to enterprise -PostHog does enterprise the same way we do everything else. Pricing is published. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules) — volume, commitment, payment timing, forecast certainty — up to 40%+ off. No "let me talk to my manager" theatre. +PostHog does enterprise the same way we do everything else. Pricing is published. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules) – volume, commitment, payment timing, forecast certainty – up to 40%+ off. No "let me talk to my manager" theatre. Enterprise gets volume discounts on real-time and batch usage, ~20% annual prepay, custom DPA, BAA for HIPAA, EU residency, SOC 2, and dedicated support. **Contract buyout:** if a customer is locked into Segment / Rudderstack / Fivetran / mParticle and commits $20k+/year annually, we cover them for up to 6 months while the old contract runs out. -Enterprise does *not* get an APM-style sales motion, months-long POCs, or a CDP that operates outside our analytics platform. If a prospect needs any of those, the deal isn't a fit — say so early. +Enterprise does *not* get an APM-style sales motion, months-long POCs, or a CDP that operates outside our analytics platform. If a prospect needs any of those, the deal isn't a fit – say so early. diff --git a/contents/handbook/marketing/positioning/data-warehouse.md b/contents/handbook/marketing/positioning/data-warehouse.md index adb246cf3906..7d6407384212 100644 --- a/contents/handbook/marketing/positioning/data-warehouse.md +++ b/contents/handbook/marketing/positioning/data-warehouse.md @@ -4,44 +4,44 @@ sidebar: Handbook showTitle: true --- -> The context warehouse is the platform everything else in PostHog is built on, not a co-equal tool. It's the data warehouse plus the full context-ingestion pipeline — [data pipelines](/handbook/marketing/positioning/data-pipelines), modelling, and batch exports. Don't call this "the PostHog Data Stack" externally. +> The context warehouse is the platform everything else in PostHog is built on, not a co-equal tool. It's the data warehouse plus the full context-ingestion pipeline – [data pipelines](/handbook/marketing/positioning/data-pipelines), modelling, and batch exports. Don't call this "the PostHog Data Stack" externally. *For the canonical frame everyone at PostHog uses – the self-driving story and standard description – see [Brand foundations](/handbook/brand/foundations#how-we-describe-posthog).* ## Elevator pitch -The context warehouse brings your product events and business data — Stripe, HubSpot, Salesforce, Zendesk, and 40+ more — into one place, queryable together with SQL (and with PostHog AI to help you write it). Because it's part of PostHog, every piece of data is immediately available to your tools — analytics, experiments, feature flags — and to your agents. +The context warehouse brings your product events and business data – Stripe, HubSpot, Salesforce, Zendesk, and 40+ more – into one place, queryable together with SQL (and with PostHog AI to help you write it). Because it's part of PostHog, every piece of data is immediately available to your tools – analytics, experiments, feature flags – and to your agents. Snowflake stores data. The context warehouse stores data *and* acts on it. ## The unique belief (in terms of the context warehouse) -PostHog is building the platform for self-driving product development, and the context warehouse is the layer everything else is built on. The [product autonomy loop](/blog/self-driving-product) — signals in, work out, evaluation, repeat — only closes when agents can see the full picture. That means product events *and* business context: revenue, plan tier, support history, CRM data. +PostHog is building the platform for self-driving product development, and the context warehouse is the layer everything else is built on. The [product autonomy loop](/blog/self-driving-product) – signals in, work out, evaluation, repeat – only closes when agents can see the full picture. That means product events *and* business context: revenue, plan tier, support history, CRM data. -**The context warehouse is where that picture lives.** Every event PostHog captures, every Stripe charge, every HubSpot deal, every Zendesk ticket — it all lands in one place, queryable together. That unified store is what makes PostHog Code meaningful. Agents running the autonomy loop need context, and the context warehouse is the context layer. +**The context warehouse is where that picture lives.** Every event PostHog captures, every Stripe charge, every HubSpot deal, every Zendesk ticket – it all lands in one place, queryable together. That unified store is what makes PostHog Desktop meaningful. Agents running the autonomy loop need context, and the context warehouse is the context layer. Snowflake, BigQuery, and Databricks are powerful. They're also expensive, complex to operate, and don't connect to your product tools without significant glue, which usually has to be owned by a dedicated data team. The context warehouse is different: it's integrated, not bolted on. Your data never needs to leave the platform that acts on it. ## Who this is for -- **Startups who haven't built a data stack yet.** PostHog gets them to a complete, queryable data foundation in minutes, not months — and our [startup program](/startups) offers up to $50k in credits. +- **Startups who haven't built a data stack yet.** PostHog gets them to a complete, queryable data foundation in minutes, not months – and our [startup program](/startups) offers up to $50k in credits. - **Engineer-led teams tired of maintaining pipelines.** No ETL to babysit. Data flows in automatically from 40+ sources. - **Teams already using PostHog for analytics.** Adding the warehouse unifies product and business data in the place they already work. -- **Compliance-sensitive orgs.** EU residency, SOC 2, HIPAA-ready — data stays in PostHog. +- **Compliance-sensitive orgs.** EU residency, SOC 2, HIPAA-ready – data stays in PostHog. ### Who this isn't for -- Teams that need petabyte-scale with hundreds of concurrent analysts — Snowflake is the right answer. -- Data orgs with mature dbt pipelines and advanced modeling needs — we're not there yet. -- Teams who only want a warehouse and nothing else — the integrated platform is the point. +- Teams that need petabyte-scale with hundreds of concurrent analysts – Snowflake is the right answer. +- Data orgs with mature dbt pipelines and advanced modeling needs – we're not there yet. +- Teams who only want a warehouse and nothing else – the integrated platform is the point. ## Messaging ### Message 1: The warehouse is the context layer for your agents -**Problem:** Agents can see product signals — errors, funnel drops, slow sessions. But without business context, they're guessing. An agent can't prioritize the right customers without seeing revenue and plan data. +**Problem:** Agents can see product signals – errors, funnel drops, slow sessions. But without business context, they're guessing. An agent can't prioritize the right customers without seeing revenue and plan data. -**Solution:** PostHog's warehouse brings Stripe, HubSpot, Salesforce, and 40+ other sources alongside your product events. Every query, every insight, every agent prompt runs on the same unified dataset — no joins across systems, no pipelines to keep in sync. +**Solution:** PostHog's warehouse brings Stripe, HubSpot, Salesforce, and 40+ other sources alongside your product events. Every query, every insight, every agent prompt runs on the same unified dataset – no joins across systems, no pipelines to keep in sync. **Supporting features:** - 44+ sources including Stripe, HubSpot, Salesforce, Postgres, Snowflake, BigQuery, Databricks @@ -51,27 +51,27 @@ Snowflake, BigQuery, and Databricks are powerful. They're also expensive, comple ### Message 2: One platform replaces five -**Problem:** The typical data stack — Snowflake + Fivetran + dbt + Looker + product analytics — costs a lot. Six figures per year, easy. More if it requires a dedicated data team to maintain. +**Problem:** The typical data stack – Snowflake + Fivetran + dbt + Looker + product analytics – costs a lot. Six figures per year, easy. More if it requires a dedicated data team to maintain. **Solution:** PostHog collapses analytics, session replay, feature flags, experiments, CDP, and warehouse into one platform. Data flows automatically between tools. No pipelines. No hand-offs. Product teams self-serve. **Supporting features:** - Warehouse data available instantly in analytics, experiments, and feature flags -- 1M synced rows free per month, then $0.000015/row — no seat charges, tiered pricing as you grow +- 1M synced rows free per month, then $0.000015/row – no seat charges, tiered pricing as you grow - SQL editor, notebooks, and dashboards built in - PostHog AI for teams without a dedicated analyst ### Message 3: Modern data infrastructure for the AI era -**Problem:** Traditional data stacks were designed for batch processing and BI dashboards. AI-native product development needs something different — real-time signals, unified context, and data that agents can query directly. +**Problem:** Traditional data stacks were designed for batch processing and BI dashboards. AI-native product development needs something different – real-time signals, unified context, and data that agents can query directly. -**Solution:** PostHog's warehouse is the foundation for the [product autonomy loop](/blog/self-driving-product). Product signals and business data converge in one place, accessible to PostHog AI, MCP, and (soon) PostHog Code. That's infrastructure for how software gets built now — not a legacy stack with an AI label on it. +**Solution:** PostHog's warehouse is the foundation for the [product autonomy loop](/blog/self-driving-product). Product signals and business data converge in one place, accessible to PostHog AI, MCP, and (soon) PostHog Desktop. That's infrastructure for how software gets built now – not a legacy stack with an AI label on it. **Supporting features:** - Warehouse-backed MCP for agent context - PostHog AI to interrogate data in natural language -- Real-time event ingestion — no batch lag on the signals agents act on -- Open architecture — bring your own tools or use ours +- Real-time event ingestion – no batch lag on the signals agents act on +- Open architecture – bring your own tools or use ours ## Battle cards @@ -81,43 +81,43 @@ Snowflake, BigQuery, and Databricks are powerful. They're also expensive, comple **Where PostHog wins:** - No virtual warehouses, credits, or cluster management -- Analytics, experiments, and feature flags are built in — no integrations needed +- Analytics, experiments, and feature flags are built in – no integrations needed - Hours to first insight, not weeks -- Published, usage-based pricing — no surprise bills or "contact sales" for a number +- Published, usage-based pricing – no surprise bills or "contact sales" for a number ### vs Statsig / Amplitude / Mixpanel (warehouse-native) **Their approach:** Connect to your existing Snowflake or BigQuery and run queries there. You keep the warehouse; they run product tooling on top of it. **Where PostHog wins:** -- PostHog *is* the warehouse — no separate warehouse to buy or manage -- Session replay, feature flags, CDP, and agents are included — not add-ons +- PostHog *is* the warehouse – no separate warehouse to buy or manage +- Session replay, feature flags, CDP, and agents are included – not add-ons - If you already have Snowflake, sync what you need into PostHog instead of running another tool on top ## Objections -### "We already have Snowflake — why change?" +### "We already have Snowflake – why change?" **Follow-up:** What do you use for product analytics, feature flags, and experiments today? How do you connect those to Snowflake? -**Answer:** You have two paths. Use PostHog as your integrated warehouse and eliminate the maintenance burden entirely. Or keep Snowflake as your source of truth and sync the tables you need into PostHog via Warehouse Sources — your Snowflake data then becomes available in PostHog analytics, experiments, and agents without custom pipelines. Many teams do both and eventually consolidate. +**Answer:** You have two paths. Use PostHog as your integrated warehouse and eliminate the maintenance burden entirely. Or keep Snowflake as your source of truth and sync the tables you need into PostHog via Warehouse Sources – your Snowflake data then becomes available in PostHog analytics, experiments, and agents without custom pipelines. Many teams do both and eventually consolidate. ### "We need warehouse-native" -**Follow-up:** What's driving that requirement — performance, compliance, or avoiding data movement? +**Follow-up:** What's driving that requirement – performance, compliance, or avoiding data movement? -**Answer:** PostHog's warehouse is integrated into the platform, so data never needs to travel between tools. If you're already on Snowflake, sync what you need in via Warehouse Sources. If you're starting fresh, PostHog gives you the warehouse and every tool that runs on top of it. The outcome is the same: unified data, no data movement, integrated workflows — without paying for Snowflake on top. +**Answer:** PostHog's warehouse is integrated into the platform, so data never needs to travel between tools. If you're already on Snowflake, sync what you need in via Warehouse Sources. If you're starting fresh, PostHog gives you the warehouse and every tool that runs on top of it. The outcome is the same: unified data, no data movement, integrated workflows – without paying for Snowflake on top. ### "We'll outgrow PostHog at scale" **Follow-up:** What's your current data volume and query pattern? -**Answer:** PostHog handles the analytical workloads most product teams actually run. Where Snowflake genuinely wins — petabyte-scale governance, hundreds of concurrent analysts — we'll tell you directly. Most teams don't need that yet, and locking in that complexity early just adds cost and maintenance they don't need. When you get there, we'll help you make the right call. +**Answer:** PostHog handles the analytical workloads most product teams actually run. Where Snowflake genuinely wins – petabyte-scale governance, hundreds of concurrent analysts – we'll tell you directly. Most teams don't need that yet, and locking in that complexity early just adds cost and maintenance they don't need. When you get there, we'll help you make the right call. ## Selling to enterprise Enterprise data conversations at PostHog follow the same rules as everything else: pricing is published, terms are clear, and we don't oversell. -Enterprise warehouse customers get volume discounts on synced rows, ~20% annual prepay discount, EU data residency, SOC 2 certification, HIPAA BAA, custom DPA, and dedicated support. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules) — volume, commitment, payment timing, forecast certainty. +Enterprise warehouse customers get volume discounts on synced rows, ~20% annual prepay discount, EU data residency, SOC 2 certification, HIPAA BAA, custom DPA, and dedicated support. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules) – volume, commitment, payment timing, forecast certainty. The honest enterprise pitch: PostHog is not Snowflake, and we don't pretend otherwise. We win with teams who are tired of running five tools, want modern infrastructure for AI-native development, and value a vendor who prices transparently and ships fast. If a prospect needs petabyte-scale governance, mature dbt tooling, or has Snowflake contracts they can't exit, say so early. The right deals close faster when the fit is honest from the start. diff --git a/contents/handbook/marketing/positioning/desktop.md b/contents/handbook/marketing/positioning/desktop.md new file mode 100644 index 000000000000..d6740ef9ab3e --- /dev/null +++ b/contents/handbook/marketing/positioning/desktop.md @@ -0,0 +1,141 @@ +--- +title: PostHog Desktop +sidebar: Handbook +showTitle: true +--- + +*For the canonical frame everyone at PostHog uses – the self-driving story and standard description – see [Brand foundations](/handbook/brand/foundations#how-we-describe-posthog).* + +## Elevator pitch + +PostHog Desktop is a desktop app that runs coding agents on top of your product data. Real usage goes in, pull requests come out. It watches your errors, logs, and session recordings for problems worth fixing, turns them into tasks, and lets you run a fleet of agents against them in parallel – locally or in the cloud. + +Every other AI coding tool starts from the repo. PostHog Desktop starts from what your users are actually doing. The obvious fixes ship themselves behind a flag; the judgement calls show up as a prioritized to-do list for you to steer. + +Cursor edits your code. PostHog Desktop edits your product. + +## The unique belief (in terms of PostHog Desktop) + +A coding agent that only reads your codebase is working with half the picture. It knows what the code says. It has no idea that checkout is throwing 500s for Android users, that a rename broke a funnel last Tuesday, or that nobody makes it past step three of onboarding. That context lives in your product data, not your repo. + +PostHog Desktop is different because it's built on top of that data. Signals scan your errors, logs, and summarized recordings and surface the problems worth acting on. Tasks turn them into work. Agents do the work. And because PostHog also owns the analytics, flags, and experiments, it can close the [product autonomy loop](/blog/self-driving-product): ship the change behind a flag, measure whether it actually worked, and roll it back if it didn't. No other coding tool can do the last step, because no other coding tool has the data. + +**Other agents write code. PostHog Desktop builds your product.** + +## Who this is for + +It's not only for the people writing the code. The autonomy loop touches everyone who decides what to build and checks whether it worked – engineers, product, marketing, and the people steering the roadmap. + +| Persona | Fit | Why | +| --- | --- | --- | +| **Solo indie hacker** | Strong | One person owns the code, the data, and the decisions. A fleet of agents multiplies a team of one, and signals keep it pointed at what users actually hit. | +| **Professional software engineer** | Strong | Spend your time on the hard 20% while agents clear the obvious 80% – each fix wired to the data that says whether it worked. | +| **Startup engineering team** | Strong | More known problems than hands to fix them. Run agents in parallel and let Channels keep the team working together instead of in private chats. | +| **Product manager** | Strong | Turn signals into tasks, steer the agents on them, and read the impact yourself instead of waiting on an engineering ticket. | +| **Non-technical founder** | Good | Describe the product in plain English, let agents build it, and once you have users the production signals start driving the roadmap. | +| **Enterprise engineering team** | Good, with caveats | Usage-based pricing and flag-wrapped rollouts appeal, but governance is less mature than incumbents and it's still beta. See [selling to enterprise](#selling-to-enterprise). | +| **Product marketer** | Situational | Pull real product data and ship site or copy changes directly, without an engineer in the loop – useful, but not the core motion. | +| **Exec / leadership team** | Situational | Good for seeing what's shipping and what signals are surfacing, and for steering priorities – less so for hands-on building. | +| **Beginner learning to build apps** | Not yet | It'll happily build for you, but the production autonomy loop is wasted until you have real usage. A simpler coding tool fits better while you're learning. | + +Across all of these, the fit is sharpest for teams whose product data is already in PostHog – that's what turns a good coding agent into a self-driving product. + +### Who this isn't for + +- Teams who just want inline autocomplete in their existing editor. Copilot and Cursor are more mature at fast, in-flow suggestions, and that's a different job. +- Codebases with no PostHog data yet. Without signals, PostHog Desktop is a good coding agent but you're leaving its whole reason for existing on the table – start by instrumenting first. +- Organizations that need fully on-prem or air-gapped agent execution today. Cloud execution is the default; if the requirement is a hard no on external execution, we're not the fit yet. + +## Messaging + +### Message 1: The only agent that reads production, not just the repo + +**Problem:** Coding agents are only as good as their context, and most of them are blind to production. They can refactor a function beautifully while having no idea it's the one throwing errors for 4% of your users. You end up feeding them the context by hand – pasting stack traces, describing the bug, explaining what changed. + +**Solution:** PostHog Desktop's Signals watch your errors, logs, and session recordings and surface the problems worth fixing without being asked. Each one becomes a task an agent can pick up with the production context already attached. The agent isn't guessing what to work on – it's starting from what's actually breaking. + +**Supporting features:** +- Signals scan errors, logs, and summarized session recordings for problems worth acting on +- Tasks created automatically from signals, or from a prompt when you have your own idea +- Full PostHog data model available to the agent via MCP and PostHog AI +- Changes wrapped in a feature flag by default so a bad fix has a kill switch + +### Message 2: Run a fleet, not a chat + +**Problem:** Most agent tools are one conversation at a time. You prompt, you wait, you review, you prompt again. That's fine for a single task and useless for a backlog of fifty. The bottleneck stops being the code and starts being the number of chats you can babysit. + +**Solution:** The Command Center runs up to nine agents in parallel, each on its own task, cloud or local. You steer the ones that need judgement and let the rest run – including overnight. Channels give the whole thing a multiplayer surface, so your team works alongside the agents instead of each person driving a private chat. + +**Supporting features:** +- Command Center runs up to nine agents at once, each on a separate task +- Cloud execution by default; local execution when you want it +- Channels: a shared, multiplayer workspace where agent sessions live and context accumulates +- Human review before anything ships – agents work autonomously, you keep the final call + +### Message 3: One subscription, every model, wired to your data + +**Problem:** The agent tooling stack fragments fast. A Claude Code subscription here, a Cursor seat there, an analytics tool that doesn't talk to any of them. You're paying three vendors and stitching the context together yourself. + +**Solution:** PostHog Desktop gives you the latest models – Claude, Codex, open source – without a separate subscription to any of them, at usage-based pricing that lands around what you'd pay anyway. And because it's PostHog, the agent can query your analytics, read your flags, and check whether a change worked, all from the same place you already keep your data. + +**Supporting features:** +- Access to the latest Claude, Codex, and open-source models with no separate provider subscription +- Usage-based pricing – pay for what the agents actually do +- PostHog AI and MCP give agents a native query interface to your product data +- Flags, experiments, analytics, and replay all in the same platform the agent ships into + +## Battle cards + +### vs Claude Code / Codex + +**Their approach:** Excellent terminal-based coding agents. They read your repo, run commands, and write good code. Context stops at the codebase – they don't know your production data, and they can't measure whether a change worked. Each is a separate subscription. + +**Where PostHog wins:** +- Production context: Signals surface what to fix from real usage, not just the repo +- Closes the loop – ships behind a flag, then measures impact in the same platform +- Run up to nine agents in parallel from the Command Center, not one session at a time +- No separate model subscription; usage-based pricing across Claude, Codex, and open source +- Still uses the same underlying models, so you're not trading away code quality to get all of this + +### vs Devin + +**Their approach:** An autonomous cloud software engineer, closest to the "ships while you sleep" pitch. Strong at taking a task and running with it end to end. Its autonomy is scoped to the codebase and the task you hand it. + +**Where PostHog wins:** +- The tasks come from production signals, not just from what you think to ask for +- Impact measurement is built in – PostHog owns the analytics that tell you if it worked +- Multiplayer Channels and a nine-agent Command Center, not a single autonomous worker +- Feature-flag-wrapped rollouts give autonomous changes a native safety net + +### vs the agentic multiplayer-workspace challengers (Buzz, Capy, PromptQL, Dust) + +This is a new and fast-moving category, so keep the comparison honest and current – check what each one actually ships before leaning on specifics. + +**Their approach:** A growing set of tools putting agents into a shared, multiplayer workspace, several of them layered on top of your existing data or tools. + +**Where PostHog wins:** +- We own the whole stack the agents act on – data, analytics, flags, experiments, replay – rather than bolting an agent onto someone else's data +- The autonomy loop only closes when the same platform can both ship the change and measure it; that's structurally hard to replicate from a workspace layer alone +- Everything runs against real product data you already have in PostHog + +## Objections + +### "We already use Cursor / Claude Code and the team likes it" + +**Follow-up:** Where does that agent get its context today – just the repo, or does it know what's happening in production? + +**Answer:** Keep using them for in-flow coding if the team likes them; PostHog Desktop runs the same underlying models, so it's not a downgrade on code quality. The difference is where the work comes from and what happens after. PostHog Desktop starts from production signals and measures impact after shipping – the parts a repo-only agent can't do. Plenty of teams run both. + +### "It's still in beta" + +**Answer:** It is, and we're honest about that – some features are early and it's improving weekly. It's the tool we use to build PostHog itself, which is the same bar we hold every product to before we ship it. If you need a locked-down, GA-only tool for a regulated production process today, wait. If you want to shape a category-defining product and get the autonomy loop working before your competitors do, now is the time. + +### "We don't want agents shipping to production autonomously" + +**Answer:** Neither do we, and PostHog Desktop is built that way. Agents do the work autonomously, but a human reviews and approves before anything ships. Changes are wrapped in a feature flag by default, so even an approved change rolls out gradually with a kill switch – and the analytics tell you whether to keep going. Autonomy is on the work, not on the deploy button. + +## Selling to enterprise + +PostHog Desktop is usage-based – you pay for what the agents do, with no per-seat model subscription to stack on top. That maps cleanly onto how larger teams want to budget agent spend, and it scales with usage rather than headcount. + +Enterprise customers get SSO, EU data residency, SOC 2, and dedicated support, with contracts following [the four-lever framework](/handbook/growth/sales/contract-rules). The forward-looking pitch is simple: the autonomy loop only works for teams whose product data is already in PostHog. The teams instrumenting analytics, flags, and replay today are the ones who will have a working self-driving product tomorrow – and the gap widens every month they wait. diff --git a/contents/handbook/marketing/positioning/endpoints.md b/contents/handbook/marketing/positioning/endpoints.md index 5d57546c39a1..e851814d95bd 100644 --- a/contents/handbook/marketing/positioning/endpoints.md +++ b/contents/handbook/marketing/positioning/endpoints.md @@ -24,7 +24,7 @@ Tinybird and custom-built analytics APIs solve the same surface problem. They do ## Who this is for -* Existing customers already using two or more of these — Product Analytics, SQL/Logs, Dashboards, Surveys +* Existing customers already using two or more of these – Product Analytics, SQL/Logs, Dashboards, Surveys * If you've heard a customer say any of the following, you should pitch them Endpoints: * "We're exporting CSVs and pasting numbers into a slide every Monday." * “We want to show our customers their own usage data inside our product." @@ -124,6 +124,6 @@ Tinybird and custom-built analytics APIs solve the same surface problem. They do Enterprise Endpoints conversations follow the same rules as the rest of PostHog: pricing is published, terms are clear, and we don't oversell. -The enterprise pitch is the data egress story. Large organizations often have PostHog deployed across multiple teams and use cases, but data still escapes via manual exports and one-off scripts. Endpoints replaces that pattern with something versioned, auditable, and self-serve — without requiring a data engineering queue. +The enterprise pitch is the data egress story. Large organizations often have PostHog deployed across multiple teams and use cases, but data still escapes via manual exports and one-off scripts. Endpoints replaces that pattern with something versioned, auditable, and self-serve – without requiring a data engineering queue. The honest pitch: Endpoints wins when the data is already in PostHog and the team is tired of the work required to get it anywhere else. If a prospect's data isn't in PostHog, the right conversation is data pipelines and the data warehouse first. \ No newline at end of file diff --git a/contents/handbook/marketing/positioning/experiments.md b/contents/handbook/marketing/positioning/experiments.md index 98182f2e88b9..94bb5bf2421b 100644 --- a/contents/handbook/marketing/positioning/experiments.md +++ b/contents/handbook/marketing/positioning/experiments.md @@ -8,9 +8,9 @@ showTitle: true ## Elevator pitch -PostHog Experiments run on top of Feature Flags, so every experiment is a controlled rollout by default. Multiple metric types — funnels, trends, retention, ratio metrics — let you measure what actually matters, not just what's easy to track. Watch session replays of each variant's users. Measure side effects across your entire product. +PostHog Experiments run on top of Feature Flags, so every experiment is a controlled rollout by default. Multiple metric types – funnels, trends, retention, ratio metrics – let you measure what actually matters, not just what's easy to track. Watch session replays of each variant's users. Measure side effects across your entire product. -For self-driving development, this means enabling PostHog Code to create experiments and re-query the results automatically - making experiments the evaluation layer for agents. +For self-driving development, this means enabling PostHog Desktop to create experiments and re-query the results automatically - making experiments the evaluation layer for agents. Most experiment platforms run tests. PostHog runs tests *and* closes the loop from signal to fix to evaluation. @@ -20,7 +20,7 @@ In traditional product development, an A/B test is the last step before shipping That’s the PostHog-shaped belief: autonomous coding only becomes trustworthy when the agent can measure whether its own work improved the product. -**Experiments are how the autonomy loop knows whether it's working.** Without experiments, agents can ship changes indefinitely without knowing if anything improved. Experiments are the feedback signal that makes self-driving product development trustworthy — not just fast. +**Experiments are how the autonomy loop knows whether it's working.** Without experiments, agents can ship changes indefinitely without knowing if anything improved. Experiments are the feedback signal that makes self-driving product development trustworthy – not just fast. ## Who this is for @@ -33,19 +33,19 @@ That’s the PostHog-shaped belief: autonomous coding only becomes trustworthy w ### Who this isn't for -- Teams who need no-code visual editors for landing page and CRO tests — Optimizely Web or VWO handle that better. +- Teams who need no-code visual editors for landing page and CRO tests – Optimizely Web or VWO handle that better. - Marketing teams running experiments outside the product (ad creative, email subject lines, landing pages). ## Messaging ### Message 1: Experiments as the evaluation layer for agents -**Problem:** An agent that ships code without measuring impact isn't self-driving — it's just automated code generation. The autonomy loop requires a closed feedback cycle: change made → outcome measured → agent learns. Experiments are part of that. +**Problem:** An agent that ships code without measuring impact isn't self-driving – it's just automated code generation. The autonomy loop requires a closed feedback cycle: change made → outcome measured → agent learns. Experiments are part of that. -**Solution:** PostHog Code can scaffold experiments end-to-end. The same metric that triggered the fix signal is used as the experiment goal. Post-merge, PostHog Code re-queries the result and evaluates whether the change worked — without human intervention. +**Solution:** PostHog Desktop can scaffold experiments end-to-end. The same metric that triggered the fix signal is used as the experiment goal. Post-merge, PostHog Desktop re-queries the result and evaluates whether the change worked – without human intervention. **Supporting features:** -- PostHog Code skills for full experiment lifecycle management +- PostHog Desktop skills for full experiment lifecycle management - MCP exposes experiment results to agent runtimes for automated evaluation - Experiment results queryable alongside all PostHog data via HogQL - Automatic re-evaluation after defined exposure periods @@ -54,11 +54,11 @@ That’s the PostHog-shaped belief: autonomous coding only becomes trustworthy w **Problem:** Running an experiment can require a flag in LaunchDarkly, analytics in Amplitude, and a session tool in FullStory. Alternatively, you rely on a dedicated tool like Optimizely or VWO with a more limited feature set. -**Solution:** PostHog Experiments are built on Feature Flags. Every experiment starts as a flag variant. Every result is visible in PostHog Analytics. Every variant's sessions are watchable in PostHog Replay. Everything is in one place, with one data model - and all available to the PostHog MCP and PostHog Code to facilitate agentic workflows. +**Solution:** PostHog Experiments are built on Feature Flags. Every experiment starts as a flag variant. Every result is visible in PostHog Analytics. Every variant's sessions are watchable in PostHog Replay. Everything is in one place, with one data model - and all available to the PostHog MCP and PostHog Desktop to facilitate agentic workflows. **Supporting features:** - Experiments and flags share the same 1M/month free tier -- Multi-metric experiments — measure primary goal plus secondary effects +- Multi-metric experiments – measure primary goal plus secondary effects - Minimum detectable effect calculator and sample size guidance - Group analytics: measure experiment impact at the account level @@ -82,8 +82,8 @@ That’s the PostHog-shaped belief: autonomous coding only becomes trustworthy w **Where PostHog wins:** - Usage-based pricing vs Optimizely's enterprise contracts -- Native session replay per variant — Optimizely has no equivalent -- PostHog Code evaluation loop — Optimizely has no agent integration +- Native session replay per variant – Optimizely has no equivalent +- PostHog Desktop evaluation loop – Optimizely has no agent integration - Better fit for product engineering experiments vs marketing CRO ## Objections @@ -94,10 +94,10 @@ That’s the PostHog-shaped belief: autonomous coding only becomes trustworthy w ### "We already use LaunchDarkly flags for experiments" -**Answer:** PostHog's experiments use the same flag infrastructure you'd use with LaunchDarkly — but with analytics and session replay built in. You don't have to migrate your flags to start running experiments. Connect PostHog to your event stream, define a goal metric, and you can measure the impact of existing LaunchDarkly flags in PostHog today. +**Answer:** PostHog's experiments use the same flag infrastructure you'd use with LaunchDarkly – but with analytics and session replay built in. You don't have to migrate your flags to start running experiments. Connect PostHog to your event stream, define a goal metric, and you can measure the impact of existing LaunchDarkly flags in PostHog today. ## Selling to enterprise Enterprise experimentation customers get volume discounts, group analytics for account-level experiment analysis, SSO, access controls, EU data residency, and SOC 2. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules). -The consolidation pitch is strong: Optimizely or VWO contracts at enterprise are often $50k+/year for a tool that only runs tests. PostHog covers experiments, analytics, session replay, feature flags, and error tracking for a comparable or lower total spend — and adds the agent evaluation loop that no pure experimentation vendor offers. +The consolidation pitch is strong: Optimizely or VWO contracts at enterprise are often $50k+/year for a tool that only runs tests. PostHog covers experiments, analytics, session replay, feature flags, and error tracking for a comparable or lower total spend – and adds the agent evaluation loop that no pure experimentation vendor offers. diff --git a/contents/handbook/marketing/positioning/feature-flags.md b/contents/handbook/marketing/positioning/feature-flags.md index f87243586458..ab62e04dd342 100644 --- a/contents/handbook/marketing/positioning/feature-flags.md +++ b/contents/handbook/marketing/positioning/feature-flags.md @@ -8,13 +8,13 @@ showTitle: true ## Elevator pitch -PostHog Feature Flags support boolean flags, multivariate variants, JSON payloads for config changes without deploys, and local evaluation for <50ms latency. Every flag is queryable alongside your analytics and session replay — filter any insight by which flag variant a user saw. And every flag PostHog Code ships is automatically wired into the analytics that measures whether it worked. +PostHog Feature Flags support boolean flags, multivariate variants, JSON payloads for config changes without deploys, and local evaluation for <50ms latency. Every flag is queryable alongside your analytics and session replay – filter any insight by which flag variant a user saw. And every flag PostHog Desktop ships is automatically wired into the analytics that measures whether it worked. LaunchDarkly manages flags. PostHog manages flags *and* shows you the impact of every rollout. ## The unique belief (in terms of feature flags) -Feature flags started as deployment safety nets — a way to ship code slowly without exposing too much to users. In the [product autonomy loop](/blog/self-driving-product), they're the mechanism through which agents ship code safely. PostHog Code's `instrument-feature-flags` skill wraps relevant changes it opens in a flag by default. The enricher shows stale flags inline in your editor. When an agent ships a fix, the flag is the rollout control. +Feature flags started as deployment safety nets – a way to ship code slowly without exposing too much to users. In the [product autonomy loop](/blog/self-driving-product), they're the mechanism through which agents ship code safely. PostHog Desktop's `instrument-feature-flags` skill wraps relevant changes it opens in a flag by default. The enricher shows stale flags inline in your editor. When an agent ships a fix, the flag is the rollout control. **Flags aren't just for humans anymore. They're the guardrails that let agents work autonomously and safely.** @@ -30,9 +30,9 @@ Without flags, agents can't ship incrementally. Without incremental shipping, ag ### Who this isn't for -- Enterprises with complex governance requirements — multi-stage approvals, change management workflows, compliance-grade audit trails — LaunchDarkly Enterprise is more mature here. +- Enterprises with complex governance requirements – multi-stage approvals, change management workflows, compliance-grade audit trails – LaunchDarkly Enterprise is more mature here. - Marketing teams who need non-technical flag management with visual editors and no-code targeting. -- Teams who need experimentation without product analytics — Optimizely or VWO handle that use case more simply. +- Teams who need experimentation without product analytics – Optimizely or VWO handle that use case more simply. ## Messaging @@ -40,10 +40,10 @@ Without flags, agents can't ship incrementally. Without incremental shipping, ag **Problem:** Coding agents that ship without feature flags are unsafe. A bad change rolls out to 100% of users with no kill switch. Evaluating whether the change worked requires manually querying separate analytics. -**Solution:** PostHog Code can add flags automatically to every PR it opens. The enricher detects existing flags in your codebase and shows rollout percentage, staleness status, and flag evaluation inline — without leaving your editor. Close the loop: agent ships with flag → analytics measures impact → agent evaluates → agent removes stale flag. +**Solution:** PostHog Desktop can add flags automatically to every PR it opens. The enricher detects existing flags in your codebase and shows rollout percentage, staleness status, and flag evaluation inline – without leaving your editor. Close the loop: agent ships with flag → analytics measures impact → agent evaluates → agent removes stale flag. **Supporting features:** -- PostHog Code `instrument-feature-flags` skill: adds flags to PRs automatically +- PostHog Desktop `instrument-feature-flags` skill: adds flags to PRs automatically - Enricher: detects `isFeatureEnabled` calls and shows live rollout data inline - Stale flag detection built into the enricher - MCP exposes flag state to any connected agent runtime @@ -56,15 +56,15 @@ Without flags, agents can't ship incrementally. Without incremental shipping, ag **Supporting features:** - 1M flag evaluations/month free forever -- No seat limits — every engineer, every service, every agent gets full access -- Same billing model as the rest of PostHog — pay for what you use +- No seat limits – every engineer, every service, every agent gets full access +- Same billing model as the rest of PostHog – pay for what you use - Pricing published publicly, no "contact sales" for a number ### Message 3: From flag to experiment in one step **Problem:** Flags and experiments are managed in separate tools. You gate a feature with LaunchDarkly, then measure it in Amplitude, then run the A/B test in Optimizely. Three tools, three integrations, three contracts, three data models that don't talk to each other. -**Solution:** PostHog Experiments are built on top of Feature Flags. Every experiment starts as a flag. Every flag can become an experiment. The same evaluation infrastructure serves both — both connect to the same analytics and session replay data, and both end up available to the MCP and PostHog Code. +**Solution:** PostHog Experiments are built on top of Feature Flags. Every experiment starts as a flag. Every flag can become an experiment. The same evaluation infrastructure serves both – both connect to the same analytics and session replay data, and both end up available to the MCP and PostHog Desktop. **Supporting features:** - Experiments and flags share the same 1M/month free tier @@ -79,9 +79,9 @@ Without flags, agents can't ship incrementally. Without incremental shipping, ag **Their approach:** Strong governance, mature SDKs, deep integrations (GitHub, Jira, PagerDuty, DataDog). Per-developer seat pricing. **Where PostHog wins:** -- No per-developer pricing — typically 80-90% cheaper for equal team sizes -- Native analytics and session replay — LaunchDarkly requires separate tools for impact measurement -- PostHog Code integration — LaunchDarkly has no agent loop equivalent +- No per-developer pricing – typically 80-90% cheaper for equal team sizes +- Native analytics and session replay – LaunchDarkly requires separate tools for impact measurement +- PostHog Desktop integration – LaunchDarkly has no agent loop equivalent - Sources are free in PostHog; every PostHog tool shares the same event stream ### vs GrowthBook @@ -89,16 +89,16 @@ Without flags, agents can't ship incrementally. Without incremental shipping, ag **Their approach:** Open source feature flags and A/B testing. Self-hostable. Requires your own data infrastructure for analytics. **Where PostHog wins:** -- Fully managed — no infrastructure to run (this is better, trust us) +- Fully managed – no infrastructure to run (this is better, trust us) - Replay, analytics, error tracking included -- PostHog Code integration +- PostHog Desktop integration - Still open source (MIT) ## Objections ### "LaunchDarkly has better governance" -**Follow-up:** What specific governance features are you using today — approval workflows, change requests, audit logs? +**Follow-up:** What specific governance features are you using today – approval workflows, change requests, audit logs? **Answer:** LaunchDarkly Enterprise's governance is more mature. PostHog has flag history, audit trails, and access controls that satisfy most teams. If the requirement comes from a compliance checklist rather than active daily use, it's worth checking whether those features are actually being used or just required on paper. The cost delta between PostHog and LaunchDarkly is typically large enough to justify a closer look. @@ -106,12 +106,12 @@ Without flags, agents can't ship incrementally. Without incremental shipping, ag **Answer:** PostHog supports local evaluation natively. Flags evaluate in under 50ms without a network call. SDK downloads the full ruleset on init; evaluation is in-process. -### "We're already using flags in our codebase — migration is painful" +### "We're already using flags in our codebase – migration is painful" -**Answer:** PostHog Code's enricher detects existing `isFeatureEnabled` patterns in your codebase and surfaces flag data inline. You don't need to migrate on day one. Start by connecting PostHog analytics to measure flag impact, then migrate flags incrementally as they come up for review. The enricher makes the transition visible without forcing a flag-by-flag rewrite. +**Answer:** PostHog Desktop's enricher detects existing `isFeatureEnabled` patterns in your codebase and surfaces flag data inline. You don't need to migrate on day one. Start by connecting PostHog analytics to measure flag impact, then migrate flags incrementally as they come up for review. The enricher makes the transition visible without forcing a flag-by-flag rewrite. ## Selling to enterprise Enterprise flag customers get volume discounts, SSO, advanced access controls, audit logging, EU data residency, SOC 2, and dedicated support. Contracts follow [the four-lever framework](/handbook/growth/sales/contract-rules). -The LaunchDarkly displacement motion is strong at contract renewal time. LaunchDarkly's per-seat pricing means costs balloon as engineering teams grow. Present the total cost comparison — seat pricing vs PostHog usage-based — before the renewal window opens. Contract buyout available for customers locked into LaunchDarkly with $20k+/year annual PostHog commitment. +The LaunchDarkly displacement motion is strong at contract renewal time. LaunchDarkly's per-seat pricing means costs balloon as engineering teams grow. Present the total cost comparison – seat pricing vs PostHog usage-based – before the renewal window opens. Contract buyout available for customers locked into LaunchDarkly with $20k+/year annual PostHog commitment. diff --git a/contents/handbook/marketing/positioning/index.md b/contents/handbook/marketing/positioning/index.md index 5be1281d0b6e..229f56d86fdf 100644 --- a/contents/handbook/marketing/positioning/index.md +++ b/contents/handbook/marketing/positioning/index.md @@ -16,7 +16,7 @@ We've repositioned around self-driving. That only works if we all use the same w ### Use these words -- **"Products"** for Web / Slack / MCP / CLI / Code (and Mobile in future) +- **"Products"** for Web / Slack / MCP / CLI / Desktop (and Mobile in future) - **"Tools"** for analytics / replay / flags / error tracking, etc. - **"Context"** for events / recordings / logs / business data, etc. - **"Context warehouse"** for the data warehouse plus ingestion pipeline @@ -41,25 +41,26 @@ We've repositioned around self-driving. That only works if we all use the same w A reference index to the per-tool pages. Each follows the same shape – unique belief, who it's for, elevator pitch and three messages, battle cards, common objections, and selling to enterprise – so you can scan them quickly. Pull from them freely, but they work best when remixed and pressure-tested in real conversations, not framed on a wall and cited religiously. -- [**Analytics**](/handbook/marketing/positioning/analytics) — Product analytics built for engineers, not dashboard tourists -- [**Session replay**](/handbook/marketing/positioning/session-replay) — Watching real users beats imagining them -- [**Feature flags**](/handbook/marketing/positioning/feature-flags) — Shipping switches that don't require a separate vendor -- [**Experiments**](/handbook/marketing/positioning/experiments) — A/B testing wired to the same data as everything else -- [**Data pipelines**](/handbook/marketing/positioning/data-pipelines) — CDP, reverse-ETL, and transformations bundled — typically 5–10x cheaper than Segment -- [**Endpoints**](/handbook/marketing/positioning/endpoints) — Turn any saved insight or SQL query into a stable, authenticated HTTP endpoint -- [**LLM analytics**](/handbook/marketing/positioning/llm-analytics) — Knowing why your LLM-powered feature is bleeding money or shipping nonsense -- [**PostHog AI**](/handbook/marketing/positioning/posthog-ai) — A query interface that already knows your schema (and your users) +- [**Analytics**](/handbook/marketing/positioning/analytics) – Product analytics built for engineers, not dashboard tourists +- [**Session replay**](/handbook/marketing/positioning/session-replay) – Watching real users beats imagining them +- [**Feature flags**](/handbook/marketing/positioning/feature-flags) – Shipping switches that don't require a separate vendor +- [**Experiments**](/handbook/marketing/positioning/experiments) – A/B testing wired to the same data as everything else +- [**Data pipelines**](/handbook/marketing/positioning/data-pipelines) – CDP, reverse-ETL, and transformations bundled – typically 5–10x cheaper than Segment +- [**Endpoints**](/handbook/marketing/positioning/endpoints) – Turn any saved insight or SQL query into a stable, authenticated HTTP endpoint +- [**LLM analytics**](/handbook/marketing/positioning/llm-analytics) – Knowing why your LLM-powered feature is bleeding money or shipping nonsense +- [**PostHog AI**](/handbook/marketing/positioning/posthog-ai) – A query interface that already knows your schema (and your users) +- [**PostHog Desktop**](/handbook/marketing/positioning/desktop) – A desktop app that runs a fleet of coding agents on top of your product data The **context warehouse** has its own page too, but treat it as the platform everything above is built on – the data warehouse plus modelling, pipelines, and exports – not as a co-equal tool in this list: -- [**Context warehouse**](/handbook/marketing/positioning/data-warehouse) — The context layer for your agents, not just a SQL bucket +- [**Context warehouse**](/handbook/marketing/positioning/data-warehouse) – The context layer for your agents, not just a SQL bucket ## What this isn't - **Not a feature list.** That's what [the docs](/docs) are for. - **Not static.** Tools evolve, pricing changes, and competitors ship things. Treat every page as the current best version, not the final one. -If something here feels off, doesn't match what the product team is actually building, or contradicts itself across pages — open a PR or flag it in #team-marketing. +If something here feels off, doesn't match what the product team is actually building, or contradicts itself across pages – open a PR or flag it in #team-marketing. ## How we name and position things diff --git a/contents/handbook/marketing/positioning/llm-analytics.md b/contents/handbook/marketing/positioning/llm-analytics.md index 4222c58e7501..e6a33ed2b7e5 100644 --- a/contents/handbook/marketing/positioning/llm-analytics.md +++ b/contents/handbook/marketing/positioning/llm-analytics.md @@ -8,29 +8,29 @@ showTitle: true ## Elevator pitch -PostHog LLM Analytics tracks every model call — latency, tokens, cost per user, quality signals, errors — alongside the product events and session data from the humans using your AI features. When something goes wrong, you can trace it back to the exact conversation, the exact prompt, and the exact user cohort affected. And because it's PostHog, PostHog Code can read those traces and propose fixes — automatically. +PostHog LLM Analytics tracks every model call – latency, tokens, cost per user, quality signals, errors – alongside the product events and session data from the humans using your AI features. When something goes wrong, you can trace it back to the exact conversation, the exact prompt, and the exact user cohort affected. And because it's PostHog, PostHog Desktop can read those traces and propose fixes – automatically. -Langfuse shows you the trace. PostHog shows you the trace *and* what it cost you in user retention **and** makes that information queryable to PostHog Code, the self-driving development platform. +Langfuse shows you the trace. PostHog shows you the trace *and* what it cost you in user retention **and** makes that information queryable to PostHog Desktop, the self-driving development platform. ## The unique belief (in terms of LLM analytics) -Every team building an AI-native product is running two products simultaneously: the product users see, and the AI layer underneath it. That AI layer has its own failure modes — bad prompts, cost explosions, latency spikes, quality regressions — and none of those show up in standard product analytics. That's where LLM analytics comes in! +Every team building an AI-native product is running two products simultaneously: the product users see, and the AI layer underneath it. That AI layer has its own failure modes – bad prompts, cost explosions, latency spikes, quality regressions – and none of those show up in standard product analytics. That's where LLM analytics comes in! -PostHog Code already uses LLM traces optimize AI features as part of the [product autonomy loop](/blog/self-driving-product). Its built-in `exploring-llm-traces` and `exploring-llm-clusters` skills let agents find patterns in model calls and propose prompt improvements. But that only works if the traces exist. **LLM Analytics is the signal layer that makes AI products self-improving.** +PostHog Desktop already uses LLM traces optimize AI features as part of the [product autonomy loop](/blog/self-driving-product). Its built-in `exploring-llm-traces` and `exploring-llm-clusters` skills let agents find patterns in model calls and propose prompt improvements. But that only works if the traces exist. **LLM Analytics is the signal layer that makes AI products self-improving.** If you're building AI features without LLM observability, your agents are flying blind. ## Who this is for -- **Teams building AI-native products** — chatbots, copilots, agents, AI-assisted features — who need to understand model performance. -- **Engineers debugging why AI features underperform** — wrong answers, high latency, unexpected costs. +- **Teams building AI-native products** – chatbots, copilots, agents, AI-assisted features – who need to understand model performance. +- **Engineers debugging why AI features underperform** – wrong answers, high latency, unexpected costs. - **Product teams who want to correlate LLM quality with user retention and conversion.** -- **Teams who want LLM observability in the same place as product analytics** — not in a separate tool. +- **Teams who want LLM observability in the same place as product analytics** – not in a separate tool. ### Who this isn't for -- Data science teams who need model training infrastructure, fine-tuning pipelines, or MLOps — that's not PostHog. Yet. -- Teams who only care about billing/token costs — those tools exist, but PostHog adds user context that pure cost monitors don't. +- Data science teams who need model training infrastructure, fine-tuning pipelines, or MLOps – that's not PostHog. Yet. +- Teams who only care about billing/token costs – those tools exist, but PostHog adds user context that pure cost monitors don't. - Enterprises with deeply embedded observability platforms (Datadog) where adding another tool isn't worth the friction. ## Messaging @@ -39,19 +39,19 @@ If you're building AI features without LLM observability, your agents are flying **Problem:** An LLM trace tells you a model call failed. It doesn't tell you whether that failure caused the user to churn, downgrade, or file a support ticket. Without that connection, you can't prioritize what to fix. -**Solution:** PostHog links every LLM span to the user's full session — their history, their plan tier, their previous behavior. A 3% quality degradation in your AI assistant looks very different when you can see it's impacting your highest-value accounts. +**Solution:** PostHog links every LLM span to the user's full session – their history, their plan tier, their previous behavior. A 3% quality degradation in your AI assistant looks very different when you can see it's impacting your highest-value accounts. **Supporting features:** - LLM span tracking linked to PostHog person profiles - Cost-per-user and cost-per-feature analysis - Cluster analysis to find patterns across conversations -- PostHog Code's `exploring-llm-traces` skill triggers automated investigation on quality regressions +- PostHog Desktop's `exploring-llm-traces` skill triggers automated investigation on quality regressions ### Message 2: Cost visibility with user context **Problem:** Token cost monitors tell you what you spent. They don't tell you whether you spent it on users who converted or users who churned. -**Solution:** PostHog shows LLM costs alongside product metrics — retention, conversion, NPS responses — so you can make informed decisions about which model to run, which features to optimize, and where cost reduction would hurt versus help. +**Solution:** PostHog shows LLM costs alongside product metrics – retention, conversion, NPS responses – so you can make informed decisions about which model to run, which features to optimize, and where cost reduction would hurt versus help. **Supporting features:** - Cost trends by model, feature, and user cohort @@ -63,12 +63,12 @@ If you're building AI features without LLM observability, your agents are flying **Problem:** LLM observability tools were built by infrastructure teams. They're excellent at tracing model calls. They don't understand that the user behind the call is a churned customer, a free trial, or your top enterprise account. -**Solution:** PostHog's LLM Analytics sits inside a product platform with full user profiles, cohorts, and behavioral history. Every trace has a person behind it. That context is what makes the data actionable — and what makes PostHog Code's agent research meaningful rather than mechanical. +**Solution:** PostHog's LLM Analytics sits inside a product platform with full user profiles, cohorts, and behavioral history. Every trace has a person behind it. That context is what makes the data actionable – and what makes PostHog Desktop's agent research meaningful rather than mechanical. **Supporting features:** - Supports OpenAI, Anthropic, Google Gemini, and major LLM providers -- Session replay correlation — watch the session where the AI feature failed -- Feature flag integration — A/B test prompt variations formally +- Session replay correlation – watch the session where the AI feature failed +- Feature flag integration – A/B test prompt variations formally - Unified dashboard with product analytics ## Battle cards @@ -78,10 +78,10 @@ If you're building AI features without LLM observability, your agents are flying **Their approach:** Open source LLM observability. Excellent trace visualization, evaluation pipelines, prompt management. No product analytics, no session context, no agent loop integration. **Where PostHog wins:** -- User context — traces linked to person profiles and behavioral history -- PostHog Code integration — traces become inputs to the autonomy loop -- Session replay correlation — watch what users did before and after an LLM call -- One platform — LLM observability inside your existing PostHog setup +- User context – traces linked to person profiles and behavioral history +- PostHog Desktop integration – traces become inputs to the autonomy loop +- Session replay correlation – watch what users did before and after an LLM call +- One platform – LLM observability inside your existing PostHog setup ### vs Helicone @@ -100,7 +100,7 @@ If you're building AI features without LLM observability, your agents are flying - Purpose-built for product engineering teams - Dramatically lower cost for the observability product teams actually need - Native integration with feature flags and experiments for model A/B testing -- PostHog Code agent integration +- PostHog Desktop agent integration ## Objections @@ -108,11 +108,11 @@ If you're building AI features without LLM observability, your agents are flying **Follow-up:** How do you connect your LLM quality data to your product metrics today? -**Answer:** Langfuse is a strong trace tool. PostHog LLM Analytics adds what Langfuse doesn't have: user context, session replay correlation, product metric linkage, and PostHog Code agent integration. Many teams run both during evaluation and consolidate as PostHog's LLM features mature. +**Answer:** Langfuse is a strong trace tool. PostHog LLM Analytics adds what Langfuse doesn't have: user context, session replay correlation, product metric linkage, and PostHog Desktop agent integration. Many teams run both during evaluation and consolidate as PostHog's LLM features mature. ### "We just need cost monitoring" -**Answer:** Cost monitoring is one metric. Can you build a better product if you just look at one metric alone? PostHog shows cost per user, cost per feature, cost per cohort — so you can answer "are we spending money on users who convert?" That's the difference between a billing tool and a product tool. +**Answer:** Cost monitoring is one metric. Can you build a better product if you just look at one metric alone? PostHog shows cost per user, cost per feature, cost per cohort – so you can answer "are we spending money on users who convert?" That's the difference between a billing tool and a product tool. ### "Our LLM features aren't production yet" @@ -122,4 +122,4 @@ If you're building AI features without LLM observability, your agents are flying Enterprise LLM Analytics customers get the same four-lever discounting as other PostHog products: volume, commitment, payment timing, forecast certainty. The enterprise conversation usually centers on **cost governance** (which model, which features, which teams are driving spend) and **compliance** (is LLM trace data covered by the DPA; does EU residency apply to conversation data). -The forward-looking pitch: as PostHog Code matures, teams with well-instrumented LLM Analytics will have a fully automated quality improvement loop — traces in, agent optimization out. That's the infrastructure play for AI-native companies in 2030, and it starts with getting the observability layer right today. +The forward-looking pitch: as PostHog Desktop matures, teams with well-instrumented LLM Analytics will have a fully automated quality improvement loop – traces in, agent optimization out. That's the infrastructure play for AI-native companies in 2030, and it starts with getting the observability layer right today. diff --git a/contents/handbook/marketing/positioning/posthog-ai.md b/contents/handbook/marketing/positioning/posthog-ai.md index f6cc8478ff1d..6a8cc3f0eb84 100644 --- a/contents/handbook/marketing/positioning/posthog-ai.md +++ b/contents/handbook/marketing/positioning/posthog-ai.md @@ -8,31 +8,31 @@ showTitle: true ## Elevator pitch -PostHog AI understands your full data model — event taxonomy, user properties, cohorts, flags, experiments, warehouse sources. Ask it a question in plain English. It writes the query, runs it, and explains the result. No prompt engineering. No schema briefing. No waiting for a data team ticket to be picked up. It will also speak like a pirate to you on International Speak Like A Pirate Day. +PostHog AI understands your full data model – event taxonomy, user properties, cohorts, flags, experiments, warehouse sources. Ask it a question in plain English. It writes the query, runs it, and explains the result. No prompt engineering. No schema briefing. No waiting for a data team ticket to be picked up. It will also speak like a pirate to you on International Speak Like A Pirate Day. -PostHog AI is wired into PostHog Code via MCP, so it's not just a query interface for humans — it's the intelligence layer that agents use to understand product impact, measure experiment results, and evaluate whether their changes worked. A key part of the product autonomy loop. +PostHog AI is wired into PostHog Desktop via MCP, so it's not just a query interface for humans – it's the intelligence layer that agents use to understand product impact, measure experiment results, and evaluate whether their changes worked. A key part of the product autonomy loop. ## The unique belief (in terms of PostHog AI) General-purpose AI is impressive but context-blind. When you ask ChatGPT "why did signups drop last Tuesday?", it doesn't know your event taxonomy, your funnel structure, your user cohorts, or what shipped last Monday. Without an MCP (which PostHog also has) you spend more time explaining the context than getting the answer. -PostHog AI is different because it already has the context. It knows your event names, your properties, your SQL schema, and your product's entire behavioral history. It doesn't need to be briefed. It's the query interface for humans and agents alike — and in the [product autonomy loop](/blog/self-driving-product), it's the layer that connects PostHog Code to every insight, dashboard, and metric in the platform. +PostHog AI is different because it already has the context. It knows your event names, your properties, your SQL schema, and your product's entire behavioral history. It doesn't need to be briefed. It's the query interface for humans and agents alike – and in the [product autonomy loop](/blog/self-driving-product), it's the layer that connects PostHog Desktop to every insight, dashboard, and metric in the platform. **PostHog AI isn't AI added onto analytics. It's the interface through which a self-driving product understands itself.** ## Who this is for - **Product managers and non-technical stakeholders** who need product insights without writing SQL or waiting on a data engineer. -- **Engineers who want to move faster** — PostHog AI writes the query so they can iterate on the result. +- **Engineers who want to move faster** – PostHog AI writes the query so they can iterate on the result. - **Teams without a dedicated analyst** where self-serve analytics is the only option that scales. - **AI-native product teams** who want to expose their product data to agents and other LLM runtimes via MCP. -- **PostHog Code users** — PostHog AI is the query engine that powers agent access to product data. +- **PostHog Desktop users** – PostHog AI is the query engine that powers agent access to product data. ### Who this isn't for - Teams who prefer writing SQL directly and always want to do things the hard way. You _can_ do that in PostHog, but then why use PostHog AI? - Organizations that need formal AI output auditing before any query runs in a production data environment. -- Teams looking for a general-purpose AI assistant for tasks outside PostHog — PostHog AI is intentionally scoped to product data. +- Teams looking for a general-purpose AI assistant for tasks outside PostHog – PostHog AI is intentionally scoped to product data. ## Messaging @@ -40,29 +40,29 @@ PostHog AI is different because it already has the context. It knows your event **Problem:** Product data is valuable but inaccessible to most of the people who need it. Non-technical stakeholders can't write SQL. Engineers don't want to context-switch to write a dashboard for a one-off question. Agents need to query metrics programmatically without human intervention. -**Solution:** PostHog AI serves all three audiences from the same interface. A PM asks "what do power users do in their first session?" PostHog AI writes the query and shows the answer. PostHog Code asks "did this deploy regress conversion?" and gets a structured result it can use in the evaluation step of the autonomy loop. +**Solution:** PostHog AI serves all three audiences from the same interface. A PM asks "what do power users do in their first session?" PostHog AI writes the query and shows the answer. PostHog Desktop asks "did this deploy regress conversion?" and gets a structured result it can use in the evaluation step of the autonomy loop. **Supporting features:** - Natural language to HogQL query generation - Supports events, persons, cohorts, funnels, retention, trends, and warehouse data -- MCP integration: PostHog Code and any MCP-compatible agent runtime can query via the same interface +- MCP integration: PostHog Desktop and any MCP-compatible agent runtime can query via the same interface - Explains query logic so you can verify or modify before running ### Message 2: The democratization of your data -**Problem:** Self-serve analytics doesn't mean much if "self-serve" requires SQL fluency. Most product teams are bottlenecked on the analyst who can translate business questions into queries — and that analyst is always busy. +**Problem:** Self-serve analytics doesn't mean much if "self-serve" requires SQL fluency. Most product teams are bottlenecked on the analyst who can translate business questions into queries – and that analyst is always busy. **Solution:** PostHog AI democratizes query access across the entire product team. A customer success manager can ask "how often do enterprise customers use this feature?" A designer can ask "where do users get stuck in the onboarding flow?" An engineer can ask "which error type has the most user impact?" All without SQL, all without a ticket. **Supporting features:** -- Generates complex queries — joins, window functions, cohort comparisons +- Generates complex queries – joins, window functions, cohort comparisons - Pre-built awareness of PostHog's product functions (flags, experiments, cohorts) - Integrates with warehouse sources (Stripe, HubSpot, Salesforce data queryable in natural language) - Dashboard generation from natural language ### Message 3: Context-aware from day one -**Problem:** General AI tools require extensive prompt engineering to be useful for product analytics. You have to explain your schema, your naming conventions, your business logic, and your question — every time. +**Problem:** General AI tools require extensive prompt engineering to be useful for product analytics. You have to explain your schema, your naming conventions, your business logic, and your question – every time. **Solution:** PostHog AI has full access to your event taxonomy, your user property schema, and your existing dashboards. It autocompletes event names correctly. It knows which properties are populated. It understands which cohorts exist. The first time you ask a question, it already knows how to answer it. @@ -79,17 +79,17 @@ PostHog AI is different because it already has the context. It knows your event **Their approach:** Amplitude's AI features work within Amplitude's product analytics context. Good for querying Amplitude data. No feature flag, session replay, warehouse, or agent integration. **Where PostHog wins:** -- PostHog AI has access to the full PostHog platform — analytics, flags, experiments, replay, and warehouse in one context -- MCP integration for agent access — Amplitude has no equivalent -- PostHog Code integration: PostHog AI powers the evaluation step of the product autonomy loop +- PostHog AI has access to the full PostHog platform – analytics, flags, experiments, replay, and warehouse in one context +- MCP integration for agent access – Amplitude has no equivalent +- PostHog Desktop integration: PostHog AI powers the evaluation step of the product autonomy loop ### vs ChatGPT / Claude (direct) **Their approach:** Powerful general-purpose LLMs. Excellent for many tasks. Completely context-blind about your specific data model, event taxonomy, and product structure unless you add our MCP. **Where PostHog wins:** -- No schema briefing required — PostHog AI already knows your data -- Executes queries directly — general LLMs produce SQL you then have to run elsewhere +- No schema briefing required – PostHog AI already knows your data +- Executes queries directly – general LLMs produce SQL you then have to run elsewhere - Integrated into the platform where you already work - MCP bridge for teams who want to use Claude Code or other agents with PostHog data @@ -97,18 +97,18 @@ PostHog AI is different because it already has the context. It knows your event ### "AI-generated SQL isn't reliable enough for production decisions" -**Answer:** PostHog AI shows you the query it generated before running it. You verify, modify, or reject. It's a query accelerator and first-draft generator — not an autonomous decision-maker. You still make the call; PostHog AI removes the SQL translation step. +**Answer:** PostHog AI shows you the query it generated before running it. You verify, modify, or reject. It's a query accelerator and first-draft generator – not an autonomous decision-maker. You still make the call; PostHog AI removes the SQL translation step. ### "We have data analysts who write SQL" -**Answer:** PostHog AI frees analysts from repetitive "how many users did X?" questions and gives everyone else self-service access to answers. Analysts can focus on the work that requires real judgment — designing experiments, interpreting ambiguous results, finding non-obvious patterns. PostHog AI handles the questions that shouldn't take analyst time. +**Answer:** PostHog AI frees analysts from repetitive "how many users did X?" questions and gives everyone else self-service access to answers. Analysts can focus on the work that requires real judgment – designing experiments, interpreting ambiguous results, finding non-obvious patterns. PostHog AI handles the questions that shouldn't take analyst time. ### "We're worried about AI hallucinating column names or event names" -**Answer:** PostHog AI autocompletes from your actual event taxonomy and property schema — it doesn't invent column names. It can misinterpret business logic in complex queries, which is why we show you the SQL before running. Simple to medium complexity queries are reliable. Very complex multi-step analyses should be verified. +**Answer:** PostHog AI autocompletes from your actual event taxonomy and property schema – it doesn't invent column names. It can misinterpret business logic in complex queries, which is why we show you the SQL before running. Simple to medium complexity queries are reliable. Very complex multi-step analyses should be verified. ## Selling to enterprise -PostHog AI is included in the platform — there's no separate AI product to price. The enterprise conversation is usually about **data governance** (can AI generate queries on sensitive user data?) and **access controls** (can we restrict which users can use PostHog AI?). +PostHog AI is included in the platform – there's no separate AI product to price. The enterprise conversation is usually about **data governance** (can AI generate queries on sensitive user data?) and **access controls** (can we restrict which users can use PostHog AI?). -The forward-looking pitch: teams that have PostHog AI set up properly today are the teams that will have the most capable PostHog Code autonomous loop tomorrow. The MCP integration between PostHog AI and coding agents is the technical foundation for self-driving product development — and it starts with getting the query layer instrumented and accessible. Enterprises which don't adopt it are falling behind faster every day. +The forward-looking pitch: teams that have PostHog AI set up properly today are the teams that will have the most capable PostHog Desktop autonomous loop tomorrow. The MCP integration between PostHog AI and coding agents is the technical foundation for self-driving product development – and it starts with getting the query layer instrumented and accessible. Enterprises which don't adopt it are falling behind faster every day. diff --git a/contents/handbook/marketing/positioning/session-replay.md b/contents/handbook/marketing/positioning/session-replay.md index 30150cb413b0..d2f157d9e160 100644 --- a/contents/handbook/marketing/positioning/session-replay.md +++ b/contents/handbook/marketing/positioning/session-replay.md @@ -8,31 +8,31 @@ showTitle: true ## Elevator pitch -PostHog Session Replay records every user session across web and mobile. From any analytics insight, jump to the sessions behind it. From any error in Error Tracking, watch exactly what the user was doing when it happened. From any rage click pattern, let PostHog Code Inbox research and open a fix PR. +PostHog Session Replay records every user session across web and mobile. From any analytics insight, jump to the sessions behind it. From any error in Error Tracking, watch exactly what the user was doing when it happened. From any rage click pattern, let PostHog Desktop Inbox research and open a fix PR. Want to watch sessions manually but overwhelmed by the amount of data? PostHog AI can group and summarize sessions for you, separating signal from noise in an efficient way. -FullStory and Hotjar record sessions. PostHog records sessions *and* connects them to everything else — your metrics, your errors, your flags, and your agents. +FullStory and Hotjar record sessions. PostHog records sessions *and* connects them to everything else – your metrics, your errors, your flags, and your agents. ## The unique belief (in terms of session replay) -Session replay used to be reactive — you watched what went wrong *after* a user complained. In the [product autonomy loop](/blog/self-driving-product), replay is a proactive signal source. PostHog Code's Inbox reads replay patterns — rage clicks, dead ends, unexpected exits — and converts them into researched, prioritized fix PRs before users ever file a ticket. +Session replay used to be reactive – you watched what went wrong *after* a user complained. In the [product autonomy loop](/blog/self-driving-product), replay is a proactive signal source. PostHog Desktop's Inbox reads replay patterns – rage clicks, dead ends, unexpected exits – and converts them into researched, prioritized fix PRs before users ever file a ticket. The shift is fundamental: replay isn't just evidence of a problem. It's the trigger that starts automated remediation. Watching sessions is what humans do. Generating signals from sessions is what self-driving product development does. ## Who this is for -- **Engineers debugging why users are dropping off** — they need to see the session, not just the funnel. -- **Product teams correlating qualitative behavior with quantitative metrics** — jump from a funnel drop to the sessions behind it in one click. +- **Engineers debugging why users are dropping off** – they need to see the session, not just the funnel. +- **Product teams correlating qualitative behavior with quantitative metrics** – jump from a funnel drop to the sessions behind it in one click. - **Teams replacing FullStory or Hotjar** and consolidating to a platform that also covers analytics, flags, and experiments. - **Mobile teams** who need iOS, Android, React Native, and Flutter replay with the same analytics integration as web. - **Anyone using PostHog** who wants to close the gap between "what happened" and "why." ### Who this isn't for -- Enterprises needing advanced session reconstruction for legal, compliance, or accessibility audits — FullStory's enterprise features are more mature here. -- High-volume consumer apps that need aggressive client-side sampling and complex retention policies — larger enterprise plans are required. -- Marketing teams who primarily need heatmaps as the UX research tool — Hotjar is simpler for that specific use case. +- Enterprises needing advanced session reconstruction for legal, compliance, or accessibility audits – FullStory's enterprise features are more mature here. +- High-volume consumer apps that need aggressive client-side sampling and complex retention policies – larger enterprise plans are required. +- Marketing teams who primarily need heatmaps as the UX research tool – Hotjar is simpler for that specific use case. ## Messaging @@ -50,12 +50,12 @@ The shift is fundamental: replay isn't just evidence of a problem. It's the trig ### Message 2: Replay as a signal source, not just a recording -**Problem:** Most teams watch session replays when something goes wrong. The signal is already cold — the user has churned or complained. Proactive replay analysis requires someone to watch hundreds of recordings, which doesn't scale. +**Problem:** Most teams watch session replays when something goes wrong. The signal is already cold – the user has churned or complained. Proactive replay analysis requires someone to watch hundreds of recordings, which doesn't scale. -**Solution:** PostHog Code's Inbox connects to Session Replay as a signal source. Replay patterns — rage clicks, repeated form abandonment, dead-click clusters — are automatically surfaced, researched, and converted into prioritized fix PRs. Sessions feed directly into PR, while AI summarization enables manual review to scale as PostHog AI can group and summarize sessions for you. +**Solution:** PostHog Desktop's Inbox connects to Session Replay as a signal source. Replay patterns – rage clicks, repeated form abandonment, dead-click clusters – are automatically surfaced, researched, and converted into prioritized fix PRs. Sessions feed directly into PR, while AI summarization enables manual review to scale as PostHog AI can group and summarize sessions for you. **Supporting features:** -- PostHog Code Inbox integration with Session Replay as a signal source +- PostHog Desktop Inbox integration with Session Replay as a signal source - Session replay summarization and automatic playlist generation - Rage click and dead click detection - Session collections for grouping related recordings @@ -81,7 +81,7 @@ The shift is fundamental: replay isn't just evidence of a problem. It's the trig **Where PostHog wins:** - Native connection to analytics, feature flags, experiments, and error tracking -- PostHog Code agent integration — replays become inputs to automated fix PRs +- PostHog Desktop agent integration – replays become inputs to automated fix PRs - Significantly lower cost at equivalent session volume - More generous free tier (5,000 sessions/month forever vs FullStory's trial limits) - AI summarization and automatic playlist generation @@ -91,8 +91,8 @@ The shift is fundamental: replay isn't just evidence of a problem. It's the trig **Their approach:** Simple heatmaps, scroll maps, and basic session replay. Popular with non-technical teams. No analytics depth, limited mobile support, no feature flags. **Where PostHog wins:** -- Full analytics integration — jump from Hotjar's heatmaps to PostHog's funnel and back is not possible; PostHog provides both -- Feature flag correlation — filter sessions by which flag variant the user saw +- Full analytics integration – jump from Hotjar's heatmaps to PostHog's funnel and back is not possible; PostHog provides both +- Feature flag correlation – filter sessions by which flag variant the user saw - Agent integration for automated investigation - AI summarization and automatic playlist generation @@ -101,8 +101,8 @@ The shift is fundamental: replay isn't just evidence of a problem. It's the trig **Their approach:** Developer-focused session replay with strong frontend performance monitoring. No product analytics or feature flags. Good DevTools integration. **Where PostHog wins:** -- Broader platform — analytics, flags, experiments, warehouse, and error tracking included -- PostHog Code Inbox integration — LogRocket has no equivalent agent loop +- Broader platform – analytics, flags, experiments, warehouse, and error tracking included +- PostHog Desktop Inbox integration – LogRocket has no equivalent agent loop - Usage-based pricing without seat limits ## Objections @@ -125,4 +125,4 @@ The shift is fundamental: replay isn't just evidence of a problem. It's the trig Enterprise session replay customers get volume discounts, extended mobile replay retention, advanced access controls, SOC 2, and EU data residency. The consolidation pitch is particularly strong here: FullStory and Hotjar contracts are often standalone line items that can be eliminated when replay is included in a PostHog annual deal. -The forward-looking pitch: replay as a signal source for PostHog Code Inbox is a capability no other vendor offers. Teams that instrument replay properly now will have a fully automated UX investigation loop as the agent features mature. +The forward-looking pitch: replay as a signal source for PostHog Desktop Inbox is a capability no other vendor offers. Teams that instrument replay properly now will have a fully automated UX investigation loop as the agent features mature. diff --git a/contents/handbook/people/spending-money.md b/contents/handbook/people/spending-money.md index 1bb4d115511d..bf1650a725b9 100644 --- a/contents/handbook/people/spending-money.md +++ b/contents/handbook/people/spending-money.md @@ -147,7 +147,7 @@ Talk to [Tara](https://posthog.com/community/profiles/34526) who handles most Ma - Laptop guidelines - For engineering roles (product, platform, & support), we recommend a Macbook Pro 14-inch M5 Pro, with the 18-core CPU, 20-core GPU upgrade and 64GB of RAM. - For sales & CS roles, we buy the Macbook Pro 14-inch M5, with 10-core GPU, 16-core and the 32GB RAM upgrade. - - All other roles, we issue Macbook Pros. Wherever possible we will redistribute engineering models (Macbook Pros) no longer in use to allow you to have a more powerful machine for running PostHog Code. + - All other roles, we issue Macbook Pros. Wherever possible we will redistribute engineering models (Macbook Pros) no longer in use to allow you to have a more powerful machine for running PostHog Desktop. - Apple offers multiple screen sizes. The larger screen sizes (15 inches +), are disproportionately more expensive. If you are realistically going to do most of your work at home, it is more rational to pick a smaller laptop size, and to get a large monitor. - We only purchase laptops with an English keyboard configuration (US, International or British is fine) - this enables us to easily pass your laptop on to someone else if you upgrade or leave. - In the unlikely case that you need to purchase your own laptop: diff --git a/contents/handbook/story.md b/contents/handbook/story.md index 5afae855f97a..2983ff15c04d 100644 --- a/contents/handbook/story.md +++ b/contents/handbook/story.md @@ -238,8 +238,8 @@ Around here we stopped calling ourselves an analytics company. We're (almost) ev We raised again – a $75m Series E led by Peak XV at a ~$1.4bn valuation. That technically makes us a unicorn. Total raised since 2020 is ~$194m, and we're ~140 people now. We also offered employees secondary, which we [wrote about](/blog/how-secondaries-actually-work). -### Early 2026: PostHog Code +### Early 2026: PostHog Desktop -~200 people and a product list too long to keep reciting! [PostHog Code](/desktop) was probably our biggest launch yet. +~200 people and a product list too long to keep reciting! [PostHog Desktop](/desktop) was probably our biggest launch yet. Our vision is now to make your product [self-driving](/self-driving). diff --git a/src/navs/index.js b/src/navs/index.js index f429ea2dc59b..f7914ac869f5 100644 --- a/src/navs/index.js +++ b/src/navs/index.js @@ -1130,6 +1130,10 @@ export const handbookSidebar = [ name: 'PostHog AI', url: '/handbook/marketing/positioning/posthog-ai', }, + { + name: 'PostHog Desktop', + url: '/handbook/marketing/positioning/desktop', + }, ], }, ], From c2abf06bb9d89df9e84fd307761063ce12e8f7ff Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Tue, 21 Jul 2026 21:19:48 -0400 Subject: [PATCH 2/5] added positioning guide to marketing handbook --- .../handbook/marketing/positioning/desktop.md | 147 +++++++++--------- .../handbook/marketing/positioning/index.md | 2 +- 2 files changed, 76 insertions(+), 73 deletions(-) diff --git a/contents/handbook/marketing/positioning/desktop.md b/contents/handbook/marketing/positioning/desktop.md index d6740ef9ab3e..6a8f552336c6 100644 --- a/contents/handbook/marketing/positioning/desktop.md +++ b/contents/handbook/marketing/positioning/desktop.md @@ -8,134 +8,137 @@ showTitle: true ## Elevator pitch -PostHog Desktop is a desktop app that runs coding agents on top of your product data. Real usage goes in, pull requests come out. It watches your errors, logs, and session recordings for problems worth fixing, turns them into tasks, and lets you run a fleet of agents against them in parallel – locally or in the cloud. +PostHog Desktop is a product editor: a desktop app where you, your team, and a fleet of coding agents build your product together. -Every other AI coding tool starts from the repo. PostHog Desktop starts from what your users are actually doing. The obvious fixes ship themselves behind a flag; the judgement calls show up as a prioritized to-do list for you to steer. - -Cursor edits your code. PostHog Desktop edits your product. +The same self-driving engine that turns product data into pull requests runs in PostHog web, but Desktop isn't where you watch that work happen; it's where you do it. Think of the web app as the dashboard and Desktop as the driver's seat. ## The unique belief (in terms of PostHog Desktop) -A coding agent that only reads your codebase is working with half the picture. It knows what the code says. It has no idea that checkout is throwing 500s for Android users, that a rename broke a funnel last Tuesday, or that nobody makes it past step three of onboarding. That context lives in your product data, not your repo. - -PostHog Desktop is different because it's built on top of that data. Signals scan your errors, logs, and summarized recordings and surface the problems worth acting on. Tasks turn them into work. Agents do the work. And because PostHog also owns the analytics, flags, and experiments, it can close the [product autonomy loop](/blog/self-driving-product): ship the change behind a flag, measure whether it actually worked, and roll it back if it didn't. No other coding tool can do the last step, because no other coding tool has the data. - -**Other agents write code. PostHog Desktop builds your product.** +Agents write most of code now. Claude Code and Codex are all excellent at the work, but neither of them can originate it – they need a prompt from a human to turn it into a task. The solution isn't a chat box, and it isn't an IDE. It's a product editor: one that's deeply integrated with your data, and multiplayer (like work actually is). ## Who this is for -It's not only for the people writing the code. The autonomy loop touches everyone who decides what to build and checks whether it worked – engineers, product, marketing, and the people steering the roadmap. +The primary audience is AI-pilled software teams at engineering-led companies. Adoption starts bottom-up, the way PostHog always wins: an engineer connects a repo, turns on signals, and the first fixes show up within minutes. | Persona | Fit | Why | | --- | --- | --- | -| **Solo indie hacker** | Strong | One person owns the code, the data, and the decisions. A fleet of agents multiplies a team of one, and signals keep it pointed at what users actually hit. | -| **Professional software engineer** | Strong | Spend your time on the hard 20% while agents clear the obvious 80% – each fix wired to the data that says whether it worked. | -| **Startup engineering team** | Strong | More known problems than hands to fix them. Run agents in parallel and let Channels keep the team working together instead of in private chats. | -| **Product manager** | Strong | Turn signals into tasks, steer the agents on them, and read the impact yourself instead of waiting on an engineering ticket. | -| **Non-technical founder** | Good | Describe the product in plain English, let agents build it, and once you have users the production signals start driving the roadmap. | -| **Enterprise engineering team** | Good, with caveats | Usage-based pricing and flag-wrapped rollouts appeal, but governance is less mature than incumbents and it's still beta. See [selling to enterprise](#selling-to-enterprise). | -| **Product marketer** | Situational | Pull real product data and ship site or copy changes directly, without an engineer in the loop – useful, but not the core motion. | -| **Exec / leadership team** | Situational | Good for seeing what's shipping and what signals are surfacing, and for steering priorities – less so for hands-on building. | -| **Beginner learning to build apps** | Not yet | It'll happily build for you, but the production autonomy loop is wasted until you have real usage. A simpler coding tool fits better while you're learning. | - -Across all of these, the fit is sharpest for teams whose product data is already in PostHog – that's what turns a good coding agent into a self-driving product. +| **Founding team** | Strong | Team size is a worse proxy for fit than it used to be – a five-person founding team can already carry the product surface of a company ten times its size. The loop is what lets that founder-mode instinct (care about every detail, fix it today) scale past the headcount that used to cap it. | +| **Startup** | Strong | PMF and a growing backlog of small fixes nobody has time to get to. A fleet of agents plus the loop clears it without another hire, and product data keeps every fix pointed at what users actually hit. | +| **Scaleup** | Strong | Multiple teams, each already running their own coding agents that don't talk to each other or share any context. PostHog Desktop gives them one shared loop instead of a dozen disconnected ones. | +| **Enterprise** | Good, with caveats | More data means more signal to act on, but also more noise. Agents shipping changes into a very complex codebase spanning many teams is a bigger blast radius to get wrong, with more org-hierarchy friction than a smaller team deals with. Might be a hard sell unless they operate like a compound startup. | + +PostHog Desktop fits best for teams with a real product and real users (that's the fuel the whole thing runs on). It's a workbench for engineers, but the benefits extend to other roles in build mode (product managers, marketers, and pesky execs trying to steer the roadmap). ### Who this isn't for -- Teams who just want inline autocomplete in their existing editor. Copilot and Cursor are more mature at fast, in-flow suggestions, and that's a different job. -- Codebases with no PostHog data yet. Without signals, PostHog Desktop is a good coding agent but you're leaving its whole reason for existing on the table – start by instrumenting first. -- Organizations that need fully on-prem or air-gapped agent execution today. Cloud execution is the default; if the requirement is a hard no on external execution, we're not the fit yet. +- Teams who haven't shipped a product to real users. Without product data there are no signals to act on. +- Non-technical builders without a repo to point at (using Lovable, Replit, and other no-code platforms). ## Messaging -### Message 1: The only agent that reads production, not just the repo +### Message 1: Real usage catches what review can't -**Problem:** Coding agents are only as good as their context, and most of them are blind to production. They can refactor a function beautifully while having no idea it's the one throwing errors for 4% of your users. You end up feeding them the context by hand – pasting stack traces, describing the bug, explaining what changed. +**Problem:** Code review catches wrongness in the syntax, but it can't catch wrongness in *behaviour*. That's because behaviour only shows up in production. -**Solution:** PostHog Desktop's Signals watch your errors, logs, and session recordings and surface the problems worth fixing without being asked. Each one becomes a task an agent can pick up with the production context already attached. The agent isn't guessing what to work on – it's starting from what's actually breaking. +**Solution:** In PostHog Desktop, flags and experiments are how a code change actually earns its spot. When an agent opens a PR, it builds in instrumentation and measures against a real metric you care about. If it works, great. If it doesn't, it fixes it. **Supporting features:** -- Signals scan errors, logs, and summarized session recordings for problems worth acting on -- Tasks created automatically from signals, or from a prompt when you have your own idea -- Full PostHog data model available to the agent via MCP and PostHog AI -- Changes wrapped in a feature flag by default so a bad fix has a kill switch +- Feature flags wrap agent-shipped changes by default, before they reach everyone +- Experiments measure the change against the metric that matters, not just "did it deploy" +- Scouts watch your product on a schedule and open a PR when they find something worth fixing +- Your events, errors, and session replays are the secret sauce – that's the real data every fix gets checked against -### Message 2: Run a fleet, not a chat +### Message 2: Your product gets better in between the times you look at it -**Problem:** Most agent tools are one conversation at a time. You prompt, you wait, you review, you prompt again. That's fine for a single task and useless for a backlog of fifty. The bottleneck stops being the code and starts being the number of chats you can babysit. +**Problem:** Every team has a long tail of work that's real but not urgent. Papercuts compete for the same hours as the big bets, and the big bets usually win the argument. -**Solution:** The Command Center runs up to nine agents in parallel, each on its own task, cloud or local. You steer the ones that need judgement and let the rest run – including overnight. Channels give the whole thing a multiplayer surface, so your team works alongside the agents instead of each person driving a private chat. +**Solution:** PostHog agents watch that long tail continuously and turn what they find into shipped fixes. The dull triage work doesn't need a human, and your product improves while you sleep. Better instrumentation leads to better detection, better detection leads to better tasks, and better tasks lead to clearer data telling you exactly where to spend your own judgment. **Supporting features:** -- Command Center runs up to nine agents at once, each on a separate task -- Cloud execution by default; local execution when you want it -- Channels: a shared, multiplayer workspace where agent sessions live and context accumulates -- Human review before anything ships – agents work autonomously, you keep the final call +- Handles the long tail of polish – papercuts, small fixes, instrumentation, cleanup, docs, edge cases +- No prompt required: Signals and Scouts generate reports which turn into PRs +- Frees your best people for the work that needs judgment – architecture, big bets, and the problems only a human notices out in the real world -### Message 3: One subscription, every model, wired to your data +### Message 3: Humans and agents building together -**Problem:** The agent tooling stack fragments fast. A Claude Code subscription here, a Cursor seat there, an analytics tool that doesn't talk to any of them. You're paying three vendors and stitching the context together yourself. +**Problem:** Midjourney hit $200M in revenue with 40 people – outsized impact from a tiny team (and we'll see a lot more of this soon). Agents solved the writing-code half, they don't solve the managing-it-all half. More changes means more surface area for the same small team to review, measure, and catch when something goes sideways. -**Solution:** PostHog Desktop gives you the latest models – Claude, Codex, open source – without a separate subscription to any of them, at usage-based pricing that lands around what you'd pay anyway. And because it's PostHog, the agent can query your analytics, read your flags, and check whether a change worked, all from the same place you already keep your data. +**Solution:** That's the half PostHog Desktop is built for. A handful of people steering a fleet of agents from a shared workspace can outship a team ten times their size, without losing the detail that velocity like that usually costs you. Call it founder mode for your product: the hands-on, fix-it-today instinct that used to only survive at five people, running as the default no matter how big or small your company gets. **Supporting features:** -- Access to the latest Claude, Codex, and open-source models with no separate provider subscription -- Usage-based pricing – pay for what the agents actually do -- PostHog AI and MCP give agents a native query interface to your product data -- Flags, experiments, analytics, and replay all in the same platform the agent ships into +- Parallel agent orchestration, multi-model – run several agents at once, each on the model that fits the task +- Channels: a shared space where your team's agent work lives, with memory that sticks around between sessions *(alpha)* +- Canvases: ask for a dashboard, report, or internal tool and get it built on your real data model *(alpha)* +- No markup – you pay the token costs, not a subscription stacked on top ## Battle cards ### vs Claude Code / Codex -**Their approach:** Excellent terminal-based coding agents. They read your repo, run commands, and write good code. Context stops at the codebase – they don't know your production data, and they can't measure whether a change worked. Each is a separate subscription. +**Their approach:** Claude Code and Codex are Anthropic and OpenAI's own coding products, built on the same models PostHog Desktop runs on top of. They're the harness we use and a direct competitor at the same time, since they sell their own single-player interface around those same models. **Where PostHog wins:** -- Production context: Signals surface what to fix from real usage, not just the repo -- Closes the loop – ships behind a flag, then measures impact in the same platform -- Run up to nine agents in parallel from the Command Center, not one session at a time -- No separate model subscription; usage-based pricing across Claude, Codex, and open source -- Still uses the same underlying models, so you're not trading away code quality to get all of this +- Multiplayer: your whole team and their agents share channels and context, not private terminals +- Native product context – work is sourced from and measured against your product data +- Not either/or: PostHog Desktop runs the Claude Code and Codex harnesses through one app at usage-based pricing, no per-tool subscription -### vs Devin +### vs Devin, Factory, and other scoped AI engineering tools -**Their approach:** An autonomous cloud software engineer, closest to the "ships while you sleep" pitch. Strong at taking a task and running with it end to end. Its autonomy is scoped to the codebase and the task you hand it. +**Their approach:** An autonomous cloud engineer that takes a task and runs. Strong at unattended work, scoped to the codebase and the task you hand it. **Where PostHog wins:** -- The tasks come from production signals, not just from what you think to ask for -- Impact measurement is built in – PostHog owns the analytics that tell you if it worked -- Multiplayer Channels and a nine-agent Command Center, not a single autonomous worker -- Feature-flag-wrapped rollouts give autonomous changes a native safety net +- A product editor you actively steer (plan, review, redirect mid-run) +- Multiplayer by design: a shared team surface, not a single autonomous worker +- Work is grounded in and measured against your product data, then shipped behind a flag +- Usage-based pricing rather than a fixed monthly seat -### vs the agentic multiplayer-workspace challengers (Buzz, Capy, PromptQL, Dust) +### vs the agentic multiplayer-workspace (Buzz, Capy, PromptQL, Dust) -This is a new and fast-moving category, so keep the comparison honest and current – check what each one actually ships before leaning on specifics. +*This is a new and fast-moving category. Check what each one actually shipped recently before leaning on specifics.* -**Their approach:** A growing set of tools putting agents into a shared, multiplayer workspace, several of them layered on top of your existing data or tools. +**Their approach:** A growing set of tools putting agents into a shared, multiplayer workspace, layered on top of your existing data or tools. **Where PostHog wins:** -- We own the whole stack the agents act on – data, analytics, flags, experiments, replay – rather than bolting an agent onto someone else's data -- The autonomy loop only closes when the same platform can both ship the change and measure it; that's structurally hard to replicate from a workspace layer alone -- Everything runs against real product data you already have in PostHog +- We own the whole stack the agents act on – product data, analytics, flags, experiments, replay – rather than bolting an agent onto someone else's data +- The self-driving loop closes because the same platform ships the change and measures whether it worked +- We're not a workspace layered on top of someone else's product data – PostHog is the product data, so there's no integration to build or context to lose in the handoff ## Objections -### "We already use Cursor / Claude Code and the team likes it" +### "Why a new app? Just give me an MCP into my existing setup." + +**What they're really saying:** I live in Claude Code or Cursor. My workflow is settled. + +**Answer:** Fair, and you can! Our MCP is a first-class product, and for a lot of teams, it's the main way they use PostHog. The inbox and signals are in the web app too, so reviewing work doesn't require the app either. Desktop exists for a different job: running many agents at once and working on them alongside your teammates in a shared space – shipping, reviewing, and iterating together in a control center. It's a much more intuitive way to build a product than a terminal built for one. + +### "Why pay usage when my Anthropic subscription is subsidized?" + +**What they're really saying:** Inference feels free right now. Anything metered next to a flat, subsidized sub looks expensive. + +**Answer:** You're comparing the cost of generating changes with the cost of knowing whether they worked. Run the logic forward: subsidized inference means you'll run more agents making more changes, which makes verification the growing line item, not the optional one. We also run open source models, which are getting good enough to handle plenty of the work for a fraction of the cost. + +*When they push on bill predictability (a fair worry) point at billing limits and per-tool caps. Don't argue that usage-based pricing is painless; argue it's honest.* + +### "We already have an established stack. Why consolidate?" + +**What they're really saying:** Switching cost is enormous, and "all-in-one" has historically meant "mediocre at everything." + +**Answer:** When an agent ships a change behind a flag, the flag system needs to know which sessions saw it, replay needs to know which errors those sessions hit, and the experiment needs to tie all three back to the same user, automatically, within moments, or the rollout can't proceed. Across vendors that's either glue code you write and maintain, humans acting as APIs, or precious context falling through the cracks. One system of record isn't a procurement preference anymore, it's what keeps the agent loop, well, looping. -**Follow-up:** Where does that agent get its context today – just the repo, or does it know what's happening in production? +### "I don't trust agents to ship. We review every PR by hand." -**Answer:** Keep using them for in-flow coding if the team likes them; PostHog Desktop runs the same underlying models, so it's not a downgrade on code quality. The difference is where the work comes from and what happens after. PostHog Desktop starts from production signals and measures impact after shipping – the parts a repo-only agent can't do. Plenty of teams run both. +**What they're really saying:** The 2030 story is ahead of my org. Don't sell me the destination. -### "It's still in beta" +**Answer:** No problem – most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. -**Answer:** It is, and we're honest about that – some features are early and it's improving weekly. It's the tool we use to build PostHog itself, which is the same bar we hold every product to before we ship it. If you need a locked-down, GA-only tool for a regulated production process today, wait. If you want to shape a category-defining product and get the autonomy loop working before your competitors do, now is the time. +### "It's still beta, and the multiplayer stuff sounds early." -### "We don't want agents shipping to production autonomously" +**What they're really saying:** I don't want to bet a workflow on something half-built. -**Answer:** Neither do we, and PostHog Desktop is built that way. Agents do the work autonomously, but a human reviews and approves before anything ships. Changes are wrapped in a feature flag by default, so even an approved change rolls out gradually with a kill switch – and the analytics tell you whether to keep going. Autonomy is on the work, not on the deploy button. +**Answer:** It's a WIP, and we'd rather say so than oversell. The core coding primitives (tasks, the Command Center, multi-model support, MCP) is solid, and it's what we use to build PostHog every day. Channels, canvases, and channel memory are alpha and changing weekly. If you need a locked-down, GA-only tool today, wait. If you want a say in where multiplayer agent development goes, hop in. ## Selling to enterprise -PostHog Desktop is usage-based – you pay for what the agents do, with no per-seat model subscription to stack on top. That maps cleanly onto how larger teams want to budget agent spend, and it scales with usage rather than headcount. +PostHog Desktop is usage-based with no per-seat license. You pay for what the agents consume, starting from a free monthly tier ($20). Multi-model support (including open source) means no lock-in to a single provider's roadmap or contract. -Enterprise customers get SSO, EU data residency, SOC 2, and dedicated support, with contracts following [the four-lever framework](/handbook/growth/sales/contract-rules). The forward-looking pitch is simple: the autonomy loop only works for teams whose product data is already in PostHog. The teams instrumenting analytics, flags, and replay today are the ones who will have a working self-driving product tomorrow – and the gap widens every month they wait. +The forward-looking pitch: the self-driving loop runs on product data, so established companies with lots data are the ones who can put the most work on autopilot (and steer the rest from one place, as a team). diff --git a/contents/handbook/marketing/positioning/index.md b/contents/handbook/marketing/positioning/index.md index 229f56d86fdf..19bec1cbeadf 100644 --- a/contents/handbook/marketing/positioning/index.md +++ b/contents/handbook/marketing/positioning/index.md @@ -49,7 +49,7 @@ A reference index to the per-tool pages. Each follows the same shape – unique - [**Endpoints**](/handbook/marketing/positioning/endpoints) – Turn any saved insight or SQL query into a stable, authenticated HTTP endpoint - [**LLM analytics**](/handbook/marketing/positioning/llm-analytics) – Knowing why your LLM-powered feature is bleeding money or shipping nonsense - [**PostHog AI**](/handbook/marketing/positioning/posthog-ai) – A query interface that already knows your schema (and your users) -- [**PostHog Desktop**](/handbook/marketing/positioning/desktop) – A desktop app that runs a fleet of coding agents on top of your product data +- [**PostHog Desktop**](/handbook/marketing/positioning/desktop) – The product editor: where you, your team, and a fleet of agents build together The **context warehouse** has its own page too, but treat it as the platform everything above is built on – the data warehouse plus modelling, pipelines, and exports – not as a co-equal tool in this list: From f8ea0adcb98fbe9e23296fe1b1e285e7b887ad29 Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Wed, 22 Jul 2026 11:43:23 -0400 Subject: [PATCH 3/5] Update PostHog Desktop positioning with clearer, more authentic messaging Generated-By: PostHog Code --- .../handbook/marketing/positioning/desktop.md | 76 ++++++++++--------- 1 file changed, 40 insertions(+), 36 deletions(-) diff --git a/contents/handbook/marketing/positioning/desktop.md b/contents/handbook/marketing/positioning/desktop.md index 6a8f552336c6..008e4779cdd8 100644 --- a/contents/handbook/marketing/positioning/desktop.md +++ b/contents/handbook/marketing/positioning/desktop.md @@ -4,17 +4,17 @@ sidebar: Handbook showTitle: true --- -*For the canonical frame everyone at PostHog uses – the self-driving story and standard description – see [Brand foundations](/handbook/brand/foundations#how-we-describe-posthog).* +*For the canonical frame everyone at PostHog uses (the self-driving story and standard description), see [Brand foundations](/handbook/brand/foundations#how-we-describe-posthog).* ## Elevator pitch -PostHog Desktop is a product editor: a desktop app where you, your team, and a fleet of coding agents build your product together. - -The same self-driving engine that turns product data into pull requests runs in PostHog web, but Desktop isn't where you watch that work happen; it's where you do it. Think of the web app as the dashboard and Desktop as the driver's seat. +PostHog makes your product self-driving: agents work off your product's own context (events, errors, session replays) to find real problems, fix them, and open PRs without being prompted. PostHog Desktop is the product editor where you and your team run that loop together, steering a whole fleet of agents at once. Because the context is already there, the PRs are grounded in how your product actually behaves, not the generic slop from an agent that's only seen your code. ## The unique belief (in terms of PostHog Desktop) -Agents write most of code now. Claude Code and Codex are all excellent at the work, but neither of them can originate it – they need a prompt from a human to turn it into a task. The solution isn't a chat box, and it isn't an IDE. It's a product editor: one that's deeply integrated with your data, and multiplayer (like work actually is). +Agents write most of the code now, but someone still has to hand them a task. That's what a product editor does, and it only works if it can see your product data. + +The old way to build with agents: one engineer, one agent (maybe loads if you're savvy), alone, working locally from whatever's in their head. Desktop is the new way: your whole team steers a fleet of cloud agents from one shared place, and the work comes straight from your real product data (events, errors, replays, and signals that show what's broken or missing). ## Who this is for @@ -22,65 +22,65 @@ The primary audience is AI-pilled software teams at engineering-led companies. A | Persona | Fit | Why | | --- | --- | --- | -| **Founding team** | Strong | Team size is a worse proxy for fit than it used to be – a five-person founding team can already carry the product surface of a company ten times its size. The loop is what lets that founder-mode instinct (care about every detail, fix it today) scale past the headcount that used to cap it. | -| **Startup** | Strong | PMF and a growing backlog of small fixes nobody has time to get to. A fleet of agents plus the loop clears it without another hire, and product data keeps every fix pointed at what users actually hit. | -| **Scaleup** | Strong | Multiple teams, each already running their own coding agents that don't talk to each other or share any context. PostHog Desktop gives them one shared loop instead of a dozen disconnected ones. | -| **Enterprise** | Good, with caveats | More data means more signal to act on, but also more noise. Agents shipping changes into a very complex codebase spanning many teams is a bigger blast radius to get wrong, with more org-hierarchy friction than a smaller team deals with. Might be a hard sell unless they operate like a compound startup. | +| **Founding team** | Strong | Five people can now cover the product surface of a company 10x their size. The loop lets you keep the founder instinct (fix every papercut today) long after you'd normally have run out of hands. | +| **Startup** | Strong | You've got PMF and a backlog of small fixes nobody has time for. Agents clear it without another hire, and your product data keeps every fix aimed at what users actually hit. | +| **Scaleup** | Strong | Multiple teams already running their own coding agents that share no context. Desktop gives them one shared loop instead of a dozen disconnected ones. | +| **Enterprise** | Good, with caveats | More data, more signal, but also more noise, and a bigger blast radius when an agent ships into a huge multi-team codebase. Add the org politics and it's a harder sell, unless they already act like a compound startup. | -PostHog Desktop fits best for teams with a real product and real users (that's the fuel the whole thing runs on). It's a workbench for engineers, but the benefits extend to other roles in build mode (product managers, marketers, and pesky execs trying to steer the roadmap). +Desktop fits best for teams with a real product and real users (that's the fuel the whole thing runs on). It's built for engineers, but anyone in build mode gets value: PMs, marketers, and pesky execs trying to steer the roadmap. ### Who this isn't for -- Teams who haven't shipped a product to real users. Without product data there are no signals to act on. +- Teams who haven't shipped a product to real users. No product data means no signals to act on. - Non-technical builders without a repo to point at (using Lovable, Replit, and other no-code platforms). ## Messaging ### Message 1: Real usage catches what review can't -**Problem:** Code review catches wrongness in the syntax, but it can't catch wrongness in *behaviour*. That's because behaviour only shows up in production. +**Problem:** Code review catches bugs in the code. It can't catch a change that works exactly as written but makes things worse for real users. That only shows up once real people use it in production. -**Solution:** In PostHog Desktop, flags and experiments are how a code change actually earns its spot. When an agent opens a PR, it builds in instrumentation and measures against a real metric you care about. If it works, great. If it doesn't, it fixes it. +**Solution:** In PostHog Desktop, agent-shipped changes go out behind a feature flag before they reach everyone. When a change is worth measuring, it's checked against a metric you actually care about, so you find out whether it helped or hurt real users, not just whether it deployed. If the numbers move the right way, it stays. If they don't, the agent fixes it or rolls it back. **Supporting features:** - Feature flags wrap agent-shipped changes by default, before they reach everyone - Experiments measure the change against the metric that matters, not just "did it deploy" - Scouts watch your product on a schedule and open a PR when they find something worth fixing -- Your events, errors, and session replays are the secret sauce – that's the real data every fix gets checked against +- Every fix gets checked against your real events, errors, and session replays, not a hunch -### Message 2: Your product gets better in between the times you look at it +### Message 2: Your product gets better while you're not looking **Problem:** Every team has a long tail of work that's real but not urgent. Papercuts compete for the same hours as the big bets, and the big bets usually win the argument. -**Solution:** PostHog agents watch that long tail continuously and turn what they find into shipped fixes. The dull triage work doesn't need a human, and your product improves while you sleep. Better instrumentation leads to better detection, better detection leads to better tasks, and better tasks lead to clearer data telling you exactly where to spend your own judgment. +**Solution:** PostHog agents watch that long tail around the clock and turn what they find into shipped fixes. Triage doesn't need a human, so the boring stuff gets handled while you sleep, and the better your instrumentation, the sharper the tasks the agents pick up. **Supporting features:** -- Handles the long tail of polish – papercuts, small fixes, instrumentation, cleanup, docs, edge cases -- No prompt required: Signals and Scouts generate reports which turn into PRs -- Frees your best people for the work that needs judgment – architecture, big bets, and the problems only a human notices out in the real world +- Handles the long tail of polish (papercuts, small fixes, instrumentation, cleanup, docs, edge cases) +- No prompt required: Signals and Scouts generate reports that turn into PRs +- Frees your best people for the work that needs judgment (architecture, big bets, and the problems only a human notices out in the real world) ### Message 3: Humans and agents building together -**Problem:** Midjourney hit $200M in revenue with 40 people – outsized impact from a tiny team (and we'll see a lot more of this soon). Agents solved the writing-code half, they don't solve the managing-it-all half. More changes means more surface area for the same small team to review, measure, and catch when something goes sideways. +**Problem:** Midjourney did $200M in revenue with 40 people. We'll see a lot more of that. Agents cracked the writing-code half. They didn't touch the managing-it-all half. More changes shipped means more surface for the same small team to review, measure, and catch when something goes sideways. -**Solution:** That's the half PostHog Desktop is built for. A handful of people steering a fleet of agents from a shared workspace can outship a team ten times their size, without losing the detail that velocity like that usually costs you. Call it founder mode for your product: the hands-on, fix-it-today instinct that used to only survive at five people, running as the default no matter how big or small your company gets. +**Solution:** That's the half Desktop is built for. A few people steering a fleet of agents from one shared workspace can outship a team 10x their size, and keep the attention to detail that kind of speed usually kills. It's founder mode that doesn't fall apart as you grow. **Supporting features:** -- Parallel agent orchestration, multi-model – run several agents at once, each on the model that fits the task +- Parallel agent orchestration, multi-model: run several agents at once, each on the model that fits the task - Channels: a shared space where your team's agent work lives, with memory that sticks around between sessions *(alpha)* - Canvases: ask for a dashboard, report, or internal tool and get it built on your real data model *(alpha)* -- No markup – you pay the token costs, not a subscription stacked on top +- No markup: you pay the token costs, not a subscription stacked on top ## Battle cards ### vs Claude Code / Codex -**Their approach:** Claude Code and Codex are Anthropic and OpenAI's own coding products, built on the same models PostHog Desktop runs on top of. They're the harness we use and a direct competitor at the same time, since they sell their own single-player interface around those same models. +**Their approach:** Anthropic's and OpenAI's own coding products, built on the same models Desktop runs on top of. They're both the harness we use and a competitor (they sell a single-player interface around those models). **Where PostHog wins:** - Multiplayer: your whole team and their agents share channels and context, not private terminals -- Native product context – work is sourced from and measured against your product data -- Not either/or: PostHog Desktop runs the Claude Code and Codex harnesses through one app at usage-based pricing, no per-tool subscription +- Native product context: work is sourced from and measured against your product data +- Not either/or: Desktop runs the Claude Code and Codex harnesses through one app at usage-based pricing, no per-tool subscription ### vs Devin, Factory, and other scoped AI engineering tools @@ -90,7 +90,7 @@ PostHog Desktop fits best for teams with a real product and real users (that's t - A product editor you actively steer (plan, review, redirect mid-run) - Multiplayer by design: a shared team surface, not a single autonomous worker - Work is grounded in and measured against your product data, then shipped behind a flag -- Usage-based pricing rather than a fixed monthly seat +- Usage-based pricing, not a fixed monthly seat ### vs the agentic multiplayer-workspace (Buzz, Capy, PromptQL, Dust) @@ -99,9 +99,9 @@ PostHog Desktop fits best for teams with a real product and real users (that's t **Their approach:** A growing set of tools putting agents into a shared, multiplayer workspace, layered on top of your existing data or tools. **Where PostHog wins:** -- We own the whole stack the agents act on – product data, analytics, flags, experiments, replay – rather than bolting an agent onto someone else's data -- The self-driving loop closes because the same platform ships the change and measures whether it worked -- We're not a workspace layered on top of someone else's product data – PostHog is the product data, so there's no integration to build or context to lose in the handoff +- We own the whole stack the agents act on (product data, analytics, flags, experiments, replay) instead of bolting an agent onto someone else's data +- The loop actually closes, because the same platform ships the change and measures whether it worked +- There's no data to integrate and no context to lose in a handoff, because there is no handoff ## Objections @@ -109,36 +109,40 @@ PostHog Desktop fits best for teams with a real product and real users (that's t **What they're really saying:** I live in Claude Code or Cursor. My workflow is settled. -**Answer:** Fair, and you can! Our MCP is a first-class product, and for a lot of teams, it's the main way they use PostHog. The inbox and signals are in the web app too, so reviewing work doesn't require the app either. Desktop exists for a different job: running many agents at once and working on them alongside your teammates in a shared space – shipping, reviewing, and iterating together in a control center. It's a much more intuitive way to build a product than a terminal built for one. +**Answer:** Fair, and you can. Our MCP is first-class, and for a lot of teams it's the main way they use PostHog. Inbox and signals live in the web app too, so you don't need Desktop to review work. Desktop is for a different job: running many agents at once, with your teammates, in one place. ### "Why pay usage when my Anthropic subscription is subsidized?" **What they're really saying:** Inference feels free right now. Anything metered next to a flat, subsidized sub looks expensive. -**Answer:** You're comparing the cost of generating changes with the cost of knowing whether they worked. Run the logic forward: subsidized inference means you'll run more agents making more changes, which makes verification the growing line item, not the optional one. We also run open source models, which are getting good enough to handle plenty of the work for a fraction of the cost. +**Answer:** A lot of the work doesn't need a frontier model. PostHog runs multiple models, including open-source ones that are getting good enough to handle plenty of tasks for a fraction of the price. You're not locked to one subscription that's subsidized today and will probably be repriced tomorrow. *When they push on bill predictability (a fair worry) point at billing limits and per-tool caps. Don't argue that usage-based pricing is painless; argue it's honest.* +### "Why would I trust PostHog to ship code? You're an analytics company." + +**Answer:** Fair question, but you're not betting on PostHog being a great engineer. The code is written by Claude Code and Codex, the same models you'd use anyway. What PostHog adds is the safety net around them: every change ships behind a flag, gets measured against real user behavior, and doesn't reach everyone until the numbers say it's safe. If something regresses, you kill it with a flag, no redeploy or revert. You still review the PRs and set the CI rules the agents follow. That's more scrutiny than most teams put on their hand-written code, and it's exactly how we ship PostHog itself. + ### "We already have an established stack. Why consolidate?" **What they're really saying:** Switching cost is enormous, and "all-in-one" has historically meant "mediocre at everything." -**Answer:** When an agent ships a change behind a flag, the flag system needs to know which sessions saw it, replay needs to know which errors those sessions hit, and the experiment needs to tie all three back to the same user, automatically, within moments, or the rollout can't proceed. Across vendors that's either glue code you write and maintain, humans acting as APIs, or precious context falling through the cracks. One system of record isn't a procurement preference anymore, it's what keeps the agent loop, well, looping. +**Answer:** When an agent ships behind a flag, the flag system has to know which sessions saw it, replay has to know which errors those sessions hit, and the experiment has to tie it all back to the same user, automatically, in seconds, or the rollout stalls. Across separate vendors that's glue code you maintain forever, humans copy-pasting between tools, or context falling through the cracks. One system of record is what keeps the loop running at all. ### "I don't trust agents to ship. We review every PR by hand." **What they're really saying:** The 2030 story is ahead of my org. Don't sell me the destination. -**Answer:** No problem – most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. +**Answer:** No problem, most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. ### "It's still beta, and the multiplayer stuff sounds early." **What they're really saying:** I don't want to bet a workflow on something half-built. -**Answer:** It's a WIP, and we'd rather say so than oversell. The core coding primitives (tasks, the Command Center, multi-model support, MCP) is solid, and it's what we use to build PostHog every day. Channels, canvases, and channel memory are alpha and changing weekly. If you need a locked-down, GA-only tool today, wait. If you want a say in where multiplayer agent development goes, hop in. +**Answer:** It's a WIP, and we'd rather say so than oversell. The core coding primitives (tasks, the Command Center, multi-model support, MCP) are solid, and they're what we use to build PostHog Desktop itself. Channels, canvases, and channel memory are in alpha and changing shape weekly. ## Selling to enterprise PostHog Desktop is usage-based with no per-seat license. You pay for what the agents consume, starting from a free monthly tier ($20). Multi-model support (including open source) means no lock-in to a single provider's roadmap or contract. -The forward-looking pitch: the self-driving loop runs on product data, so established companies with lots data are the ones who can put the most work on autopilot (and steer the rest from one place, as a team). +The forward-looking pitch: the loop runs on product data, so the companies with the most data can put the most work on autopilot (and steer the rest from one place, as a team). From e8612016bbd445cca2c6fef125bcdd85c380045e Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Wed, 22 Jul 2026 17:41:52 -0400 Subject: [PATCH 4/5] Refine PostHog Desktop positioning with clearer value prop Generated-By: PostHog Code --- .../handbook/marketing/positioning/desktop.md | 72 +++++++++++++++---- 1 file changed, 57 insertions(+), 15 deletions(-) diff --git a/contents/handbook/marketing/positioning/desktop.md b/contents/handbook/marketing/positioning/desktop.md index 008e4779cdd8..b5e343b3e2b5 100644 --- a/contents/handbook/marketing/positioning/desktop.md +++ b/contents/handbook/marketing/positioning/desktop.md @@ -8,31 +8,40 @@ showTitle: true ## Elevator pitch -PostHog makes your product self-driving: agents work off your product's own context (events, errors, session replays) to find real problems, fix them, and open PRs without being prompted. PostHog Desktop is the product editor where you and your team run that loop together, steering a whole fleet of agents at once. Because the context is already there, the PRs are grounded in how your product actually behaves, not the generic slop from an agent that's only seen your code. +PostHog Desktop is a product editor for product builders. Context, knowing what's actually happening in your product, is what separates a fix that works from one that just deploys. That context (analytics, session replay, error tracking, experiments, and feature flags) already lives in PostHog, a layer above the usual devtools, so you and your agents just think about what to ship. Usage data in, pull requests out, with your whole team steering that work together from a multiplayer interface. + +## Self-driving, and where Desktop fits (vs web, Slack, and MCP) + +The self-driving loop runs anywhere PostHog does, and each interface is a different way to use it. Desktop is the one built for actively building. The other surfaces are for reviewing the loop, or embedding it in tools you already have. + +- **PostHog Web** is the full app in your browser: review agent work in the Inbox and query with PostHog AI. +- **PostHog Slack** brings the loop to you: digests, alerts, and quick questions in a thread. +- **PostHog MCP / CLI** pipes PostHog's context into the agent you already use (Claude Code, Cursor). +- **PostHog Desktop** is a workbench for building new features, shipping improvements, and steering agents with your team. ## The unique belief (in terms of PostHog Desktop) -Agents write most of the code now, but someone still has to hand them a task. That's what a product editor does, and it only works if it can see your product data. +Agents write most of the code now, but someone still has to hand them a task, and review the changes. That's what a product editor does, and it only works if it can see your product data. -The old way to build with agents: one engineer, one agent (maybe loads if you're savvy), alone, working locally from whatever's in their head. Desktop is the new way: your whole team steers a fleet of cloud agents from one shared place, and the work comes straight from your real product data (events, errors, replays, and signals that show what's broken or missing). +The old way to build with agents: one engineer prompting one coding agent (a few if they're savvy), alone, working locally from whatever's in their head. Desktop is the new way: your whole team steers a fleet of agents from one shared space, and context acts as fuel to build better products. ## Who this is for -The primary audience is AI-pilled software teams at engineering-led companies. Adoption starts bottom-up, the way PostHog always wins: an engineer connects a repo, turns on signals, and the first fixes show up within minutes. +AI-pilled software teams at engineering-led companies. Adoption starts bottom-up (the way PostHog always wins) with one engineer connecting a repo. | Persona | Fit | Why | | --- | --- | --- | -| **Founding team** | Strong | Five people can now cover the product surface of a company 10x their size. The loop lets you keep the founder instinct (fix every papercut today) long after you'd normally have run out of hands. | -| **Startup** | Strong | You've got PMF and a backlog of small fixes nobody has time for. Agents clear it without another hire, and your product data keeps every fix aimed at what users actually hit. | -| **Scaleup** | Strong | Multiple teams already running their own coding agents that share no context. Desktop gives them one shared loop instead of a dozen disconnected ones. | -| **Enterprise** | Good, with caveats | More data, more signal, but also more noise, and a bigger blast radius when an agent ships into a huge multi-team codebase. Add the org politics and it's a harder sell, unless they already act like a compound startup. | - -Desktop fits best for teams with a real product and real users (that's the fuel the whole thing runs on). It's built for engineers, but anyone in build mode gets value: PMs, marketers, and pesky execs trying to steer the roadmap. +| **Founding team** | Strong | Five people with agents can outship a company 10x their size. The self-driving loop hones the founder instinct (obsess over details), and Desktop gives structure to how small teams collaborate. | +| **Startup** | Strong | They've got PMF and a backlog of small fixes nobody has time for. Agents clear it without another hire, and the self-driving loop gets stronger the more context they generate, since PostHog's own tools instrument that context automatically. | +| **Scaleup** | Strong | The product surface has grown past what any one team can watch closely, and at this revenue scale, a fraction of a percent of conversion or retention is real money. Desktop puts a fleet of agents on that surface continuously and measures every fix against the metric that matters, so small wins compound into real growth. | +| **Enterprise** | Good, with caveats | More data means more signal, but also more noise, and a bigger blast radius when an agent ships into a huge, complex codebase. Add the org politics and it's a harder sell, unless they already act like a compound startup. | ### Who this isn't for - Teams who haven't shipped a product to real users. No product data means no signals to act on. -- Non-technical builders without a repo to point at (using Lovable, Replit, and other no-code platforms). +- Non-technical builders\* without a repo to point at (using Lovable, Replit, and other no-code platforms). + +*\*Desktop is built for engineers, but adoption across a product org is expected: PMs, marketers, pesky execs trying to steer the roadmap, basically anyone in build mode can benefit.* ## Messaging @@ -113,9 +122,9 @@ Desktop fits best for teams with a real product and real users (that's the fuel ### "Why pay usage when my Anthropic subscription is subsidized?" -**What they're really saying:** Inference feels free right now. Anything metered next to a flat, subsidized sub looks expensive. +**What they're really saying:** Inference feels free right now, and anything metered next to a flat, subsidized sub looks expensive, especially if the token budget or the procurement process is already tight. -**Answer:** A lot of the work doesn't need a frontier model. PostHog runs multiple models, including open-source ones that are getting good enough to handle plenty of tasks for a fraction of the price. You're not locked to one subscription that's subsidized today and will probably be repriced tomorrow. +**Answer:** A lot of the work doesn't need a frontier model. PostHog runs multiple models, including open-source ones that are getting good enough to handle plenty of tasks for a fraction of the price. You're not locked to one subscription that's subsidized today and will probably be repriced tomorrow. If budget's genuinely tight, start with one scout or signal source, cap the spend, and expand once it's paying for itself. *When they push on bill predictability (a fair worry) point at billing limits and per-tool caps. Don't argue that usage-based pricing is painless; argue it's honest.* @@ -123,6 +132,12 @@ Desktop fits best for teams with a real product and real users (that's the fuel **Answer:** Fair question, but you're not betting on PostHog being a great engineer. The code is written by Claude Code and Codex, the same models you'd use anyway. What PostHog adds is the safety net around them: every change ships behind a flag, gets measured against real user behavior, and doesn't reach everyone until the numbers say it's safe. If something regresses, you kill it with a flag, no redeploy or revert. You still review the PRs and set the CI rules the agents follow. That's more scrutiny than most teams put on their hand-written code, and it's exactly how we ship PostHog itself. +### "Our codebase is legacy, huge, or on a stack agents don't know well. Will this even work?" + +**What they're really saying:** I've seen agents choke on codebases like mine, and I don't want to find out the hard way. + +**Answer:** Fair, and it's not one-size-fits-all. Multi-model support means you can point the harder or more unusual parts of your codebase at whichever model handles them best. Start scouts where your data already shows a real problem, since that's usually the highest-value fix, not necessarily the gnarliest legacy code. And you choose which repos to connect, so anything too risky to hand an agent yet just doesn't get connected. + ### "We already have an established stack. Why consolidate?" **What they're really saying:** Switching cost is enormous, and "all-in-one" has historically meant "mediocre at everything." @@ -131,9 +146,9 @@ Desktop fits best for teams with a real product and real users (that's the fuel ### "I don't trust agents to ship. We review every PR by hand." -**What they're really saying:** The 2030 story is ahead of my org. Don't sell me the destination. +**What they're really saying:** The 2030 story is ahead of my org, whether that's general AI skepticism or just not having the bandwidth to review more PRs right now. Don't sell me the destination. -**Answer:** No problem, most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. +**Answer:** No problem, most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. If review bandwidth is the real constraint, start with scouts and signals as alerts only, no PRs, until you're ready to act on them. ### "It's still beta, and the multiplayer stuff sounds early." @@ -141,6 +156,33 @@ Desktop fits best for teams with a real product and real users (that's the fuel **Answer:** It's a WIP, and we'd rather say so than oversell. The core coding primitives (tasks, the Command Center, multi-model support, MCP) are solid, and they're what we use to build PostHog Desktop itself. Channels, canvases, and channel memory are in alpha and changing shape weekly. +## How to sell it (the ramp) + +Don't lead with "self-driving products" as if everyone's ready for it. Most teams need to see concrete value first, then arrive at autonomy as their own idea. + +1. **SKU selling:** "Do you want error tracking?" (too basic, nobody's inspired) +2. **Use-case selling:** "I see errors causing drop-off in your replays, here's how to surface them" +3. **Value selling:** "Let's look at your conversion rate and a plan to raise it, with error tracking, replay, and A/B tests working as one thing" +4. **Vision selling:** "Your product can be self-driving, come on this journey with us" + +It's a stepped process. You can't jump straight to "stop reviewing your code, AI-slop everything." A sensible ramp: turn on session replay, add Replay Vision, then scouts and signals as alerts only (no PRs yet). That shows value and makes continuing the customer's own idea, so the pain point bubbles up naturally: they'll want to connect their repo themselves. + +For a good customer, getting to a meaningful level of autonomy is probably a year-long process. Start where they are: + +- **More basic customers:** error tracking and session replay to bubble up basic issues +- **More advanced customers:** scouts slurping data, surfacing PRs and recommendations to act on + +### The progression + +1. **Identify issues** (error tracking, session replay) +2. **Surface useful patterns** (product analytics, web analytics, AI observability) +3. **Recommend actions** (signals, scouts) +4. **Validate and measure** (feature flags, experiments, PostHog AI to check whether a change worked) +5. **Generate fixes** (self-driving via PostHog Desktop, Slack app, and MCP) +6. **Automate more over time** + +Sell concrete value first (Replay Vision, error tracking), then surface self-driving as a signal of AI readiness. That order avoids churn risk from pushing a product that isn't a fit yet. + ## Selling to enterprise PostHog Desktop is usage-based with no per-seat license. You pay for what the agents consume, starting from a free monthly tier ($20). Multi-model support (including open source) means no lock-in to a single provider's roadmap or contract. From 623ae42c20c34153656e951ab1c2e340477505e1 Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Wed, 22 Jul 2026 18:33:02 -0400 Subject: [PATCH 5/5] human rewrite --- .../handbook/marketing/positioning/desktop.md | 105 ++++++------------ 1 file changed, 36 insertions(+), 69 deletions(-) diff --git a/contents/handbook/marketing/positioning/desktop.md b/contents/handbook/marketing/positioning/desktop.md index b5e343b3e2b5..2ef227dbe046 100644 --- a/contents/handbook/marketing/positioning/desktop.md +++ b/contents/handbook/marketing/positioning/desktop.md @@ -45,40 +45,41 @@ AI-pilled software teams at engineering-led companies. Adoption starts bottom-up ## Messaging -### Message 1: Real usage catches what review can't +### Message 1: Ship like a team 10x your size -**Problem:** Code review catches bugs in the code. It can't catch a change that works exactly as written but makes things worse for real users. That only shows up once real people use it in production. +**Problem:** Midjourney hit $200M in revenue with 40 people. Coding agents make that kind of leverage possible, but only up to a point: one person can only track so many agents at once, and when everyone on the team runs their own separately, none of that work compounds. -**Solution:** In PostHog Desktop, agent-shipped changes go out behind a feature flag before they reach everyone. When a change is worth measuring, it's checked against a metric you actually care about, so you find out whether it helped or hurt real users, not just whether it deployed. If the numbers move the right way, it stays. If they don't, the agent fixes it or rolls it back. +**Solution:** Desktop puts a fleet of agents in one shared workspace, so a few people can track and steer all of it together. That's how a small team outships one 10x its size, without losing the attention to detail that speed usually costs. **Supporting features:** -- Feature flags wrap agent-shipped changes by default, before they reach everyone -- Experiments measure the change against the metric that matters, not just "did it deploy" -- Scouts watch your product on a schedule and open a PR when they find something worth fixing -- Every fix gets checked against your real events, errors, and session replays, not a hunch +- Command Center: run multiple agents at once, each on its own task, local, in a worktree, or in the cloud +- Multi-model: pick Claude Code or Codex, plus the model and reasoning effort, per task +- Channels: a shared space for a team's agent work, with memory that persists across sessions *(alpha)* +- Canvases: generate a dashboard, report, or internal tool from your real data model *(alpha)* -### Message 2: Your product gets better while you're not looking +### Message 2: Agents check their own work -**Problem:** Every team has a long tail of work that's real but not urgent. Papercuts compete for the same hours as the big bets, and the big bets usually win the argument. +**Problem:** Agents are shipping far more changes than your team used to. Code review can tell you the diff looks right, but not whether the change did something meaningful (and no one has time to set that up for every agent PR). -**Solution:** PostHog agents watch that long tail around the clock and turn what they find into shipped fixes. Triage doesn't need a human, so the boring stuff gets handled while you sleep, and the better your instrumentation, the sharper the tasks the agents pick up. +**Solution:** In PostHog Desktop, agents don't just write the fix, they flag it and measure it too. When a change is worth verifying, it ships behind a feature flag and gets checked against a metric you care about before it rolls out any further. **Supporting features:** -- Handles the long tail of polish (papercuts, small fixes, instrumentation, cleanup, docs, edge cases) -- No prompt required: Signals and Scouts generate reports that turn into PRs -- Frees your best people for the work that needs judgment (architecture, big bets, and the problems only a human notices out in the real world) +- Feature flags: agents wrap riskier changes in a flag before rolling them out +- Experiments: agents scaffold an A/B test tied to a metric +- Track events: agents instrument the events needed to measure whether a change worked +- Track errors: agents capture exceptions and stack traces to catch regressions fast -### Message 3: Humans and agents building together +### Message 3: Your product gets better while you're not looking -**Problem:** Midjourney did $200M in revenue with 40 people. We'll see a lot more of that. Agents cracked the writing-code half. They didn't touch the managing-it-all half. More changes shipped means more surface for the same small team to review, measure, and catch when something goes sideways. +**Problem:** Every team has a backlog of small, real bugs that's been sitting for months. None of them are ever quite bad enough to bump the sprint, so they don't get fixed. -**Solution:** That's the half Desktop is built for. A few people steering a fleet of agents from one shared workspace can outship a team 10x their size, and keep the attention to detail that kind of speed usually kills. It's founder mode that doesn't fall apart as you grow. +**Solution:** PostHog agents work that backlog continuously, so it gets cleared without pulling anyone off what they're already doing. They watch for it, triage it, and ship the fix. No human has to notice the problem first. **Supporting features:** -- Parallel agent orchestration, multi-model: run several agents at once, each on the model that fits the task -- Channels: a shared space where your team's agent work lives, with memory that sticks around between sessions *(alpha)* -- Canvases: ask for a dashboard, report, or internal tool and get it built on your real data model *(alpha)* -- No markup: you pay the token costs, not a subscription stacked on top +- Scouts run on a schedule and open a PR when they find something worth fixing, no prompt required +- Signals draw from errors, support tickets, session replays, GitHub issues, Linear, and Zendesk +- Inbox ranks incoming reports and PRs by importance and impact +- Usage-based pricing: 100 credits = $1, no markup, with a $20/month free tier and a $50 default billing limit ## Battle cards @@ -118,31 +119,23 @@ AI-pilled software teams at engineering-led companies. Adoption starts bottom-up **What they're really saying:** I live in Claude Code or Cursor. My workflow is settled. -**Answer:** Fair, and you can. Our MCP is first-class, and for a lot of teams it's the main way they use PostHog. Inbox and signals live in the web app too, so you don't need Desktop to review work. Desktop is for a different job: running many agents at once, with your teammates, in one place. +**Answer:** Our MCP is awesome, and for a lot of teams it's the main way they use PostHog. But a terminal only shows you one agent at a time, so if you're running more than a couple of tasks, or want your team to see what's in flight without a status update, MCP might limit you. ### "Why pay usage when my Anthropic subscription is subsidized?" -**What they're really saying:** Inference feels free right now, and anything metered next to a flat, subsidized sub looks expensive, especially if the token budget or the procurement process is already tight. +**What they're really saying:** Inference feels free right now, and anything metered next to a flat, subsidized sub looks expensive (especially if the token budget is tight or the procurement process is slow). -**Answer:** A lot of the work doesn't need a frontier model. PostHog runs multiple models, including open-source ones that are getting good enough to handle plenty of tasks for a fraction of the price. You're not locked to one subscription that's subsidized today and will probably be repriced tomorrow. If budget's genuinely tight, start with one scout or signal source, cap the spend, and expand once it's paying for itself. +**Answer:** A lot of the work you're doing doesn't need a frontier model. PostHog runs multiple models, including open-source ones that are getting good enough to handle plenty of tasks for a fraction of the price. You're not locked to one subscription that's subsidized today and will probably be repriced tomorrow. If budget's genuinely tight, start with one task or one repo connected, cap the spend, and expand once it's paying for itself. -*When they push on bill predictability (a fair worry) point at billing limits and per-tool caps. Don't argue that usage-based pricing is painless; argue it's honest.* +### "Why would I trust PostHog to ship code? You started as an analytics tool." -### "Why would I trust PostHog to ship code? You're an analytics company." - -**Answer:** Fair question, but you're not betting on PostHog being a great engineer. The code is written by Claude Code and Codex, the same models you'd use anyway. What PostHog adds is the safety net around them: every change ships behind a flag, gets measured against real user behavior, and doesn't reach everyone until the numbers say it's safe. If something regresses, you kill it with a flag, no redeploy or revert. You still review the PRs and set the CI rules the agents follow. That's more scrutiny than most teams put on their hand-written code, and it's exactly how we ship PostHog itself. +**Answer:** The code is written by the same models you'd use anyway. What PostHog adds is everything around it: error tracking to catch regressions, session replay to see exactly what happened, experiments to prove a change is a net positive, flags to control the rollout, plus the memory, context, and data agents need to build the next change with less prompting. ### "Our codebase is legacy, huge, or on a stack agents don't know well. Will this even work?" -**What they're really saying:** I've seen agents choke on codebases like mine, and I don't want to find out the hard way. - -**Answer:** Fair, and it's not one-size-fits-all. Multi-model support means you can point the harder or more unusual parts of your codebase at whichever model handles them best. Start scouts where your data already shows a real problem, since that's usually the highest-value fix, not necessarily the gnarliest legacy code. And you choose which repos to connect, so anything too risky to hand an agent yet just doesn't get connected. - -### "We already have an established stack. Why consolidate?" - -**What they're really saying:** Switching cost is enormous, and "all-in-one" has historically meant "mediocre at everything." +**What they're really saying:** I've seen agents choke on repos like mine. -**Answer:** When an agent ships behind a flag, the flag system has to know which sessions saw it, replay has to know which errors those sessions hit, and the experiment has to tie it all back to the same user, automatically, in seconds, or the rollout stalls. Across separate vendors that's glue code you maintain forever, humans copy-pasting between tools, or context falling through the cracks. One system of record is what keeps the loop running at all. +**Answer:** Honestly, worry less than you think. Models have gotten very good at working in legacy and unusual codebases, and if part of yours is still tougher, multi-model support means you can point it at whichever model handles it best. And worst case, it's just code: you review the PR before it merges, and if something still gets through, you flag it off or revert. Nothing here is one-way. ### "I don't trust agents to ship. We review every PR by hand." @@ -150,41 +143,15 @@ AI-pilled software teams at engineering-led companies. Adoption starts bottom-up **Answer:** No problem, most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. If review bandwidth is the real constraint, start with scouts and signals as alerts only, no PRs, until you're ready to act on them. -### "It's still beta, and the multiplayer stuff sounds early." - -**What they're really saying:** I don't want to bet a workflow on something half-built. - -**Answer:** It's a WIP, and we'd rather say so than oversell. The core coding primitives (tasks, the Command Center, multi-model support, MCP) are solid, and they're what we use to build PostHog Desktop itself. Channels, canvases, and channel memory are in alpha and changing shape weekly. - -## How to sell it (the ramp) - -Don't lead with "self-driving products" as if everyone's ready for it. Most teams need to see concrete value first, then arrive at autonomy as their own idea. - -1. **SKU selling:** "Do you want error tracking?" (too basic, nobody's inspired) -2. **Use-case selling:** "I see errors causing drop-off in your replays, here's how to surface them" -3. **Value selling:** "Let's look at your conversion rate and a plan to raise it, with error tracking, replay, and A/B tests working as one thing" -4. **Vision selling:** "Your product can be self-driving, come on this journey with us" - -It's a stepped process. You can't jump straight to "stop reviewing your code, AI-slop everything." A sensible ramp: turn on session replay, add Replay Vision, then scouts and signals as alerts only (no PRs yet). That shows value and makes continuing the customer's own idea, so the pain point bubbles up naturally: they'll want to connect their repo themselves. - -For a good customer, getting to a meaningful level of autonomy is probably a year-long process. Start where they are: - -- **More basic customers:** error tracking and session replay to bubble up basic issues -- **More advanced customers:** scouts slurping data, surfacing PRs and recommendations to act on - -### The progression - -1. **Identify issues** (error tracking, session replay) -2. **Surface useful patterns** (product analytics, web analytics, AI observability) -3. **Recommend actions** (signals, scouts) -4. **Validate and measure** (feature flags, experiments, PostHog AI to check whether a change worked) -5. **Generate fixes** (self-driving via PostHog Desktop, Slack app, and MCP) -6. **Automate more over time** +## How to sell it -Sell concrete value first (Replay Vision, error tracking), then surface self-driving as a signal of AI readiness. That order avoids churn risk from pushing a product that isn't a fit yet. +Find out which tool a team already has running (error tracking, replay, analytics), and pitch Desktop as the next step from there. -## Selling to enterprise +Don't lead with "connect your repo and let agents ship code" as if everyone's ready for that. Most teams need to see real findings first, then ease into self-driving. For example: -PostHog Desktop is usage-based with no per-seat license. You pay for what the agents consume, starting from a free monthly tier ($20). Multi-model support (including open source) means no lock-in to a single provider's roadmap or contract. +1. **They're already using at least one PostHog product** (ideally analytics, error tracking, or session replay) so there's real data to work from +2. **Scouts start running** against that data and generating reports, still entirely in the web app, no Desktop involved yet +3. **The coding part happens in Desktop**: once a report is worth acting on, that's the natural point to connect a repo and let an agent write the fix +4. **Usage expands from there**: more repos, more agents, more of the team shipping through Desktop +5. **The Slack app is often in the mix too**, surfacing the same findings and PRs wherever the team already works -The forward-looking pitch: the loop runs on product data, so the companies with the most data can put the most work on autopilot (and steer the rest from one place, as a team).