Post

We have built 10 different AI products at PostHog like PostHog AI, our Wizard, Replay Vision, Scouts, and more. Combined, they are used by nearly 100k people every month. Along the way, we’ve learned a lot about building them, what works, and what doesn’t. Here are the 38 most important lessons:

1. AI can make your product worse. It can be slow and unreliable, or solve a problem nobody has (like chatting with your docs, any AI can do this). Just because it’s AI does not mean it’s worth building.

2. Consider whether you need to build AI at all. It’s often better to build for AI first, like an MCP server. These are easier to build and maintain. 5x more people use our MCP server daily than PostHog AI.

3. Look for jobs to be done, not demos. The best opportunities for AI are tasks that take 30+ seconds, use language or interfaces users don’t know (like SQL), or tasks users repeat 20+ times.

4. Onboarding is a great first target. Our AI install wizard does two hours of work in ~8 minutes. Those who use it convert to paid 5x more often and activate 2x faster.

5. Rather than asking “how do we add AI to this?” ask “what is the agent-first version of this?” Doing this forces you to rethink the jobs to be done for an agent-first future and helps you avoid being disrupted by an AI-native competitor.

6. Building 2030-shaped products may require you to start fresh and break from years of cumulative UI and assumptions which are no longer valid or relevant.

7. Watch for customers rebuilding your product with AI. This reveals what features they actually want. When one of our largest customers built their own prototype of “PostHog 2.0” with our MCP and Claude Code, we knew we needed to add more customizable “canvas” artifacts to PostHog.

8. Validate AI bets like you would new products. Write down how it will be judged and how much runway it gets. Ask how disappointed your team would be to lose it (the PMF survey). We did this for one product and only 23% said they would be very disappointed. Bad results, but useful.

9. Write down how your product loses to an AI-native threat and then fund your version of the attacker. Even the best support product loses to one where AI answers all the tickets for example, which is probably why Intercom pivoted so hard into Fin.

0 reposts0 likes

10. Answer the question: How does this beat Claude? It’s what people default to. Your moat is context: your product’s functionality, your users’ data, and the tools and skills you’ve built.

11. Your harness is not your moat. PostHog AI went through three of them in a year. We now have MCP as the canonical interface and let people pick their own harness. Don’t spend innovation points here.

12. Don’t build an assistant. Clippy is 90’s tech. Assistants are what you build when intelligence sits next to your product. Systems are what you build when intelligence becomes part of it. Build those instead.

13. Focus on building shared AI infrastructure. Make prompts, streaming, evals, tasks, and analytics primitives teams can extend and build with. Pick a consistent UX pattern to avoid death by a thousand widgets and then get out of people’s way. Product teams know their users best, not the AI team.