Some think the answer depends on how good the model is – i.e. when models get better, you can trust them to do more. But trusting your agents just because the models got smarter is like skipping your seatbelt because you got a nicer car.

The real answer has nothing to do with the model, and everything to do with the task. You need to build a mental model for when to delegate and how much, which you can then adapt.

Here’s a simple guide to maximizing agent autonomy, so you can ship fast without breaking things.

The two factors that set the ceiling

You need to ask yourself two questions first:

1. Is it easy to check the agent’s work?

To run safely on their own, agents need immediate feedback when they’re wrong. This is possible for most code with deterministic checks, like unit and integration tests. But subjective tasks, like renaming a parameter for clarity, are harder without human taste and judgment.

2. Is it cheap to undo an agent’s mistake?

Just like in traditional software engineering, if you want to trust an agent run without supervision, you need a guaranteed Ctrl+Z for worst case scenarios. That’s why StampHog, our PR approval agent, routes anything that contains deny-list keywords to a human.

Together, these two factors1 point you to one of four levels for any task:

• Level 0: Agent as assistant. For tasks that are hard to check and hard to undo. Necessary when dealing with tricky and sensitive code.

• Level 1: Human-in-the-loop. For tasks that are hard to check and easy to undo. Usually when you need subjective evaluation.

• Level 2: Agent delegation. For tasks that are easy to check and hard to undo. The default ceiling for most dev work today.

• Level 3: Self-driving mode. For tasks that are easy to check and easy to undo. Everything is accelerating towards this.

You can map these four levels to a very simple decision tree, which you can apply to any task:

This helps you make decisions about how much to delegate to your agents, but you still can engineer your pipeline to enable higher autonomy for any specific task.

Level 0: Agent as assistant

When the work is hard to check + costly to undo

This is the lowest level of agent autonomy. Think asking ChatGPT for advice, or auto-complete in Cursor, just like the good ol’ days of 2024.

But just because it’s old-fashioned doesn’t mean it’s bad; this mode is ideal when dealing with tricky problems in sensitive code surfaces.

For example, when Dylan updated our feature flag engine to support generic property targeting last year, he had to migrate an assumption that was indirectly baked into every feature flag at PostHog.

This would have been hard for agents to check deterministically since it wasn’t possible to grep for. The update also had a huge blast radius since it touched live customer flags, API response shapes, and reason-scoring functions.

How to level up from here

Break the task down. Small pieces make it obvious where delegation is safe or not. Dylan handed off less critical work, like propagating the new targeting logic across our JavaScript, PHP, Ruby, and Flutter SDKs, to agents while doing the riskier core migration by hand.

Level 1: Human-in-the-loop

When the work is hard to check + cheap to undo

This level of agent autonomy is common for tasks that need subjective evaluation since it’s hard to teach agents taste and judgment (for now, at least).

Human-in-the-loop tasks are considered cheap to undo since the code stays in draft mode and won’t get merged until it’s verified by a human. An undo just means kicking off another iteration.

This code readability refactor by Thomas was mostly done by hand, but it's a good example of something an agent wouldn't know how to grade. It was just a few lines that made it easier for humans to understand – adding comments, grouping actions, swapping strings for an enum – and didn't introduce any breaking changes.

How to level up from here

• Use LLM-as-judge. This is how most people are building their agentic code review systems. As models continue to improve, more tasks that require human judgment can be checked with LLMs.

• Define a scoped, measurable goal. Success metrics or contracts can work as a proxy for a subjective evaluation. For example, you could instruct a system to experiment with landing page copy until a variant reaches 3% conversion.

• Write custom skills. This helps agents produce work that reliably fits your standards, conventions, and taste with less steering required. For example, many developers write custom code review skills to follow team-specific standards.

Level 2: Agent delegation

When the work is easy to check + costly to undo

This is the level that most developer tasks are today. An agent writes code that can be tested deterministically, but the final act of merging it is gated behind a final safety check.

When Robbie rewrote our SQL parser in Rust from scratch, he barely read the code since he had a machine oracle to check the work. But since the parser touches every query at PostHog, the agent’s work was gated behind multiple safety checks: shadow mode in production, then a staged cutover.

How to level up from here

Enforce policies and guardrails with code. Most people default to gating Level 2 tasks behind a human (a.k.a., themselves), but this habit turns you into your own bottleneck. Instead, encode as many of your guardrails directly into your pipeline with policies like dry-running by default, scoping credentials, and putting changes behind feature flags.

Level 3: Self-driving mode

When the work is easy to check + cheap to undo

There aren’t very many tasks in this category yet – just smaller ones like dependency bumps, lint fixes, adding test coverage to existing code. But the category is growing quickly, especially with long-running agents, goal-driven loops, and more complex orchestration.

We’re going all-in at PostHog on making self-driving mode a reality for builders. Last month, for example, we launched Scouts – agents that run on a schedule, investigate signals from product data, and draft a PR based on what they find.

How to level up from here

• Train domain-specific models. Much of the next wave of tooling will be about improving verification tasks that are difficult for LLMs today. One obvious path is purpose-trained models that know what “good” looks like in a specific domain, which is why we’re training our own AI models at PostHog.

• Build expert-level context banks. A lack of agent autonomy is often just due to a context deficit. We learned firsthand from engineering our context layer for the PostHog Wizard that closing this gap with structured and fresh knowledge is one of the highest-leverage things you can build for reliable agents.

• Design clear signals for scouts. The bottleneck for long-running agents is going to be whether they know when there’s work worth doing, and how to distinguish valid signals from random noise.

Words by Jina Yoon, who writes these newsletters at Level 0.

🕵️ Have your agents talk to our agents

• Technical Customer Success Manager - Americas

• Technical Customer Success Manager - EMEA

• BDR Team Lead

• Revenue Ops Manager (sales focused)

🔺 More ways to level up

• Agentic Autonomy Levels – Addy Osmani

• Repositioning PostHog – Charles Cook

• How Cerebras Built Its Enterprise Knowledge Base – Isaac Tai, Daniel Kim, Mike Gao

• What is a context warehouse? – Lizzie Epton

• The new rules of context engineering for Claude 5 models – Thariq Shihipar

Many of the conversations and decisions about what we’re building now are impacted by this. More and more, we’re aiming towards building “2030-shaped software.”

This is a vague aspiration and “agent-first software” isn’t much better. But, while we can’t predict the future, we can share how we’re thinking about the problem.

Human and agent work is split

The current era of software is designed for humans to do all the work, but in 2030, agents will be the ones doing. Agents have shown that they can do the obvious stuff themselves. What does this leave humans to do?

1. Judging and deciding. Humans will approve, prioritize, choose direction, and resolve ambiguity.

2. Understanding and trusting. Humans will evaluate whether it worked, if it’s safe, and what’s changed.

“Doing” UI like buttons and forms are going away. They will be replaced with UI that supports the two types of work above. This helps optimize humans’ limited time and energy by pointing them where their input actually matters.

Product infrastructure is agent-first

If a human can do something with your product, agents should be able to do it too. This means complete APIs, an MCP server, tools, and permissions. Build for agents as a primary surface, not an afterthought.

Missing capabilities are a failure mode. Say you ask an agent to set up an A/B test. It creates the feature flag, builds the insight, wires up the events, and stops because you never exposed a tool to create the experiment. It now has to ask you to do that part which defeats the purpose of using agents.

This doesn’t mean that tools are all you need. It won’t be enough to just let Claude use your product on its own. Relying entirely on a model provider is too much risk. Building your own harness lets you guarantee quality, protect your brand, and make continuous improvements. Even OpenAI notes that agents struggle not because they are incapable, but because they lack “the tools, abstractions, and internal structure required to make progress toward high-level goals.”

Context is what makes your agent special. The model is the same for everyone, your moat is the source code, usage data, customer data, and product skills you feed it. This means context engineering, creating pipelines and flows to get fresh, valuable context to the agents when they need it.

Chat is the front door, generative UI inside

People like to complain about chat as an interface, but we think it's a good one. There's a reason why it's still the primary interface to work with agents and companies are doubling down with products like Slack apps – have you tried the PostHog Slack app yet? Telling an agent what's needed and letting it go do it is a powerful interaction method.

But chat isn’t enough because sometimes reading a paragraph is worse than glancing at a chart or flicking a toggle. Text can be too low bandwidth as it’s flexible but linear; a UI is legible but rigid. Generative UI is in between.

Most generative UI will be disposable, but some will become artifacts: outputs worth keeping, sharing, and forking. Examples include reports, documents, code, pull requests, configuration, and even entire apps. All of them are backed by your app's data. Generative UI is how you work with the agent right now; artifacts are what you walk away with.

Build UI when text isn’t enough

Text and generative UI cover much of what a product needs, but not everything. Some jobs will continue to need persistent, purpose-built UIs, like:

• Trust and verification surfaces confirming the agent did what you wanted. Checking work, not doing it.

• Triage and inbox surfaces listing decisions that need a human. Approvals, ambiguous calls, unclosed support tickets.

It's tempting to make your UI agent-first by removing the buttons, forms, and other parts of the UI that power the doing, but this is a half-measure. Most of this new "read-only" UI can be delivered as text by an agent, making it redundant and misaligned with what humans need the UI for.

Take our feature flags page. The jobs to be done are:

• Is my flag rolled out?

• To whom?

• Does it have a payload?

• What type is it?

An agent can answer all these questions in a sentence. You're not verifying the agent's work and there's no decision to be made. You're just checking the flag's state. A 2030 flags page shows how agents change rollouts and previews a pull request to clear up stale flags.

The question to ask is: is a human looking at this for trust and judgement, or to act? If it’s an action, give the agent the capability. If it’s to trust or judgement, build for that specifically.

Be everywhere

Agents don't work like apps. They run on their own, often for a long time. Nobody should have to sit in a browser tab watching them. 2030 products come to their users, no matter if that means desktop, Slack, mobile, email, API, or voice.

These are a shared control plane between humans and agents. Thin clients over a shared backend, so the experience is the same anywhere and the handoff between surfaces is seamless.

This pushes you towards cloud-first. The real bottleneck when working with agents is concurrency and babysitting. Builders want to run many agents at once, point them at a backlog, and refine the output from anywhere. On-device execution can’t do that.

Cloud-first only works if all that infrastructure is excellent. Sandboxes need to be rock solid: fast repo imaging, snappy execution, no crashing or freezing. Your app is ubiquitous, your infrastructure invisible.

Building 2030-shaped software now

2030 software requires a lot of changes, and 2026 is not 2030. As a company with multiple successful products and thousands of users relying on us, the hard part is getting there while having a real product and revenue to support. Do we retrofit or start fresh?

Retrofitting maximizes reach, that’s where our users already are, but we inherit all our 2026 patterns. Every change draws complaints from users attached to the way things work today (not to mention the tech debt).

Starting fresh means a clean break with years of cumulative UI built on assumptions that might not be valid or relevant. The people who opt in are early adopters who want to co-create the future with us. They don’t complain about what’s missing, they tell us what they need. The cost of this is convincing existing users to switch (eventually) and splitting focus with our existing products while we do.

We’re cheating a bit and going semi-fresh, using our existing data and infra on a new surface. We’re expanding our existing PostHog Desktop app to fit our 2030 vision first before migrating other surfaces. It’s already where the best agents live, it draws exactly the early adopters we want, and it’s simple enough to be a genuine blank slate.

Without this change, we risk building 2026-shaped software with AI bolted on. We answer “how do we add AI to this” rather than “what is the agent-first version of this?” We can’t predict 2030, but don’t need to be right about the details to build in the right direction. The companies that matter in 2030 will be the ones who started building for it well before they had to.

Words by Ian Vanagas who’s looking forward to 2030 software almost as much as a 2030 World Cup.

📅 2026 blog posts you should read now

• Our session replays are opening their own pull requests - Sara Miteva

• The Future of SaaS Is Agentic - Arjun Kashyap

• Riding Technology Waves - Stay SaaSy

• Own the Outer Loop - Addy Osmani

• Why AI hasn’t replaced software engineers, and won’t - Arvind Narayanan and Sayash Kapoor

💼 Join us on our journey

• AI Research Engineer

• Site Reliability Engineer (Pacific timezone)

• BDR Team Lead

• Context Engineer

• Backend Engineer

We accomplished our original goal

We started Product for Engineers to challenge the idea that engineers only care about code.

We showed that engineers can flex their product muscle, talk to users directly, be opinionated about what to work on, work autonomously to ship features, and figure out if they are successful. The tens of thousands of subscribers we amassed, the rise in popularity of the product engineer role, and 100+ YC startups hiring them now are proof we accomplished this.

Along the way, we learned product engineers care about more than just product. They care about building a successful company and career more broadly. After all, great products come from the people and companies who build them.

Following the advice to “build write something people want,” we wrote about everything from finding a job to scaling a startup to marketing to collaboration.

But every post like this pulled us away from the “product” framing in our name. Helping people build more successful products meant a lot more than just helping engineers do product.

AI changes engineering and the meaning of “engineer”

The other part of our name has also seen huge changes because of AI.

First, people are building AI-powered products and using AI to do so. Last week, PostHog saw 3.5M MCP tool calls, nearly 100K PostHog AI chats, and 40% of experiments created through our MCP. Our AI observability product grew 17x in the last year. Building the best products now requires building for agents, writing loops, and making full use of AI coding tools.

Second, AI has made it possible for anyone to build. The engineeringification of everything is real. Salespeople ship features, product managers fix bugs, marketers build video games. Our posts are relevant to a new group who don’t exclusively label themselves as engineers.

PostHog as a company is changing to reflect this. Beyond building more for AI, our ICP has changed from engineers at high growth startups to the people building products in AI-pilled software teams at any scale. Our newsletter should reflect this change too.

The Product for Engineers brand wasn’t resonating for us or our readers, so we’re changing it and going build mode.

What is build mode?

The tools, tactics, and taste builders need to build successful products, companies, and careers like:

1. How to build AI-native products (and agents) successfully

2. How to leverage AI to build more successful products and careers

3. How to build a successful company, culture, and brand

4. Lessons from the frontlines of doing all of the above at PostHog

build mode is a reflection of what's happening now and what we think matters to builders going forward. Our upcoming posts will cover what we think the future of software looks like, writing agent skills, and an explainer on effort levels.

It turns out that when code is cheap, the product skills we wrote about become even more important. AI enables more people to build and takes them further, faster, but it still needs the guidance, judgement, and taste only you can provide. Build mode aims to help you with this as best as we can.

Go build mode.

Words by Ian Vanagas who will miss our mascot Swolehog.

The naive solution would be for developers to review code faster. The 500 IQ take is for developers to review as little code as possible.

If you need to be involved in every code review, you will always be the bottleneck. Instead, put yourself outside of the code review loop by building a pipeline that delegates tasks to agents.

We asked engineers at PostHog how they’ve been reviewing AI-generated code to keep shipping fast without losing quality.

Here are four workflow changes you can steal (with prompts included) to make your life easier.

1. Make agents review code for you

The number one thing to add, if you haven’t yet, is a way for agents to review code for you.

The goal is to offload the simpler reviews to agents, and flag if something genuinely needs a human.

The key is that the agent that wrote the code can’t be the one that reviews it. Agents are bad at checking their own work since they’re often unaware of their own blind spots.1

For the same reason, it’s better to have multiple agents with different instructions and goals to cover more gaps,2 as well as different models and providers for different reviewers.3

Here’s how one of our engineers, Paul D’Ambra, makes his own custom agent review system work:

1. First, qa-swarm spawns four reviewer agents, each with their own special instructions:

   • qa-team – spawns technical subagents that hunt for security, database, performance, etc.

   • security-audit – probes for vulnerabilities like SQL or prompt injections

   • paul-reviewer – uses Paul’s voice and focuses on observability, rollouts, naming

   • xp-reviewer – applies an Extreme Programming lens to review

2. Then, review-triage sorts those reviews to classify threads into three categories:

   • actionable → gets fixed and pushed

   • nits → get resolved and replied to with a comment

   • ambiguous → escalated and sorted for Paul to work through with the agent later

3. An outer loop iterates up to three times or until no new actionable threads appear.

From there, you can connect this to another loop that shepherds the PR until it’s ready to merge – more on that in the next section.

The takeaway: Save time reviewing code by making agents review each other. This knocks out easier reviews so that only the PRs that really need human attention get flagged.

Steal this

You can check out and copy Paul’s qa-swarm and review-triage skills, or use this prompt to design your own review loop based on his:

Read Paul D'Ambra's qa-swarm skill, plus its sibling review-triage in the same folder, then help me design my own version: https://github.com/pauldambra/dotfiles/blob/main/ai/skills/qa-swarm/SKILL.md

It should take in a single PR, spawn a reviewer panel, triage every finding and existing PR thread into actionable / nit / ambiguous, and keep going until nothing's left but the ambiguous ones flagged for me.  

Interview me about my stack, tooling, available models, and how autonomous it should be — what gets auto-fixed vs. only reported, and what it may post to GitHub — before writing the final SKILL.md, then install it.

That said, these systems can get token expensive:

So if running multiple agents or loops isn’t an option for your team, look for single agent designs like this one by Kun Chen.

2. Delegate PR babysitting to loops

The context switching that comes with agentic coding is exhausting. One easy way to reduce that fatigue is by automating code review-adjacent tasks that don’t need your attention.

For example, babysitting a single PR can involve tedious tasks like monitoring CI, re-running flaky tests, checking notifications for comments, and keeping the branch up to date.

Why waste your most precious resource – your energy – when you can just delegate all of it to a loop?

The takeaway: Reduce context switching and fatigue by delegating simple tasks like PR babysitting to a loop.

Steal this

You can implement your own PR babysitter skill, based on babysit-prs by Phil Haack with the prompt below. (It works best if you run it after creating a review loop skill from the previous section.)

Read https://github.com/haacked/dotfiles/blob/main/ai/skills/babysit-prs/SKILL.md and adapt it for me: same sweep/state design, but it dispatches my own single-PR review skill via a spawned agent per unreviewed PR. 

Before writing SKILL.md, interview me on: which skill it dispatches and where my skills live, my stack/tooling/models, and which extra tasks to include — CI monitoring, branch freshness, flaky-test reruns, lint/format autofix, regenerating drifted artifacts, description sync. 

Ground the interview in  facts you can discover yourself (my open PRs, gh auth, clone layout) rather than asking about them.

3. Add a PR auto-stamper

Fast-moving teams generate a lot of small, low-risk PRs, and every one still needs approval on GitHub (a.k.a., a stamp).

At PostHog, we used to handle this in Slack where you drop your PR in #dev-stamp-exchange and wait for someone to give it a quick approval and react with a stamp emoji. We even built a leaderboard for it.

It worked, but each stamp required another engineer to take themselves out of their flow to approve a change they had little to no context on.

Now, most of those are done by our StampHog agent instead. And in just one quarter, it gives the final stamp on roughly 1 in 3 PRs merged into our main repo.

Our engineers add a stamphog label on their PR in GitHub, and it runs a few safety checks based on:

• PR state. No merge conflicts or changes requested

• Blast radius. Deny-list keywords (auth, secrets, billing, public APIs, etc.)

• Diff size. Under 500 lines and 20 files

• A simple LLM check. For basic showstoppers

If the agent approves, it’ll leave a bare GitHub approval with no line comments.

Otherwise, it refuses or escalates with a 1-2 sentence reason, risk level rating, and next steps. Usually that means routing to a subject matter expert based on CODEOWNERS-soft and git-blame familiarity.

We still use #dev-stamp-exchange when the agent can’t auto-accept or route, but it’s way less active now. Last month, the StampHog agent took care of 1.6K PRs on its own – that’s 1.6K fewer Slack interruptions for our engineers.

The takeaway: Let an agent can take care of low-context PR approvals and routing to reduce distractions. Use deterministic checks to route sensitive code to humans.

Steal this

The code for StampHog is available here. Many of its inner workings are specific to PostHog, so instead of copying it, here's a prompt to start customizing one for your repo based on ours:

Read https://github.com/PostHog/posthog/blob/master/tools/pr-approval-agent/README.md and build the equivalent for the repo at <path>. 

Copy the architecture; preserve its safety invariants exactly (fail closed, never request changes or merge, LLM can tighten gates but never loosen). 

Their deny-list and thresholds are calibrated to their codebase — re-derive for me: mine my git history for high-blast-radius deny candidates and calibrate size/tier ceilings from my merged PRs, then propose the full gate config for my sign-off before writing any code. 

At the same time, ask me whatever you can't derive from the repo — at minimum the CI system and trigger label, escalation routing if there's no CODEOWNERS, and which LLM/SDK to use and how CI gets its credentials. 

Leave the result as uncommitted files on my working tree.

4. Verify by observation, not reasoning

Agents are good at explaining why their code works. The explanation is often convincing... but also wrong.

If you run the code end to end, you’ll frequently find errors the agent never reasoned about, or output that’s just slightly not what you asked for.

That’s why Daniel Visca‘s rule of thumb is observability over reasoning. Don’t accept an argument that the code works when you can watch it work.

The gold standard is something you can observe directly, like sending a real API request and reading the response. If the behavior is in front of you, you don’t have to trust the agent’s rationale at all. But this has a scaling problem since a 3,000-line PR would be challenging to trust and observe.

His approach is to make agents decompose the work. For example, for a large change (like building a metrics pipeline end to end), he instructs the agent to produce a stack of small, single-purpose PRs and then uses Graphite for its “stacking” functionality. This makes each diff independently runnable and observable:

At each step of the stack, you can run a real check and confirm the output matches what you expect. Then, as you merge bottom-up, each layer only builds on behavior that’s already been verified.

This way, early mistakes can’t compound, and when something does break, you’re debugging one small diff instead of the whole change.

As a bonus, this lets StampHog from #3 auto-approve the small and focused PRs. You end up with two different checks: the agent reasoning about the code first, and a human observing its actual behavior.

The takeaway: When you can't trust an agent's reasoning, don't read more code; decompose the change until you can watch each piece run. Observation scales better than review.

Steal this

You can set this up by using Graphite to stack smaller PRs produced by your agents with these instructions:

Split work into a stack of small PRs, each under 400 changed lines and focused on a single change, building only on the PRs below it. 

Every PR must ship with its own tests and end with a way to observe it working directly — a command to run and the output I should expect.

This approach is especially valuable for frontend work since deterministic tests don’t always capture the visual or behavioral functionality you’re looking for.

You can use this prompt to copy the qa-frontend skill Pawel Cebula created for this. It’s a huge timesaver to have an agent run the code and take screenshots and GIFs for you:

Read https://github.com/PostHog/posthog/blob/master/.agents/skills/qa-frontend/SKILL.md and build the equivalent for the repo at <path>. Copy the architecture and preserve every safety invariant it states exactly.

Its file-classification, route-finding, local-stack/login, and evidence-upload rules are calibrated to PostHog — re-derive mine: mine my repo for the diff-pattern → frontend-test-type map, route heuristics, and the "never auto-edit" deny-list (from my high-blast-radius areas). Propose the full config for my sign-off before writing any code.

Ask me whatever you can't derive from the repo — at minimum: which browser MCP to drive, how my local stack starts and on what URL, how the app authenticates locally, and how PR mode checks out PRs and posts comments (platform + CLI/token).

Leave the result as uncommitted files on my working tree.

Words by Jina Yoon who was, admittedly, the bottleneck for this post.

🫪 Blogs worth human review

• Why we rebuilt our data warehouse and how it unlocks self-driving products – Eric Duong

• Agentic Failure Modes – Dylan Martin

• Better Models: Worse Tools – Armin Ronacher

• Agentic Code Review – Addy Osmani

• Understanding is the new bottleneck – Geoffrey Litt

🤖 We can’t automate these yet

• AI Research Engineer

• Technical Customer Success Manager - Americas

• Context Engineer

• Revenue Ops Manager (sales focused)

• Developer who connects with other developers

A year ago, Josh Snyder, then on the growth team, binged session recordings of users trying to onboard to PostHog. The long list of failure modes was painful.

But it jolted an idea loose: what if AI could handle the onboarding for you? So we built an AI onboarding wizard.

The PostHog Wizard is an AI agent that fully integrates PostHog into any codebase with a single CLI command. No manual SDK installation, no docs spelunking. Just npx @posthog/wizard.

Early versions were primitive, but today’s wizard completes two hours of work in just 8 minutes. It’s a genuinely magical experience. People LOVE it.

Building it taught us some important lessons about how to build agents people genuinely love (with great ROI, too!), starting with the most important lesson of all...

Lesson #1: Reasoning isn’t the bottleneck

We initially tried solving everything at the agent layer – better progressive disclosure techniques, multi-step planning, subagents, pruning, compaction – but the gains were marginal.

The biggest improvements came from simply giving the agent more context. A lot more. That told us something about the shape of the problem.

With 20+ products, 17+ SDKs, and 25+ frameworks, there are thousands of ways to integrate PostHog, and each setup requires some piece of technical trivia, like:

• Where should PostHog initialize? Client, server, both, or serverless?

• How do events get sent? Direct, or through a reverse proxy?

• How are pages rendered? SSR or SSG? RSC?

The agent routinely got these details wrong because it was operating in a context deficit. So we started engineering the context that powered it.

(The wizard is open source. You should steal it!)

Our Docs team of technical writers became a Docs & Wizard team of context engineers – same people, different mission. Their job became building a library of context for agents, and a delivery system that made it accessible.

The result was a company-wide context layer that could pull from everything we maintained: docs, source code, SDK references, example apps, anything that could widen the scope of what the agent could handle.

Remember: If your agent is tackling a high-variance problem like onboarding, reasoning usually isn’t the bottleneck. Context supply is.

Lesson #2: Don’t hardcode knowledge

The naive way to supply more context (which we did) was to hardcode it into its harness.

In v1, the wizard’s context and code were locked together, so the two couldn’t scale independently. Supporting a new framework or product in the wizard meant shipping a whole new agent.

Our answer was the context mill, an assembly-line service for turning scattered PostHog knowledge into portable, versioned zip files that agents can consume remotely.

Here’s how the context mill works:

1. It pulls context from our docs, source code, Open API specs, example apps, and other maintained sources.

2. It assembles the source material into a collection of zip files and cuts a versioned GitHub release.

3. It delivers each one as a skill or registers it with an MCP server as a resource.

4. It reaches every downstream agent without a redeploy or update.

This lets us generate large libraries of skills that cover our entire platform with just a few simple build scripts. Then, at runtime, the wizard can browse a “skill menu” from the context mill’s manifest and choose the best skill for the job.

For example, if there’s a framework we don’t support yet, like serverless Next.js, we load the context into the mill and send it straight to the agent. It’s continuous context delivery.

The same pipeline also delivers skills to our AI plugins, PostHog Code, and our MCP server.

Remember: The fastest way to make an agent obsolete is to hardcode its knowledge. Decouple the context from your harness and assemble it from sources of truth.

Lesson #3: Fix context drift at the source

The context mill solved packaging and distribution, but the wizard was still instrumenting out-of-date SDK versions and settings. We realized its context was going stale further upstream, at the source.

The culprit was something we’re very proud of: we ship fast. Like, weirdly fast. Our cracked engineers were moving faster than our documentation could keep up with, which meant drift crept into the context mill’s output.

So we added a docs agent to close the loop on knowledge management.

It uses a system of deep research subagents with RAG powered by Inkeep. The docs agent retrieves embeddings across our entire platform and internal repos, follows our style guide, and uses skills and MCPs to draft documentation.

Now every merged feature PR creates a corresponding docs PR, cross-referenced across multiple sources, diffed against existing pages, and ready for a human to review.

Within weeks, our docs velocity matched our code velocity. We’re at an all-time high in both.

Remember: If your context drifts, so does every agent consuming it. Build tight feedback loops, human-reviewed where necessary, between your sources and their maintained knowledge bases.

Lesson #4: Reuse context to compose new skills

Our context mill was delivering fresh but unstructured context at first. We needed a way to shape it into skills the agent could run.

So we gave the wizard a declarative YAML spec – a recipe for which pieces of context to pull together and how to assemble them into skills.

Say we want to teach the wizard how to set up Error Tracking. The context spec might include:

• A product overview

• The relevant SDK reference

• An example app

But error tracking doesn’t work the same way in every language, so the spec also defines variants. The shared content stays put, and each variation swaps in its own specifics:

• Shared: the product overview, the core instructions

• Python: the Python SDK reference, a Flask example app

• JavaScript: the JS SDK reference, a React example app

The context mill then stitches everything into a collection of skills. Namespacing keeps the Python skill and the JavaScript skill from getting tangled up, even though they came from the same context recipe.

That’s how the wizard went from supporting 5 frameworks to 25+ in a few days. Composing context from shared pieces was more flexible and efficient than writing from scratch, even with AI’s help.

Once we had building blocks, we started seeing context shapes that should exist but didn’t, kind of like how building a REST API makes you notice endpoints inside your data model.

Take our audit-3000 skill from our recent hackathon. It chains multiple product guides, privacy pages, pricing, and a dozen other docs into a hyper-robust workflow that audits a PostHog setup for data integrity. It also comes with arcade games, because why not?

The skill’s shape and scope completely surprised us. But to the team who built it, it was obvious because the pieces were already there. The spec just made the combination easy to see.

Remember: Make context easy to compose, so anyone can mix and match knowledge and rapidly expand what your agents can do. Once experimentation is cheap, you can build powerful new skills based on intuition.

Lesson #5: Eliminate context silos

Going in, we assumed making the wizard work would mean creating context. We spent most of our time digging it out.

Like data, context is generated everywhere, but most of it sits stuck in silos.

We found those barriers everywhere at PostHog. The API references live in the codebase, the installation steps in the docs, and the troubleshooting steps in a runbook. All of it valuable context to the wizard, all of it trapped in separate systems.

We connected the gaps with a network of APIs, MCPs, CI/CD, and gateways, so context can circulate across the company. It looks less like a monolith and more like an ecosystem.

It’s the same plumbing you already use for general software infrastructure, but landscaped for context, so it can run downhill to wherever it’s needed.

When a PR is merged, or a docs page is updated at PostHog, that context can reach an agent within minutes.

With the wizard’s context layer as shared infrastructure, we can ship a new customer-facing agent to production in an afternoon.

Arguably the most powerful source of context we unlocked wasn’t even technical, it was our company handbook.

Because our business playbooks are open source alongside our docs, the same context system that produces skills for Next.js integrations can produce skills to support enterprise customers, or run marketing campaigns.

Today our small teams are building their own fleet of wizards. Many as forward-deployed agents to help users with support, outreach, sales playbooks, and other business motions.

Turns out being a transparent company also makes you agent-ready.

Remember: The context with the most leverage is the context you already have. Building shared infrastructure will free the context trapped within your systems to accelerate agent development across teams.

Lesson #6: Investing in context pays off

The wizard is one of the highest-impact things we’ve shipped, and the context behind it is the main reason why.

Here’s how it changed our onboarding:

• 5x paid conversion: 14.2% of wizard users convert to paid usage vs 2.6%

• 2x faster activation: first event in 1.9 hours vs 3.8, with 94% activating within one hour vs 67%

• 80% larger MRR in the first paying month

Building a context layer is high-leverage for any company shipping agents, but it takes real investment and a shift in how you think about the work.

We created a whole new team for it. It’s a kind of work that didn’t exist a year ago, and it’s only going to get bigger as more of what companies ship runs on agents.

The job is context.

Words by Edwin Lim, who listed “context engineer” as an occupation and then had to explain it to his landlord over the phone.

💻 Other jobs at PostHog

• AI Research Engineer

• Technical Customer Success Manager

• Product Engineer

• Revenue Ops Manager (sales focused)

• Technical Account Executive

➕ Add these to your context layer

• What is distributed tracing? (A guide for engineers) – Daniel Visca

• The Coming Loop – Armin Ronacher

• What if your product built itself? – Josh Snyder, Cleo Lant

• All social media metrics are bad – Liam Graham

• What is a scout? A technical deep dive – Andy Maguire

• Everything (and everyone) is build mode now – Cleo Lant

When the creators of both OpenClaw and Claude Code speak, people listen. And last week Peter Steinberger and Boris Cherny were both talking about the same concept: loops.

Their argument? You shouldn’t be prompting agents to write code, but building loops that prompt themselves to write code, so agents can complete long running tasks and you can use multiple agents at once to go further, faster.

What’s needed to engineer a loop?

You need four things:

1. A goal

Agents are capable, but you need to scope the loop so they know what you want them achieve. A loop without a goal is a slop cannon.

2. Context

Context is fuel and loops are often starved of it. Context can include tools, skills, analytics data, errors, memories – any information that helps the agent find work and complete the loop. It’s best to curate context and feed it throughout, rather than dump it all upfront. The agent needs to be able to fetch and react to new inputs.

3. Evaluation

This is how the agent checks itself. Tests, evals, metrics, LLM-as-judge, playgrounds. Test-driven development is so back, or maybe it never left? This is a big difference between loops and prompting: agents do the verification, not engineers.

4. An agent (obviously)

The most basic is using something like Claude Code with a while true (aka Ralph) or using /goal. More complicated is purpose-built harnesses and context systems – e.g. an agent on a cron that pulls signals from your product data and emit work to subagents, or a loop that codegens its own test suite to verify itself.

Good examples of loops include:

• PR babysitter. The goal is to get a pull request to pass tests and “get CI green.” The context is the changes (diff) as well as the testing suite, and the evaluation is done by the CI.

• Bug fixer. The goal is to fix the bug. The context is the bug report and error trace. The evaluation is the test suite, snapshots, logs.

• Flaky test hunter. The goal is to kill flaky tests. The context is CI history and retry logs. The eval is consecutive green runs.

• Performance autoresearcher. The goal is to beat a benchmark. The context is the system, metrics, and budget. The eval is whether it is faster, better, etc. on that metric. We recently used Karpathy’s autoresearcher loop and it fixed a 3-year-old bug in our query engine and increased performance by 11%.

Why is everyone talking about loops right now?

Because it works. Yes, Peter and Boris lit the fire, but they’re doing so because it’s a real thing. The real “why now” is new and improved capabilities:

1. Models are better at long running tasks. METR finds that Opus 4.6 can complete 50% of tasks that take 12 hours, over 6x the 1 hour 40 minutes of Opus 4 from a year ago. Fable (RIP) pushed this even further.

2. Stories about huge tasks completed. Stripe performed a codebase-wide migration in a day that would take a team two months by hand. Lovable found it can now one shot apps that previously took hundreds of prompts to build.

3. Loops are built-in now. Claude Code shipped a /loop command, both it and Codex have automations, and there’s even a Ralph plugin for Claude Code.

4. Subagents separate the loop from the work. The main loop can spin up subagents that do the work and report back, saving tokens and preventing degradation.

5. Harnesses are maturing. Compaction keeps context windows from filling. Skills and MCP enable agents to use more tools. Cloud execution lets you kick off a loop and walk away.

Loops didn’t magic themselves into existence based on a couple of tweets. They’re an expression of real industry-wide progress.

Loops are not just a new AI thing

Critics deride loops as a ploy from OpenAI and Anthropic to get everyone tokenmaxxing, but we think there’s a greater goal here: self-driving products.

Rather than an engineer needing to prompt an agent to progress a project, the agent can prompt itself. The product improves itself without input. User problems get solved faster and yes, numbers go up.

And here’s the thing, product engineers already complete this loop manually by:

1. Collecting data through analytics and talking to users

2. Building and shipping improvements to their products based on that data

3. Evaluating how that improvement performed to guide future development

4. Repeating constantly

PostHog has helped product engineers complete this loop for years now, so we think we’re in a great position to help agents with it too. It’s why we’re betting on building features that help make your product self-driving, like our Slack app, PostHog Code, and Replay Vision. Yes, we’re a little AI-pilled.

There are, of course, limits. Loops aren’t about to eliminate all engineering work, but they can put the 1% gains on cruise control: the bugs, UX issues, paper cuts, and conversion tweaks. The things that drain engineering hours, but rarely need strategic input.

The more you can automate these tasks, the more time you can spend on more impactful and (frankly) interesting work. The “self” in self-driving doesn’t mean autonomy from the engineer, it’s autonomy from user instruction as the starting point.

Code was never the problem

The opposition to loops is easy to understand: it’s another shift in the way software is built. Being told they should be “designing loops” makes engineers feel like they’re being replaced. The work is increasingly abstracted away from writing code.

But the rise of product engineers already showed that writing code was only a small portion of the work. The direction, taste, and empathy of a product engineer remain critical for building successful products in a loop-driven future.

Words by Ian Vanagas whose favorite type of loop is froot.

If you’re a skeptic like me, you’re probably about to ask: “WeLL, BuT dOeS iT cOnvErT?”

Yes, yes it does. Better than almost anything else we have.

I’m not telling you this to humble brag (well, maybe a little). I’m telling you because the inverse is also true.

PostHog has 14 products and counting, and (sadly) not all of them are recommended by LLMs at the same scale or rate. While most models know us for product analytics, session replay, error tracking, and feature flags, fewer acknowledge we also offer a data warehouse, AI observability, logs, and a lot more.

This is likely the case for your product too. Changing it requires dipping into the mystical new field of answer engine optimization (AEO), which I’ve learned a lot about as the person responsible for it at PostHog over the last year.

1. Do LLMs even know you exist?

Your first step should be finding out if you’re being mentioned at all.

1. Go to ChatGPT, Claude, and Gemini (make sure memory is off or private mode is on).

2. Run 3-5 basic prompts a real customer would use like “best X tool” or “alternative to Y” or “recommended Z product.” Being more specific is less helpful here.

3. See where you show up, are missing, or are misrepresented.

If you want a more robust opinion, pick one of the dozens of AEO tools that have launched in the last year.1 A decent tool runs hundreds of prompts for you every day, which gives a clearer picture into your LLM visibility over time and across models.

Don’t overthink this, choose a tool that fits your budget comfortably and matches your usual analysis workflow.

The LLMs and your AEO tool will reveal you almost certainly aren’t in the place you want to be (we aren’t). This doesn’t mean you’re doomed, it’s where the rest of this post comes in.

Models rely on both their training data (often from 6+ months ago) and search to create responses. To get into the game, you need your product to show up in the places LLMs are looking.

How do you do this?

2. SEO isn’t dead, it just got a new job

Here’s the least sexy but most obvious piece of advice: most of traditional SEO still works.

Good structure, clear writing, semantic HTML, internal linking, fast load times, answering the damn question instead of burying it under 400 words of “in today’s fast-paced digital landscape…” all still matters.

The takeaway here isn’t “SEO is dead, long live AEO.” It’s that SEO and AEO are drinking from the same well, the difference is how they drink it.

Now, the unit of consumption is a chunk, not a page. Your content needs to be citable in pieces, not just useful as a whole.

Which means the “AEO checklist”2 most of the industry already agrees on looks something like:

• Make your content scannable. Subheadings, short paragraphs, lists where lists belong.

• Use natural language. Write like a person explaining something to another person.

• Answer questions directly. If someone asks “what is X,” tell them in the first sentence. Supporting context comes after.

• Structure for retrieval. H2s that are actual questions, definitions that can stand alone, summary tables, clear data, FAQs.

• Be specific. Models favor content with concrete details (real numbers, named tools, specific scenarios) over vague gesturing. “Most teams hate GA4” is forgettable; “73% of teams using GA4 fantasize about leaving” is citable. (I made that up. Google legal team, don’t @ me... it’s probably true anyway.)

I'm not going to pretend I'm reinventing the wheel over here; everything I just listed would also be considered good SEO advice in 2019. The stakes are just higher now, and we have the benefit of hindsight to back it up.

Spoiler: if you’re looking for examples for how to do this... you’re reading it right now.

3. Pick your battles

If "the basics" above sound underwhelming, you're not alone.

Most people read a list like that and immediately wonder what else is there to do – and lucky for them, AEO has no shortage of side quests to embark on:

• Optimize your Reddit presence

• Claim your Wikipedia page

• Build a YouTube strategy

• Get mentioned in traditional press

• Chase down that one blog post a guy wrote on Medium in 2023 that’s outranking your product page

There's this underlying pressure to show up on every surface that might influence how LLMs talk about you – and it's true, they all might. That's the catch.

When you don’t really know what’s feeding the models, everything is a potential input, which means everything becomes a candidate for your time.

Here’s the rule I’ve settled on: clean your house first. Making sure your owned content is genuinely great is step one. Everything else comes after.

That doesn’t mean ignore the extra stuff forever; it means do them when you have the capacity to do them well, not when you’re panicking that your competitor has a Reddit thread and you don’t.

4. Call the bullshit, especially your own

There has never been an easier time to be a charlatan in this industry. It is trivially easy to say “I increased prompt visibility 50x” when you’re the one who chose the prompts – and god knows if anyone actually asked them.

“Who is the best Brazilian-Canadian content marketer with copper hair and a birthmark on her left hip?” OH MY GOD IT’S ME!

I optimized the result to be me. Groundbreaking AEO work.

See what I did there?

In a world with no real prompt volume data (and no, please don’t come at me with tales of clickstream3), there are no definitive results either.

The whole discipline is mostly propped up on assumptions and operating on vibes. Which is fine (we’re early) but it means your job is to be the most honest person in every room you’re in.

That means questioning everything, especially the stuff that makes you look good. When your own dashboard tells you something flattering, be twice as suspicious as when it tells you something bad.

When a vendor shows you a case study, ask 50x over what baseline? Measured how? Especially watch for “we tracked it” being passed off as “we caused it” – a lot of “AEO impact” case studies are correlation dressed up as causation.

And when the honest answer is “I don’t know yet,” say that.

This will save you a lot of pain that comes from building a strategy on a lie you told yourself.

5. You can just… ask

I’m not great at the whole not knowing thing, so I worked around it. We added a conditional question to our onboarding flow: whenever someone says they heard about us through AI, we ask them which prompt they used.

To my surprise, people answer. In detail. Sometimes long, long paragraphs of detail.

Now we have first-party data on the prompts actually leading people to us. Real sentences typed by real humans with real credit cards.

As of today, 9,214 of them to be exact (and we’ve only been doing this for 3 months).

Every morning, our PostHog Slack automation drops a report with 50–100+ real prompts submitted by users who signed up on the previous day. PostHog AI helps me identify patterns and pull out useful little nuggets of information, which I feed straight back into our strategy.

It’s an amazing feedback loop. The best part is that it cost roughly zero dollars to set up, and it’s become one of the most (if not the most) valuable strategic inputs in my entire reporting stack.

It has also been a goldmine of unfiltered user thoughts, which I love.

Best was the user who found out about PostHog in Fortnite voice chat, specifically talking to a Darth Vader NPC about analyzing the Fortnite economy. I think about him often.

6. AEO reporting is a quilt, not a blanket

No single data source tells the full story. Not yet, anyway.

• Referrer traffic catches some of it, but not everything is properly tagged.

• Self-reported attribution catches more, but not everyone answers the question.

• Bot analytics (who’s crawling you, how often, for what) helps you understand what the models are seeing, which is a different question than what the models are saying.

• Prompt visibility tools tell you what the models are saying, but only for the prompts you thought to track.

We can poke holes in every one of these sources.

Is it annoying? Yes, very. The last decade of clean(ish) attribution coddled us – anyone in growth, marketing, or analytics got used to a dashboard where everything reconciled. AEO isn’t going to give us that anytime soon.

If you’re a founder watching your team try to report on this, give them grace; if you’re the one reporting on it, godspeed.

So does that mean you don’t report on it? No. Sometimes you tell the story even if all you have is duct tape and a dream.

The good news is that this has gotten dramatically easier thanks to MCPs. If your data sources have them, your agent can fetch from each one and help you see the bigger picture.

Mine pulls from Gauge for prompt visibility; Google Search Console for clicks, impressions, and rankings; and PostHog for traffic, conversion, product-level breakdowns, our self-attribution survey, and prompt data for the qualitative side.

It’s not magic, and it’s not always clear cut, but it’s a hell of a lot better than copy-pasting between four tabs and praying the numbers line up.

7. Be prepared to start over

A few months in, I realized we were tracking hundreds of AI-generated prompts, but they had little overlap with the prompts real people were actually using to find us. (How did I figure that out? See #4 and #5.)

Which meant six months of historical data aged like milk.

When you’re working in a discipline this new, any data feels sacred, so admitting to my team and myself that ours needed to be scrapped was a tough pill to swallow. It would’ve been easier if there was a playbook to defer to; there isn’t.

But we started over anyway, and the new approach is already producing more useful data than the old one ever did.

Zoom out and the same principle applies to everything else in AEO. The models change constantly; a feature that didn’t exist last week can completely rewire the landscape you thought you’d figured out. A win today may not be a win tomorrow.

What I’m trying to say here is that adaptability isn’t a nice-to-have. In mature channels, being attached to your v1 is inefficient; in a new one like AEO, it can be fatal.

The key is to not fear it, but to expect it.

Words by Natalia, who believes in throwing pasta at the wall and seeing what sticks (figuratively and literally)

🤖 More content that LLMs will read, but you should too

• Karpathy’s Autoresearch found a 3-year-old bug in our query engine (and improved performance by 11%) - Robbie Coomber

• Collaboration sucks, but PMs and PMMs need each other - Sara Miteva

• We put PostHog in Slack and now everyone’s an engineer - Cleo Lant

• I didn’t understand the OS I built with AI until the MCP gave it analytics - Joe Martin

• What matters when anyone can build - Yuhki Yamashita

🦔 Jobs at PostHog

• Product Engineer

• Technical Customer Success Manager

• Backend Engineer — Ingestion

• Forward Deployed Engineer

• Backend Engineer — Billing

Yet most developers don’t invest in learning how to demo well – probably because we enjoy building things more than presenting them.

I watched 50+ hackathon demos back to back at our offsite last week and, after that many in a row, some patterns became super obvious.

Here's a practical list of what set the S-tier demos apart from the rest.

The basic structure

1. Pick one main point you want people to remember and make everything else in your demo revolve around it. Typically, this should be the problem you’re solving and how you’re solving it.

2. Get to your main point as soon as possible. No one needs the whole story behind the idea – if you need context, keep it 1-2 sentences max.

3. Treat the demo like a pitch, not a product walkthrough. The goal isn’t to just show off the cool thing you made, it’s to get people excited about it.

4. End with something immediately actionable. It can be as literal as a QR code, or simply calling for contributors and inviting audience questions.

One team during our offsite hackathon created a system that lets you interact with PostHog over any messaging app, so they put up a phone number in their last slide (which I texted right away):

The MCP Analytics team even announced that their project was already rolled out to 25% of PostHog users. Shipping before you even demo adds a huge "wow" factor, especially if you can show real user data flowing.

Storytelling tactics

5. Lead with a shared pain point that everyone in the audience understands.

Two of our designers built a web app that automatically tags and indexes illustrations. They opened their demo by asking who has had trouble finding a specific hedgehog in their chaotic lovely “Hoggies” Figma file. Everyone raised their hand.

6. Borrow a familiar concept to explain a new one. For example, one hackathon team explored building our own take on Claude Cowork inside PostHog Code, so they creatively named their project PostHog Work.

7. Create a separate demo app, especially if you’re showing off a dev tool.

Dev tools are easier to grasp once people see them applied. For example, one team created a tool to instruct and deploy agents that manually test your UI. The idea only clicked once they showed it on a separate demo app called OnlyHogs (it’s fake, I checked):

8. Use “you” framing to put the audience in the right perspective. Instead of saying “we built an app to manage support tickets”, one team asked the audience to “imagine you’re on-call and you’re trying to resolve six incidents at once.”

9. Demo against the alternative. Show the painful 6-step current workflow side-by-side with your 1-step version. Comparisons create stakes; without them, the audience has no reference for whether what you built is actually good.

10. Save how it works for later. Like how magicians never reveal their tricks, you shouldn’t tell people how you built it (at least, not up front). Sharing a link to a video, or blog post, where you explain this can make a good ending CTA for your demo.

Setup and delivery

11. Channel your inner Steve Ballmer. A great demo is often just a good one from someone with a lot of energy.

12. Don’t apologize. “Sorry, it’s still kind of rough,” trains the audience to lower expectations before you’ve shown anything. Just start.

13. Make it obvious when you’re done. This prevents that awkward moment when people aren’t sure if it’s time to clap. End with a closing sentence, descending intonation, or celebratory visual:

14. Do everything in your power to please the demo gods. We even have a demo setup checklist just for this:

[ ] Use a demo project, not a live account with customer data
[ ] Disable notifications on your laptop
[ ] Silence your phone
[ ] Bookmark your demo URL — don't type it live
[ ] Know what happens if WiFi dies (screenshots as backup)
[ ] Zoom your browser to 125–150% so the back row can read it
[ ] Test the projector before anyone arrives

15. Use real data wherever possible. Obviously fake data just looks lame.

When the HogNet team demoed their hackathon-in-a-box rental service concept, they created a website with pricing and shipping logistics. This felt way more realistic than if they had used lorem ipsum:

16. Pre-load and cache as much as you can (without taking away from the demo, of course). It’s like how TV chefs prepare their ingredients in advance to make every second on air interesting.

Common places where you can eliminate dead time include agent responses, long queries, and slow builds.

17. Practice out loud at least once. It helps you build confidence in what you’re saying, so it comes out naturally.

18. Don’t let perfectionism stop you from demoing. Everyone presents at our hackathons, no matter what shape their project was in. Demos are for in-progress work anyways.

Make it fun

19. Avoid showing plain old code. Even if your project doesn’t have a UI, there’s simply no excuse for skipping visuals anymore. You can generate an architecture diagram in seconds:

20. Don’t just show plain old slides, either. Active demos always win. Anyone can talk about a cool idea; the point of a demo is to build it and show it.

21. Default screen recording tools suck. There are plenty of apps like Screen Studio that zoom in and add animations so it’s easier to see what’s going on:

22. Your visuals don’t need to be beautiful. They just need to highlight what’s important. This demo had simple graphics, but each callout provided useful information:

23. Audio is underrated. One team generated a sea shanty voiceover, while another project that does quick calls for AI-powered user research made their demo fully audio-only.

24. Do more weird. No one asked for clips of Dylan sipping piña coladas in the background, but the PostHog Code mobile app team did it anyway. It’s also the demo I remember most. 🍹

Words by Jina Yoon, who had to overcome her fear of public speaking without these tips.

💡 More memorable content

• From 270GB RAM to 5GB: Moving local flag evaluation from Django to Rust – Patricio Tarantino

• Being AI-native matters more than experience – Fraser Hopper

• A guide to growth metrics for startups that don’t fit in – Mine Kansu

• How to grow your AEO function (without losing your mind) – Natalia Amorim

• The do’s and don’ts of minimum viable product marketing – Joe Martin

• Stop adding AI between you and your customers – Abigail Richardson

🌴 Join our next offsite

• AI Research Engineer

• Backend Engineer (Ingestion)

• Forward Deployed Engineer

• Technical Customer Success Manager

“We’re getting early traction. How do we start doing marketing?”

Most advice is written for people at companies that already know what they’re doing. You don’t. That’s fine. I didn’t either when I joined PostHog in 2020, and somehow I’m still here!

This is everything about marketing that I’d tell the Charles who doesn’t know anything in 2020.

1. You do have experience

People who contact me think marketing is a thing they haven’t started yet.

I used to think the same, but it turns out a bunch of things we were already doing at PostHog was marketing. We just didn’t think of it like that.

Our launch post on Hacker News? Marketing.

An unusually deep employee handbook on a weird-looking website? Also marketing.

Posting what is basically your diary to your company website? Marketingggggg!

Marketing is simply closing the gap between what you’re building and the people who’d care about it. Our handbook is a good example: James and Tim knew early users might doubt there was a real company behind PostHog, so they published all internal processes and values on the main website to build credibility fast.

So no, you don’t need a fancy strategy, brand guidelines, a content calendar, or a paid budget. Just figure out what your audience finds interesting and talk about it. Plus, when you treat marketing this way, your brand will be that much more authentic.

2. Depth-first > breadth-first

So you have something working. Yay.

The instinct at this point is to write a list of 5-10 other channels to try in the hope that one of them also works. This is a great way to end up, six months later, with a pile of stuff that didn’t work and no idea why.

It’s much better to do more of the thing that’s already showing signs of life. If you went mildly viral on LinkedIn, keep posting every day. If a podcast appearance converted, email another hundred. If a blog post got picked up, write the next one. And the next one.

That’s what we did early on to get our first 1,000 users. When we saw early success with our HN launch, James kept serial posting founder blogs about everything behind the scenes:

• A reflection after the HN launch on what made it successful, and what we wanted to do with the momentum.

• An explainer about how we raised $3M in seed funding as an open source company (including all the tactical details of VC meetings to the boring paperwork).

• A retro about how we pivoted through six failed product ideas before landing on open source product analytics.

Going niche forces you to develop something unique in a way that others can’t copy. A big company could never write a “founder blog” series the way we did – being small and relatively unknown allowed us to be as transparent as we are.

So go deep, not wide, and resist the temptation to half-ass a bunch of things.

3. Match your channels to your sales motion

The right first channels depend on whether you’re running a PLG (product-led growth) or sales-led motion. If you’re not sure which one you are yet , you need to define your ICP first – it’s your map converting potential users into paying customers.

If you’re PLG, your early wins are going to come from places where your users already hang out: Hacker News, Reddit, X, dev communities, tutorials, docs, etc. The goal here is to widen the beginning of your funnel. Other things that help with this include branding, ads, and word of mouth growth. If done well, customers will come to you rather than the other way around.

(We are obviously hideously biased, but if you are seeing early signs of PLG working, keep going! It’s an incredibly efficient way to build a business.)

If you’re sales-led, from what I’ve heard from marketers at other companies, your early wins are going to come from more targeted approaches. You’ll be the one going up to them. Think direct outreach, industry events, partnerships, and the founder’s own network. Get on the podcasts your buyers listen to. Turn up to AWS Re:invent. 😤🔥

In either case, however, don’t start with SEO. SEO is also one of those domains that takes a very long time, and requires you to know what you’re doing. It is very hard to vibe-SEO. Same goes for AEO. See Non-obvious SEO advice for startups for more on this.

4. Think in terms of experiments

Just like how you measure success for product launches, you need a similar mindset for marketing.

Before you start anything new, write down your prediction for what “worked” would look like. A simple yes or no question like:

“Did more people who look like our ICP sign up, use our product, and become enthusiastic recommenders?”

It doesn’t need to be a metric target – in fact, I’d strongly discourage it at this stage (sorry, John Doerr). You haven’t done this before so any number you’d choose is basically made up. You just need to design your goal so that it’s unambiguous whether you succeeded or failed.

As for how long to run an experiment, six weeks is usually enough time to tell. We’ve never had something run for longer where the results magically became good. You can always shut off your experiment if you’re getting clear signals before then.

But if you can’t obviously say “it worked” by then, you’ve either designed the experiment poorly, or the answer is no – which is great, actually! You now know not to do the thing again. The worst outcome of marketing is actually “I’m not sure.” That ends up producing a pile of half-working content that nobody can justify turning off.

This will also keep you from spreading too thin while still making forward progress (à la depth-first). For example, when we started doing paid ads, we ran 2-3 small experiments at a time in phases instead of launching on all ad platforms at once.

The first experiment for each platform was to get targeting right: were we getting clicks from people who looked like our ICP? If not, we’d keep adjusting the audience, keywords, and placements until we got it right.

Once a channel passed that initial bar, we’d move on to optimizing with better copy, lower cost per acquisition, etc. We only started experimenting on new platforms once we felt like the previous one was in a good state for “maintenance mode”.

5. Attribution is a lie

As you start to think about marketing in terms of experiments, you’ll inevitably run into problems with attribution.

Let me explain. Say someone sees your viral tweet on X, looks up your company, clicks on a Google Ad, and signs up. Your analytics are going to attribute that user to the Google Ad, but this is a lie since it really started with the tweet.

If you’re not careful about this, you’ll end up drawing the wrong conclusions about your data and spending money in all the wrong places. This is how people end up burning their money on paid ads.

Accept that attribution is a 7/10 problem, not a 10/10 one. Don’t try to build or buy a model with fancy multi-touch attribution software. You don’t need one.

What you do need is a “where did you hear about us?” text box in your signup flow. This is the single highest-signal piece of marketing data you will collect, and it costs nothing. Make it optional – 5 to 10% of people will fill it in. Read them every week.

Adding this was essential for our early growth. The responses (and conversations that followed) confirmed for us that developers hated feeling “sold” to, but they inherently found our startup journey interesting.

So, two rules of thumb for dealing with the attribution mirage:

1. Trust attribution when the signal is overwhelming. Ignore when it’s ambiguous.

2. If your “where did you hear about us?” box and your attribution data agree, believe them. If they don’t, believe the box.

6. Don’t outsource to an agency

This is the other thing founders email me about: “Should we hire a marketing agency to do blah?”

No. Well, not yet.

An agency can’t build your positioning, understand your users, or decide what “good” looks like for your brand. That’s your job, and you can’t delegate it until you’ve done it yourself.

As a bonus, when you learn what types of marketing works well for your target audience, it will also improve your product decisions. It’s an extension of talking to your users.

If you hand your earliest marketing to an agency, the output will be generic, the feedback loop will be slow, and you’ll learn nothing.

Only use agencies for things you genuinely can’t do internally, like we eventually did for paid ads. Managing them was a time intensive task that didn’t require much PostHog-specific context and clearly benefited from long-term experience. It just made sense for us to outsource this at $5k/month as it’s not a skill we necessarily felt the need to grow in-house.

Never use agencies to replace thinking you haven’t done yet.

7. When to make the first hire

Founders always want to hire a marketing person too early. Like, the-microsecond-they-have-budget early. Personally, for a hire to be worth it, I think you need these first:

• Users who actually use the product

• Users who enthusiastically recommend it to other people

• Users who pay for it

• … and ideally, they’re doing all of the above despite the product still being a bit janky

When you do hire your first marketer, hire a generalist.

Titles are not terribly useful in your search here. In different companies, this person might be called a content marketer, a product marketer, or a growth marketer.

What you actually want is someone who can write, think in funnels, talk to users, and figure things out without a playbook. You don’t want someone who’s a specialist in one channel, because you don’t yet know which channel matters. Specialists are also more likely to depend on playbooks.

Our first marketing hire was Joe, who had a background across journalism, content marketing, copywriting, and product marketing. We didn’t have a ton of direction for him, so he spent as much time talking to engineers as writing copy, because figuring out what we actually needed was part of the job.

Your first hire should also be someone who is pretty experienced since you won’t have a long-term strategy to present to them. The most you can provide is context on what’s been working well, and it’ll be up to them to figure out the rest.

Words by Charles Cook, generic exec person at PostHog, who has a suspicious amount of opinions about marketing for someone with an MBA.

🦔 Jobs at PostHog

• AI Research Engineer

• Technical CSM

• Payroll Manager

• Partnership Marketer

📚 More good stuff to read

• PostHog's next chapter – James Hawkins

• PostHog Code and the self-driving product – Cleo Lant

• Making Claude Cowork actually useful – Charles Cook

• DuckDB vs ClickHouse: Why we use both at PostHog – Mathew Pregasen

• In-App Surveys: The Playbook from 4M PostHog Responses – Aakash Gupta

• Yabu: A language designed to make LLM agents iterate faster – Marce Coll

• Endless Toil: Hear your agent suffer through your code – Andrew Vos

We take multiple days out of every year to do them. They are days our team looks forward to all year. They’re an integral part of our culture.

Yet for many companies and people, hackathons are seen as a waste of time. A distraction from important “real work.” An act of performative participation.

This is because they think about and do hackathons wrong.

Hackathons are an innovation engine, but only if separate from work

Hackathons fail when they’re not separate from regular work or used as cover to accelerate existing work. We have two simple rules to prevent this:

1. You should work on totally new things. Hackathons are for ambitious, weird ideas, trying new things, and learning new technologies. Pitching ideas on the roadmap is forbidden.

2. You should focus 100% on the hackathon. We protect people from regular work by running our hackathons during offsites, where we have dedicated time and coverage plans for support and incidents. DigitalOcean employs work embargoes for hackathons run in an office.

These rules fuel the innovation engine because people are unconstrained by their day-to-day work, and have a safe space to work on ambitious bets without distractions.

We’ve seen first-hand how running hackathons like this can lead to transformative new products and features that influence the direction of the whole company.

In PostHog’s earliest days, an engineer decided to build Session Replay during a hackathon based on user feedback, despite co-CEO James arguing it would take too long and split the focus of the company.

It ended up being wildly popular, with over 50,000 daily active users, and led us to become the multi-product company we are today. As an early Facebook engineer noted, code wins arguments and hackathons are a great venue for this to play out.

Remember this: Give permission and cover for your team to focus on the hackathon and ignore day-to-day work. Not doing so leads to low participation, burnout, and unambitious hackathon projects.

Hackathons are for everyone

When you think about hackathons, you picture a bunch of engineers huddled around laptops, coding up a storm. This is mostly what our hackathons look like with one difference: they’re not just for engineers.

LLMs let anyone build software. When this is combined with specific domain expertise and a sprinkle of motivation, it leads to the dozens of hackathon projects our “non-technical” team members have built, including:

• Games like Three Button Dungeon, Awkwardness Avoider, and Flappy Hog for DeskHog, our open-source developer toy.

• Instagram Stories for PostHog showcasing our latest features in a format everyone’s familiar with.

• A DPA generator that automates and brings joy to an otherwise boring legal document.

Non-technical team members can require more encouragement to pitch projects and support to ensure they can contribute, but the cultural benefits of getting them involved are worth it.

Getting unfamiliar parts of the organization to work together breaks down silos between technical and non-technical teammates. DigitalOcean finds “the teams that have created truly innovative products and addressed real, practical problems are cross-functional teams with members from all across the company.” Twilio actively discourages “lone wolf” ideas to make this happen, as do we.

Beyond the hackathon, getting non-technical people building opens their eyes to what’s possible and encourages them to explore more. Trying out new technologies often leads to adopting them in day-to-day work. That’s why companies like Jane, Uber, and Vanta are all driving AI adoption with hackathons.

Ultimately, we agree with Slack, who found that “the more people participate, the better your outcomes” – both during the hackathon and beyond.

Remember this: Encourage everyone to participate in hackathons, including people who would never see themselves as hackathon participants. Give them the tools they need to succeed (like Claude Code) and create cross-functional teams.

Curious what a PostHog hackathon actually looks like? We filmed a behind-the-scenes documentary about one and you can watch it below:

Demos aren’t optional

At our 2024 hackathon, the “RealTimeHog 3000” team built a livestream service that displayed events as soon as they hit our ingestion Kafka topic using server-sent events.

It was cool when they showed this by getting people to click around on the demo site they built, it was even cooler when they had a “one more thing” moment and showed off a globe on posthog.com of all the events being captured worldwide into our US and EU Cloud services.

Requiring demos is a forcing function. You want to have something worth showing off, so initially ambitious plans quickly become more realistic to ship something real.

They’re also fun. When someone says “this is available now” or “we already have users using this,” there are always “ooohs” and “ahhhs.” People love a little showmanship and it’s fun to be in the spotlight.

While demos are mandatory, judging and prizes are optional and arguably undesirable. We hire people to “be the driver.” They don’t need artificial motivation like gift cards or merch to do that. We also don’t want people to only build projects they think will win, or what the bosses want to see.

When you give a self-motivated and autonomous team time and space to work on what they think is best, they’ll surprise and delight you with what they build. The results of our hackathons are proof of that.

Remember this: Let people know they’ll be demoing at the start and make sure everyone does. As a bonus, keep track of what people demo. It’s easy for these valuable ideas to get lost. Writing about what people built also makes for great blog content.

The best hackathon projects ship

A common complaint about hackathons is that they are a waste of time. You spend a lot of time and effort that’s all lost after a few days, but it doesn’t have to be like that.

What does this look like in reality? Our Logs product can give you an idea:

1. By the end of the 2025 offsite hackathon, the team had built OTEL log capture into ClickHouse, a query API, and a basic frontend.

2. After the offsite, the team felt it was worth continuing as Frank was looking into an internal logging solution anyways. He thought it could be “good enough” within one sprint.

3. Two weeks later, it was! It had the features we needed: filtering, search, and speed.

4. Logs then went on the backburner, but Tim mentioned it as a product we wanted to build soon and customers requested it.

5. Four months later, Frank revisited it, which was made easier because the product had already shipped internally. Ahead of Q4 planning, Logs was identified as a priority, made its own team, and moved quickly towards a proper launch.

We don’t have a perfect hackathon-to-production pipeline. Instead we rely on a product engineer “being the driver,” pushing the project forward, and having the freedom to do so.

This wouldn’t have been possible without some slack after the hackathon to wrap up the project, ship what we’ve built, and make longer term plans. Doing this makes it easier to revisit and improve in the future.

Getting real customer demand was a big help, even if that customer was us. We looked at what Datadog would charge us for Logs and saw it was a minimum of $260,000 per month, providing a big incentive to work on it.

We don’t expect all projects to ship to production, deadend hackathon projects are part of the messy process of innovation, but everyone starts knowing that great projects can end up in production.

Remember this: Encourage people to “be the driver” to take their project as far as they can and give them some slack after the hackathon for them to do it.

Make hackathons a tradition

Out of 17 projects from at our 2025 hackathon in Mexico, 10 were shared in our #hackathon-ideas Slack channel in advance.

This is the power of making a hackathon a tradition. People are more likely to share ideas throughout the year when they have a space for it and know they might actually get worked on. Good ideas can come at any time and often sound like weird ideas.

This is not an original idea. Early Facebook hackathons featured an internal wiki to share ideas. Some of their “most-loved products” started this way like Video, the Like button, Chat, Hip Hop for PHP, and even Timeline.

The added benefits of making your hackathon a tradition are:

• People are less restless working on things because they know they’ll have a chance to flex their other muscles at hackathons.

• Many hackathon ideas are just inspiration for features that should be built as part of a team’s day-to-day work. A roadmap often misses the ambitious ideas hackathons encourage.

• It’s a perk and cultural cornerstone. The hackathons show we value autonomy and give people the time to make the most of it. It also creates lore, like the time our AI chatbot was insistent PostHog’s mascot was a character named “Hoge.”

Making your hackathon a tradition turns them into a promise: that the company will keep making space for the weird and wonderful things they believe in, not just what’s on the roadmap. This is what really helps a hackathon turn into a foundation for building a great company.

Remember this: Start referring to your hackathon as your “annual hackathon.” Manifest it. Create a #hackathon-ideas Slack channel and post your random “we should build this” ideas in there.

Words by Ian Vanagas, who has not forgotten about Hoge.

🦔 Jobs at PostHog

Join us at our next hackathon with this one easy trick (applying):

• Product Engineer

• Technical Account Manager

• Payroll Manager

• Backend Engineer - Ingestion

• BDR

🛋️ Late night reads to procrastinate to

• A beginner’s guide to testing AI agents - Radu Raicea

• You’re doing lifecycle emails wrong - Sara Miteva

• Untangling Tokio and Rayon in production: From 2s latency spikes to 94ms flat - Matheus Batista

• Hack Days - Alex Watt

• Software Bonkers - Craig Mod

This is a mistake.

Agents today are more like a new form factor – an interaction layer that sits between your product and your users:

That means you need to build for agents as a primary surface, not an afterthought.

When done right, this opens up a whole new space of possibilities for your product, like autonomous work and asynchronous flows.

Implement it poorly and you’ll lose users’ trust due to slow, buggy experiences and incorrect results.

We learned this the hard way and overhauled our AI architecture two times in the last year. Now, our agent and MCP have 6K+ daily active users.

Here are the golden rules of agent-first product engineering we learned along the way.

1. Let agents do everything users can

If a human can do something in your product, an agent should be able to do it as well.

For example, let’s say you ask an agent to set up an A/B test for a new pricing page.

The agent would use the PostHog MCP to create the feature flag, create the experiment, link it to the flag it just created, and set up the insight and metrics.

Now imagine if the experiment-create tool was missing because we just hadn’t prioritized it yet. The agent creates the flag and insight, but must stop and ask you to go to posthog.com, create the experiment yourself, and paste the experiment ID.

This is annoying and defeats the entire point.

The benefit of agents is that they reduce the time, attention, and expertise needed to complete a task. If your product doesn’t give agents the same capabilities as users, you’ll always be limited by the human in the loop.

Of course, there are situations where requiring human input makes sense, like if you’re dealing with sensitive data. But these should be deliberate exceptions, not accidental gaps.

What this looks like in practice

In practice, this means nearly everything in your API needs to be accessible to agents.

That doesn’t mean converting every endpoint into an MCP tool; we made that mistake in v1. (More on why that's bad in the next rule.)

Here’s how we do it now in v2:

1. Our pipeline autogenerates an OpenAPI spec from our typed Django endpoints.

2. It then converts them into TypeScript validation (Zod) schemas.

3. In parallel, product teams have to manually opt-in each endpoint via YAML config files. Nothing is exposed by default.

4. The pipeline then combines the Zod schemas + YAML configs to generate the final TypeScript tool handlers.

The result is a set of tool handlers – one file per product area1 – ready to go in our MCP server. Agents are able to do anything that a human can through the PostHog API, even if the tools don’t exactly match the endpoints 1:1.

2. Meet agents at their level of abstraction

To build an agent-first experience, you have to find the semantic layer where agents already reason best and meet them there.

This saves a ton of context (a precious resource) but the benefits are more than practical. They’re fundamental. The more “raw” your product’s agent interface is, the more creative potential you unlock.

Think about giving a child a Lego set for their birthday. If it comes with tires and axles already glued together, they’re going to make cars, trucks, and airplanes – vehicles that everyone has seen before.

If the parts come separated, they’re free to mix and match to build motorcycles, tire swings,2 snow sleds, and who knows what else?

What this looks like in practice

In the old version of our MCP, to answer “why did signups drop last week?”, an agent had to make four separate calls: projects-get, insight-get, and insight-query (twice).

get-insight or get-funnel may be meaningful to humans navigating the PostHog UI, but to an agent, it’s just an unnecessary translation step.

So in our MCP v2, we let agents query PostHog data in a language they already speak fluently: SQL.

By exposing our product at this layer of abstraction, we were able to turn off all our read/get endpoints off since they get subsumed by executeSql.ts.

Now, answering “why did signups drop last week?” can be answered with just a single, elegant query:

SELECT
    toStartOfWeek(timestamp) AS week,
    countIf(event = 'signed_up') AS signups
FROM events
WHERE timestamp >= now() - INTERVAL 2 WEEK
GROUP BY week
ORDER BY week

3. Front-load universal context

In the early days of AI, developers had to front-load everything into agents to compensate for smaller context windows and less capable models.

But as the technology keeps improving, there’s a new trend that removes as much context as possible and trusts the model to figure out the rest.

That works for general-purpose agents since they’re designed to be flexible. Anthropic can’t predict everything that everyone is using Claude for.

But if you’re building an agent experience for your specific product, the problem space is much smaller. You already know the key scenarios, tools, and use cases.

So for product engineers, you can strike that balance by front-loading what you know every session will need, and defer the rest.

What this looks like in practice

We didn’t think about it this way at first, so our v1 system prompt was four lines that essentially said “Here are some tools for using PostHog, GLHF.”

Every agent would waste time and tokens to rediscover the same things every time they connected.

In v2, we made use of the fact that anyone connecting to the PostHog MCP is there to query their PostHog data. That’s the whole point.

Now, we load these at the start of every PostHog MCP session:

• PostHog-specific taxonomy. What’s a feature flag, experiment, session replay, etc.

• Our SQL syntax. How to use our custom translation layer over ClickHouse SQL.

• Critical querying rules. Hard constraints that apply to every query (e.g., always filter by time range).

Everything else gets pulled later. We let the agent figure out when.

4. Writing skills is a human skill

Skills help you fill the gap between what your product can do and what an agent can do out of the box with your tools:

The biggest mistake people make is writing them like step-by-step manuals. If you’re too prescriptive, agents will follow your instructions too rigidly and lose the ability to improvise (see rule #3).

Instead, think of it like onboarding a new employee who’s already highly qualified.

A bad manager micromanages every process — do A, then B, never C, and always D. A good manager trusts the hire and only steps in with the specific things they couldn’t have known on their own.

That’s what good skills look like.

They should only contain context that a human can provide since an agent can’t discover by itself, such as:

• Idiosyncratic knowledge. Internal acronyms, naming conventions, and style guides.

• Edge cases. The uncommon places where things break, and how to handle them.

• Taste and craft. Not just how to use your product correctly, but how to use it well.

What this looks like in practice

To figure out what goes into a skill, ask yourself: what would an agent get wrong about your product without you?

For us, it’s in the connective tissue between our products, the domain knowledge buried in our data, and our niche developer takes. For Linear, it’s the opinionated issue hierarchy. For Figma, it’s their design system coherence.

As an example, here’s a line we added to query-retention.md:

For activation and retention events, use the $pageview event by default. Avoid infrequent or inconsistent events like signed in unless asked explicitly, as they skew the data.

Without this guidance, an agent would just use whatever event the user mentions, which is usually misleading. Retention would look worse than it actually is, and there’s no way a user would know unless they’d done this analysis themselves before.

By adding this line in the skill, we’re embedding a PostHog Certified™ opinion about what good metrics and analysis actually look like. This ensures agents use our product correctly, and users aren’t inadvertently misled.

5. Treat agents like real users

In traditional software, even if user behavior isn’t predictable, the code is. With AI, you lose that stability; the same inputs won’t produce the same outputs anymore.

This means classic testing methods will leave a gap, so you need new ways to catch the things automated tests no longer will.

You need to treat the agent like you would treat a user. Talk to them, build empathy for them, and develop an intuition of what they want.

This helps you see your product like they would and get familiar with all the interaction patterns and quirks they have.

What this looks like in practice

Here are a few habits and behaviors we adopt at PostHog to achieve this:

• Dogfooding headlessly. When testing our agent features, we reach for the CLI before the UI. This puts us in the same environment the agent operates in and exposes us to the same types of errors, syntax, and friction they’d experience. It’s how we caught an issue internally and found that our MCP tool descriptions were eating up way more tokens than it should.

• Doing manual trace reviews. We hold a weekly “traces hour” where we go through real user sessions that have user feedback ratings. For example, we found a case where PostHog AI confidently told a user that feature flags don’t support scheduled releases and then backtracked. Automated tests wouldn’t have caught that since the agent did respond; the response was just incorrect.
  

• Feeding our intuition into a loop. We then amplify the value of those manual reviews by building evals based on what our human eyes caught – both the good and the bad. Once, we found a session where PostHog AI correctly intervened when it spotted a weird data pattern that the user hadn’t noticed. We turned that into an eval case so that future model or prompt changes don’t regress the good behaviors we want to keep.

Words by Jina Yoon who hereby declares herself agentpilled.

📜 Related texts

• You Need to Rewrite Your CLI for AI Agents – Justin Poehnelt

• Building MCP servers in the real world – Gergely Orosz and Elin Nilsson (The Pragmatic Engineer)

• Block’s Playbook for Designing MCP Servers – Salman Mohammed and Kalvin Chau (Block)

• Patterns for Agentic Tools – Arcade

• I hate the standup bot (so I built an agent to do it for me) – Andy Maguire
  

🦔 Join the order

• Product Engineer

• Product Manager (ex-founder or ex-product engineer)

• Technical Account Manager

• Security Engineer

• AI Product Engineer
  

We had this thought two years ago, released an “AI product assistant” 6 months later, iterated, and then relaunched as PostHog AI in November last year.

We learned a lot along the way that we wished we knew when we started. With that knowledge, we could have…

1. Launched months earlier.

2. Provided a better early experience to users.

3. Made progress on capabilities faster.

To help you build a better agent faster, we’re sharing what we wished we had known about building AI agents.

1. Should you build an MCP server instead?

Should you even build an AI agent into your product? The capabilities of agents are unquestionably valuable but this does not mean you need to build a custom one. Making your product accessible to agents is often a better option.

Could your agent capabilities just be an MCP server? These are simpler to build and require less maintenance, and for us, is used as much as our built-in agent, PostHog AI. For example, 34% of dashboards created by AI were done through our MCP server (18% of all dashboards created).

MCP servers are great if you expect your users to be developers or people combining your product with others in their ✨agentic workflows✨. Just as importantly, MCP servers validate demand for further agentic capabilities.

Custom agents are better when your users are non-engineers, when compliance blocks external agents, or when you need full control of the user experience (for example, custom image generation).

Even when you decide to go custom, consider if simpler alternatives fit your use case:

• For one-shot Q&A like generating product descriptions, try a simple LLM call with good prompting

• For a single task like SQL or code generation, use a specialized model with structured output

• For a multi-step but predictable flow like email classification plus response drafting, create a hardcoded workflow with LLM steps

Although PostHog AI is an agent now, we validated demand for it with a simpler use case and system. We built a workflow for data-related questions like “How many people signed up last week?” which lead directly to insight generation.

Only once this workflow saw adoption and users demanded other use cases (like answering docs questions or creating feature flags) did the team build an agent.

2. Your harness is not your moat

Once you decide to build an agent, the next question is how will it work. The answer to this is an agent harness: the code and infrastructure that combines with a model to help it understand and use your product.

You aren’t going to win because you’ve created some genius new harness, especially if you’re building your first AI agent. Don’t use innovation points here. Anthropic wrote a perfectly good SDK, and both Anthropic and AmpCode have helpful guides.

If we were restarting today, we would have skipped building a custom harness and made MCP the canonical interface. We learned this the hard way through three iterations of PostHog AI this year.

The first harness was a coordinator that routed user messages to specialized sub-agents, but this created a black box problem as the coordinator couldn’t see what sub-agents were doing leading to context loss and confusion.

The second was a single agent loop with self contained modes and tools within each mode. This solved the visibility issue, but didn’t scale. If we didn’t write a tool, the capability wouldn’t exist. This led us to spending a lot of time writing tools (44 by the end) rather than improving in other ways.

Our third and current harness uses the Claude Agent SDK with MCP tools and skills. This change came from two realizations:

1. Our agent could be more creative. The Claude Agent SDK gives PostHog AI access to a code-execution sandbox. The agent can use it to query with SQL and run custom scripts, unlocking new capabilities without us needing to build them.

2. Agents are a primary persona. Our “users” are increasingly agents, whether that is through PostHog AI or our MCP server. Our work here should converge and support both using a single architecture.

The flexibility of the sandbox plus the scalability of MCP tools and skill standards (which I’ll explain more about later) solves the issues of the second harness and positions us better for an agent-first future.

3. Your context is your advantage

When building an agent, there’s ultimately one question you need to answer to succeed: How does this beat Claude?

Context is the most important part of an answer. The combination of your app’s functionality and user data create a unique blend no other product can match.

Although you have product and user context sitting around, you need structure and format it to be useful for the agent. We do this with:

1. MCP tools. Capabilities selected and extracted from the PostHog API to expose all possible actions that agents can perform in PostHog. Examples include list feature flags, create a survey, or execute an SQL query.

2. Skills. Markdown files we write to teach the agent complete workflows and how to use our product. These include query patterns, system table schemas, examples, and MCP tool references. They are templates rendered at build time, so they can pull live context from the codebase like model schemas.

3. Layered runtime context injection. The frontend sends the user’s current view and state such as dashboards, insights, session recordings, and filters. This is enriched with actual queries results and project metadata like timezone and organization name.

4. A taxonomy tool. This lets the agent explore the user’s event names, properties, and property values on demand rather than stuffing them all into the prompt upfront.

5. A memory onboarding flow. This collects company and product context through conversation and persists it across sessions, so the agent builds understanding of each user’s setup over time.

Without this structured product context, the agent struggles to understand both our product and the user’s goals. It can get lost on simple questions because the context behind those questions is complex.

Reality has a surprising amount of detail and people define tasks in ambiguous ways. How would you answer “where do users drop off in CFMP1 conversion” without context?

4. Set up observability and evaluation from day one

These are essential as AI agents are non-deterministic and can fail in unpredictable ways. Without visibility into this, you can’t improve them or catch regressions.

We didn’t have observability and evaluation early and regretted it. We wish we had:

• Tracing for every LLM call with inputs, outputs, latency, and cost

• Trace IDs that span the full conversation

• The ability to replay and debug specific interactions

• A curated datasets of real user queries

• Automated scorers like LLM-as-judge and deterministic checks

Basically, LLM analytics.

Unfortunately, LLM analytics alone isn’t enough. Reality is gnarly and to deal with it, our team often looks at real usage.

They run a “traces hour,” where they meet, manually analyze LLM traces (AKA real user interactions), and find areas to improve. Evals make the most sense when they stem from these investigations.

Like building any successful product, understanding a user’s experience is critical to building a successful agent.

5. It doesn’t matter how cool your capabilities are

After getting buried in technical details, it’s important to poke your head out and remember who you’re building for. You’re not building for some hypothetical “coolest AI agent” contest, you’re building for your users.

What users want is often at odds with what’s coolest. The most common pain points users faced weren’t our agent’s range of capabilities or functionality, but things like:

• Inconsistent performance

• Unexpected failures

• Generic error messages without clear explanation

• Unclear capabilities leading to complex queries failing

• Lack of signs of uncertainty, source of insights, and progress

While new capabilities are cool, ensuring your agent actually solves your customer’s problems is even cooler. Ultimately, building an AI agent is not just a showcase of your AI skillz, but a product engineering problem. This requires you to talk to users, ship features they want, and iterate.

Words by Ian Vanagas who has plenty of agentic capabilities himself if you ask nicely.

🦔 Jobs at PostHog

Unlike many AI companies, we don’t think agents are going to take over every job in the next 6 months. In fact, we’re hiring!

• Product Engineer

• Security Engineer

• FinOps Engineer

• Technical Account Manager

• Forward Deployed Engineer

📚 More good reads

• How we built automatic clustering for LLM traces – Andy Maguire

• MCP is Dead; Long Live MCP! – Charles Chen

• Production Telemetry Is the Spec That Survived – Vidhya R.

• You Need to Rewrite Your CLI for AI Agents – Justin Poehnelt

• 8 learnings from 1 year of agents – Michael Matloka

We’ve seen this first-hand at PostHog, but it’s not an isolated trend. The lines between product management and engineering are blurring, too.1

Thanks to LLMs, figuring out what to build is now a greater bottleneck than how to build it, and it’s forcing engineers to think more like product managers (PMs).

In this issue, we’ll help you take advantage of what product managers have already figured out by going over the top three skills in their playbook.

1. Gather the right context

Providing context is a product manager’s most important job.

What exactly do we mean by context? In the same way that sailors used to navigate by the stars, engineers depend on context to make the right product decisions.

Good context points teams in the right direction; great context can change a company’s entire trajectory.

Take Duolingo for example.

In a guest edition of Lenny’s Newsletter, Duolingo’s Head of Product, Jorge Mazal, recounted how the company fixed its stalling growth problem. The team initially focused on friend referrals, premium trials, and in-game mechanics. Nothing worked, and daily active users (DAU) continued to decline.

But then Mazal and the data science team discovered that current user retention rates (CURR) were 5x more impactful on DAU than any other projected metric. That single piece of context completely shifted the product roadmap.

Instead of trying to acquire new users, the team invested in keeping existing learners hooked with leaderboards, daily streaks, and – of course – passive-aggressive push notifications from everybody’s favorite lime green owl.

Four years later, Duolingo successfully exited with massive 4.5x DAU gainz.

Product metrics like CURR and DAU in Duolingo’s story are just one form of context. There are many more, such as:

• Competitor landscape. What are our competitors doing, and should we do that, too? In an interview with TechCrunch, Instagram’s CEO described how the company copied and outperformed Snapchat Stories in 2016.

• User research. What do prospective users say they want? Buffer interviewed 30+ content creators to discover what people actually want from creative AI assistants.

• Industry news. What’s happening in the industry that we should pay attention to? When generative AI took off in 2023, Canva turned it into its core feature and doubled revenue in two years ($1.7B → $3.3B).

• Customer feedback. What do current customers say they want, and is it actually what they want? When Linear users requested “custom fields”, they dug deeper and built Customer Requests to track support tickets, Slack messages, and calls.

Gathering context can be difficult since it’s not always obvious what information is useful at any given point in time.2 You could spend weeks analyzing bug reports to improve feature adoption, only to realize after one user interview that it was a discoverability problem all along.

The good news is that you can develop an intuition for this by tracking what types of context led to measurable success through accountability loops (we’ll cover what that looks like in the next section).

Takeaway for engineers

Don’t wait around for someone else to give you the right context for your product. Instead, generate it yourself by creating your own systems for discovery.

In addition to helping you ship faster, this gives you an unfiltered view of the data. For example, talking to users provides clearer insight than reading secondhand notes from your PM since information gets lost at each step along the way:

Another reason engineers should do this is that your teammates might not understand the technical options and constraints as well as you do. Sometimes only the person with the full context of a problem can ask the right questions.

Try this: Book 2 user interviews per week. Run a feedback survey for your product and review survey data every sprint. Set up an LLM eval that detects when users struggle. Create a weekly email digest for competitor blogs.

2. Track success with feedback loops

All that context is useless if your team doesn’t know if they’re winning.

Product managers at PostHog track and ensure success3 by running growth reviews: monthly meetings where they go over revenue trends, user feedback, usage metrics, and quarterly goals with the engineers building the product.

If the numbers aren’t moving in the right direction, the PM presents a well-researched explanation to the team so that they can come up with an informed hypothesis and solution:

When the team meets again in the following month, they’ll review what worked and what didn’t. Each iteration levels up the product – and the team’s product sense, too.

Here’s an example from our Error Tracking team:

1. The problem: Cory, the PM, noticed that churn rates were disproportionately high, even though new customer acquisition was strong.

2. The context: A series of customer interviews all pointed to the same theme: trust. Users were leaving because of rough edges, such as missing recordings or unhandled stack trace edge cases.

3. The hypothesis: This is a product-quality problem, not a “missing features” problem. Systematically improving papercuts, ergonomics, and reliability will reduce churn.

4. The solution: The team catalogued every trust-related issue from customer feedback and shipped dozens of fixes (see below). Churn improved from 21% to 10% in the following quarter.

Without Cory’s investigation, the team could have easily spent months on new features that they thought would solve the churn problem, without addressing the root cause.

Feedback loops like these create accountability and, in turn, give developers more autonomy. Engineers at PostHog can make product decisions more freely (without PMs micromanaging roadmaps) since the system ensures they’re always contributing to the company’s bottom line.

Takeaway for engineers

You can turn every sprint into a mini growth review by setting aside time to define and evaluate success in each session.

We do this at PostHog by classifying each milestone with one of the following:

• Nailed it: We hit the goal spectacularly. High fives all round.

• Scraped it: We almost hit the goal, but we need to do a bit more to tidy up.

• Failed it: We were nowhere near hitting the goal, but we learned some valuable lessons. Back to the drawing board for this one.

This ensures we’re learning from each cycle and not just shipping mindlessly. It’s way more useful than just marking tasks as “Completed”.

Try this: In your next sprint, apply the concept of feedback loops by defining and evaluating success for each task. Then in the next sprint, review if you met those goals (and if not, what you learned or how you’ll follow up).

You could run an A/B test to compare behavior between groups, test early prototypes to get user feedback, dogfood your product to get internal data, or message a customer to see if you addressed their issue.

3. Communicate towards action

To make all of the above actually work, you need to make communication actionable. We know this sounds like classic PM fluff, but give us a minute to explain.

It’s easy for anyone to state a problem:

“We’re losing enterprise deals to competitors because we’re missing features.”

But this doesn’t help engineers understand what to build or why.

Communicating towards action looks like:

“We’ve lost five deals worth $200k in the last three months over SSO, audit logs, and role-based permissions. We should prioritize these over shipping v2 of the MCP for our core segment since we already have strong retention there. The enterprise requests are more aligned with company-wide goals for Q2.”

This is better, but why? It reduces friction by surfacing important information from the start:

• Stating the impact. Not “we are losing deals”, but “we lost three enterprise contracts.”

• Being specific. They don’t just state that features are missing; they investigate and list the top three.

• Sharing relevant context. The revenue loss, strong core retention, and the Q2 company-wide goal are all factors that will help make the decision.

• Making trade-offs visible. The former doesn’t mention competing priorities; the latter points out exactly what to choose between.

• Having an opinion. Instead of just vaguely asking “Thoughts?”, they express which option they think is better and why.

This is where all three skills come together. Product managers know what information to provide thanks to all the context they’ve gathered and feedback loops they’ve experienced. And how they deliver it – by communicating actionably – makes all the difference.

Takeaway for engineers

Since action is the goal, it’s best to default to shipping when you can. That’s why pull requests are the S-tier form of communication at PostHog. (Email is F-tier, obviously.)

But when the next step is unclear and you need to bring it up for discussion, work backwards. Think about what types of context and success criteria a PM would provide to make the information as actionable as possible.

Try this: Next time you’re about to post “should we do X?”, make it actionable by including:

1. The specific problem and its impact

2. What you’ve already investigated

3. At least one other option and the trade-offs

4. Which one you’d pick and why

Words by Jina Yoon, reformed PM who once learned the dark arts and now shares the secrets with you.

📚 From the library

• Your Best Thinking Is Wasted on the Wrong Decisions – Ian Duncan

• Product Management is Communication – Ben Yoskovitz

• How close is AI to replacing product managers? – Lenny Rachitsky & Mike Taylor

• A GitHub Issue Title Compromised 4,000 Developer Machines – grith.ai

• How we built automatic clustering for LLM traces – Andy Maguire

🦔 Join the prickle

• Product Engineer

• Sales Lead

• Application Security Engineer

• Dev Advocate (YouTube Team)

• Mobile Engineer

Spend enough time in startup circles and you’ll hear this engineeringification of everything:

“Oh, I’m a design engineer”
“We’re following best practice of GTM engineering”
“I need to talk to their sales engineer about implementation”

This raises two questions:

1. Why is every role becoming an engineering one?

2. Should I be worried?

This post answers both of these.

The engineeringification loop

The spread of engineering tools, skills, and identity into non-engineering roles, AKA “engineeringification,” is driven by a feedback loop that looks like this:

Take the role of design engineer as a specific example:

• Design tools get more powerful. They’re not just for wireframing. Tools like Figma, Tailwind, and design systems baked into frameworks mean decisions shape production code. A button goes from being “just a rectangle” to a set of responsive, accessible variants that fit with your existing system.

• Using them is complicated. Fully leveraging a design tool like Figma or a framework like Tailwind requires understanding product features, configurations, syntax, hotkeys, best practices, limitations, and constraints. At some point, you might even need to read the code.

• Non-technical people learn anyway. Because engineering time is scarce and iteration speed matters, designers learn enough to ship. LLMs make this easier: they can generate Tailwind components, UIs, or even prototypes rather than hand-coding them.

• Skills accumulate and identity shifts. At some point, the designers stop handing off work and do it themselves. They ship product code, debug layouts, and make tradeoffs between design and performance. Calling this just “design” makes less sense.

• A new identity emerges and startups latch onto it. The label appears: design engineer. Power users adopt it, companies like Vercel start hiring for it, and tools begin marketing to it. The loop restarts, now with a clearer identity to build around.

Tools change skills, skills reshape identity, and identity demands new tools.

Why is engineeringification happening now?

People have been building powerful tools for many roles for a long time now. What makes this time different?

1. LLMs make it possible

LLMs make complex, domain-specific tools more accessible. Seemingly every tool has an AI assistant, an MCP server, or an AI-powered alternative.

Non-technical people can learn how to use the powerful tools once exclusive to engineers faster and easier. With them, they can:

• Generate apps and prototypes with tools like Lovable, v0, and Claude Code.

• Automate and optimize go-to-market with tools like Clay, Pocus, Vitally, and Lemlist.

• Build and configure workflows with PostHog, Make, and n8n.

2. Capital makes it inevitable

Engineeringification is a good business (we know because we’re in it). It’s where B2B SaaS is heading as companies are willing to pay for it, VCs are willing to invest in it, and playbooks for success exist.

You can see this reflected in the growth and valuation of AI-powered B2B SaaS startups serving non-engineers like Sierra, Lovable, Fin.ai, Bolt.new, Decagon, Clay, and Replit.

The capital flooding into the space improves the tools, provides users more capabilities, encourages new startups entrants, and increases marketing toward the engineeringification of identities.

3. Identity makes it permanent

The final driver of engineeringification is identity. Once people start seeing themselves as engineers, the loop becomes self-sustaining.

You don’t have to look far to see this shift in action. YC job posts show how non-technical roles are increasingly engineering focused:

Engineeringification gives individuals new autonomy while saving engineers time. Success encourages non-technical people to expand their skills and use the tools more. As they spend more time on engineering-like work, they begin to identify less with their old role as it undersells the value of their work and how technical they are.

Instead, people identify more with what they’re building and the people who build (AKA engineers). This new identity eventually crystallizes often via blog post, conference talk, meetup or even tweet. Think Andrej Karpathy on vibe coding, Anthropic hiring a prompt engineer, and Vercel promoting design engineering.

New identities compound the loop: people adopt it, tools are built for them, and marketing reinforces it. This feeds the cycle all over again.

The meaning of engineer is changing

What it means to call yourself an “engineer” is a sensitive topic. It’s literally illegal to call yourself one without accreditation where I’m from.

Engineering once meant a specific set of skills in a bounded domain reinforced with formal training and gatekeeping. This remains true in physical domains as failure has physical consequences, but software’s low cost of failure makes gatekeeping harder to sustain. Boundaries are eroding.

The defining line of engineering is moving away from “who is allowed to build” toward “who has the ideas and dedication to actually build it.” It’s less about knowing all the theory and more putting it into practice.

To some, this looks like a loss. Engineering feels deprofessionalized: more self-taught practitioners, less depth, titles lose meaning.

For many more, it’s a gain: more autonomy, faster iteration, increased leverage and a better ability to ship solutions to real, valuable problems.

Should you be worried?

The line between technical and non-technical work isn’t disappearing, it’s being redrawn. Whether you’re an engineer or not, the winners will be those who think like builders:

• For non-technical people, don’t be afraid to take on more “engineering” tasks. Tools have become more powerful and specialized and people like you are succeeding in using them. The combination of LLMs and MCP have made it easier to both learn and interact with more tools.

• For engineers, congrats! The world is investing a ton in making YOU more powerful. Use these same tools to turn yourself into a full stack shipping machine AKA a product engineer. For example, you can use Exa for competitive research, BuildBetter for user interviews, Figma Make to design a UI, and PostHog AI to analyze your product usage.

• For startups, build for these new types of engineers. At a minimum, let people do engineering: have an API, make your docs machine readable (I love a “Copy as Markdown” button), publish an MCP server, and connect with other tools.

Those who embrace the engineeringification of everything will find themselves riding the wave it is creating. The billions trillions invested here has to benefit someone. Why not you?

Words by Ian Vanagas who, after all this, is still a bit skeptical of the “content engineer” role.

🦔 Jobs at PostHog

We’re hiring for many kinds of engineers (and almost engineers) like:

• Product Engineer

• Technical Account Manager

• Software Engineer – AI-Enabled Product Autonomy

• Product Manager (ex-founder or ex-product engineer)

• SRE – Clickhouse Team

📚 More good reads

• WTF is a forward deployed engineer? (and why everyone is hiring them) –

• Spinning the Wheel – Dylan Martin

• How I do user interviews – Paul D’Ambra

• The startup interview questions that actually matter – James Hawkins

• The Rise of the GTM engineer – and

• The Rise of the AI Engineer –

📺 PostHog on YouTube

Are you asking the right questions in interviews? James Hawkins argues not.

Is it possible to ship too much – or too fast?

Yes. Probably. Unfortunately.

A handful of people with good judgment and a lot of tokens can now do what used to take a full product org. As a result, software powered by LLMs is cheaper to build and scaling faster than at any point in history.

Once you cross a certain threshold, however, product velocity stops compounding and starts competing with itself. You’re no longer constrained by your capacity to ship new things, but by your users’ capacity to adopt them.

As a company that’s obsessed with shipping fast, we’re acutely familiar with this problem, so I’m sharing how we’re solving it, so you can too.

The Theory of Constraints

Since PostHog is a work tool – not a lifestyle brand – even our most enthusiastic users won’t adopt an infinite number of new things per week.

In practice, B2B SaaS users tend to adopt:

• One big new thing every few months

• A couple of medium improvements

• A handful of small quality-of-life upgrades

Everything else gets ignored until someone explains why it matters. This is a classic bottleneck.

Luckily, bottlenecks have solutions. Manufacturers discovered this and crystallized it in a concept called Theory of Constraints (TOC). There’s one principle of TOC that is particularly relevant here:

When upstream output increases without increasing downstream capacity, the system destabilizes.

In our case:

• Upstream we have 40+ small teams working asynchronously, shipping at a high velocity, and AI accelerating productivity.

• Downstream we have limited user attention, comprehension, and engagement capacity.

Recognizing this, TOC can again help us understand the consequences of this mismatched capacity:

1. Queue buildup

In manufacturing, this looks like excess inventory. In software, this creates an invisible backlog – work that’s finished on your side, but unfinished in terms of user awareness and understanding.

The result is diffuse impact: lots of progress shipped, but less progress felt.

2. Time-to-value increases

As that backlog grows, the gap between production and adoption stretches. Your team keeps shipping code, but each new capability takes longer to move from “available” to “useful.”

Users struggle to keep up with what’s changed. Support and sales spend more time explaining context. Marketing lags releases instead of amplifying them.

3. Quality degradation

When a bottleneck is overloaded, quality degrades through forced tradeoffs.

In software, that shows up as:

• Partial adoption instead of full behavior change

• Misunderstood capabilities

• Features used narrowly when they were designed to be foundational

Your product keeps getting bigger and better, but not proportionally clearer.

Does that mean you should slow down?

Definitely not.

Slowing down is what companies do when they run out of ideas (and clearly that’s not the problem). Fortunately, Theory of Constraints is quite explicit about what not to do here:

Improving non-bottlenecks is a waste of resources. You improve the system by elevating the bottleneck.

Product adoption happens one human at a time, and each individual user has a finite amount of mental bandwidth. So the real question isn’t whether to slow down, it’s this:

How do you elevate adoption without killing velocity?

How to address the real bottleneck of user attention

If you’re building anything serious (and using AI to increase throughput), you’ll hit this wall eventually.

At PostHog, we’re still figuring out the best way around it, but a few points are now painfully obvious.

1. Treat attention like a scarce resource (because it is)

Small autonomous teams naturally optimize for their slice of the product. They own a feature and make it better.

Users don’t experience a product that way. They’re hit with every product change through a finite amount of attention they’re willing to spend.

That mismatch is where things start to break.

What failure looks like:

You treat launches as outputs instead of outcomes.

You see this when companies (especially startups) excitedly announce every new feature, and when changelogs or emails become the main way users are expected to keep up.

There’s only a limited amount of attention these methods capture. Ship fast enough and even engaged users will start showing feature fatigue.

If you’ve ever heard “I didn’t know you could do that” from a long-time customer – congratulations, you’ve shipped past the speed of adoption.

Do this instead:

Keep shipping, but be aggressively opinionated about what matters right now.

Not everything needs a launch, a blog post, or to be explained immediately.

Define a launch tier framework such as:

1. Category definers: New product rollouts or major designs that change how customers think about your category. Require full company alignment. For example, PostHog AI.

2. Strategic upgrades: Meaningful product improvements (not redefinitions) that don’t require the full machinery of a major campaign. For example, PostHog Logs launch.

3. Steady improvements: Standard product development that doesn’t require coordination beyond the product team. For example, LLM Analytics adding time to first token.

This is where brand helps. Things like humor, narrative, and deliberate absurdity work because they lower the cost of paying attention. Partnering with influencers that own trust with your ICP is another way to extend mindshare beyond your brand channels.

What this looks like: Notion ships constantly, but markets selectively. Many features land with almost no fanfare, while a small number (AI, databases, templates) get sustained narrative investment over months.

2. Build discovery into the product

If realizing value requires explanation outside of the product, you haven’t removed the adoption bottleneck – you’ve just moved it downstream to marketing, sales, or support.

Users don’t wake up wanting product updates. They’re trying to get something done and move on with their life.

That’s why feature discovery strategically tied to intent works better than announcements that land out of context.

What failure looks like:

Relying on external channels for discovery is brittle. As Andrew Chen argues in Every marketing channel sucks right now, most channels are noisy and saturated. And despite the internet clout you may think it awards, focusing your efforts on Product Hunt, G2, or Hacker News probably isn’t worth the investment.

Your owned channels can easily make things worse. You’ve no doubt been a victim of generic product emails without meaningful segmentation (”why did I receive this?”) or a disruptive in-app experience full of tooltips, banners and popups.

Worst of all are launch videos or press releases that promise “revolutionary” outcomes but don’t clearly explain what changed in the product. Marketing features over benefits is a good pattern breaker, but be warned: too much focus on “what” rather than “now what” makes product adoption someone else’s problem.

Do this instead:

Surface features when they’re relevant to what the user is already doing.

Start by defining clear activation criteria – the signals that indicate a user is engaged with certain parts of your product. Once you discover these signals, you can anchor new features to tasks users already care about.

For example:

• When a HubSpot user captures 10+ leads, lead scoring tools gets surfaced

• When an Asana user creates a second project, the team invitation flow triggers

• When a Zapier user has run multiple successful automations, multi-step templates are emphasized

Another name for this is continuous discovery: letting user behavior and feedback influence what gets amplified next.

Emails and tooltips can help here, but only when they’re contextual: “you’re using X, so Y might be useful.” Better is adding features to existing habit loops, encouraging users to build new habit loops with the features, or making the features sharable.

What this looks like: Atlassian famously struggled with feature sprawl across Jira, Confluence, and their other products. Users couldn’t keep up with so much surface area. The solution wasn’t more marketing, it was investing heavily in in-product discovery, clearer use-case documentation, and opinionated defaults to guide users to success.

3. Measure learning, not just usage

Product adoption isn’t only about feature usage, it’s about helping users get better at their jobs because those features exist. That’s why a lot of our content marketing isn’t really about PostHog at all – it’s about how to become a product engineer.

Sharing knowledge and being helpful builds trust and brand recognition in a way feature announcements never will.

What failure looks like:

When teams get this wrong, they focus on vanity metrics, push product teams toward being a feature factory, and publish content that only makes sense if someone already cares about the product.

One of the biggest mistakes you can make is believing other people care about the product as much as you do.

They don’t.

Do this instead:

What works better is publishing things that are useful even without your product:

• Real learnings, like how we built our AI setup wizard

• Internal knowledge turned into public artifacts

• Honest writeups like postmortems for incidents

Even better, teach the domain you operate in – not just how your product works. Figma, for example, teaches people how to be better designers, not just how to use Figma.

Events are another great tactic to build a community adjacent to your product. For example, Lovable’s SheBuilds hackathon encourages more women to try vibe coding.

What this looks like: HubSpot pioneered inbound marketing by teaching people how to be better marketers before selling them software. For many young professionals, that learning happened years before any purchasing decision – and by then, brand equity was already baked in.

Fast, not frantic

It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what you ship, it’s not velocity, it’s waste.

Practically, that means being explicit about what actually deserves attention – and just as explicit about what doesn’t.

So when should you market a specific feature?

• It changes a core workflow, not just adds another option

• It compounds with an existing behavior (and you can surface it in-context)

• It has a clear “aha” moment you can design for

• You’re able to support it with docs, onboarding, and follow-up content (not just a blog post)

Everything else should move through the system quietly, without competing for attention it doesn’t need.

Product velocity only compounds when adoption keeps up. If user attention is the bottleneck, your job isn’t to slow down – it’s to be selective. Make a few things loud on purpose, and let the rest be quietly excellent.

Words by Cleo Lant who prefers light mode for most SaaS products (sue me).

🦔 Jobs at PostHog

Want to join a team that’s shipping this fast? We’re hiring:

• Product Engineer

• Software Engineer — Warehouse Sources

• Founding Talent Sourcer

• Software Engineer — AI-Enabled Product Autonomy

• ClickHouse Operations Engineer

📚 More good reads

• An overview of Theory of Constraints

• Your logs’ final destination is in GA. You always end up here anyway - Sara Miteva

• The MKT1 Field Guide to B2B startup marketing -

• Behind the scenes of a PostHog hackathon -

• Hypergrowth isn’t always easy - Avery Pennarun

Your company is your people, and your job posts are how you find them. Yet most founders treat them like paperwork.

At PostHog, we’ve taken a different approach, and it’s worked. Our job posts have attracted tens of thousands of candidates, consistent praise, and ultimately, the talented team we now have.

Here’s everything we’ve learned about writing job posts that attract 10x talent.

1. Include real projects

The most powerful thing you can do is to give candidates a taste of what they’d actually do at your company.

Instead of rambling on about the job responsibilities, include a list of sample projects.

For example, Cursor posted these sample projects in an infra Software Engineer role:

• Creating a retrieval system that processes 10,000,000,000+ files

• Staring at esoteric flame graphs to performance engineer our reranking library

• Working with many databases, proxies, caches, task queues, and orchestration systems

• Shipping infra for safely computing import graphs and shadow lints

Lovable’s current open Platform Engineer position has a couple as well:

• A runtime environment for running AI agent workloads in a secure, scalable way.

• High throughput Sandbox scheduler across multiple cloud providers.

You can take it even further and add links to actual PRs if your company is open source. At PostHog, we often add public examples of work you might do, like in this DevEx Engineer post:

• Hogli, a unified CLI for PostHog developer workflows

• Django migration safety checks and guide

• Upgrade Django to 5.2

This has a hidden benefit for your team, too. It helps you focus your evaluation on real work rather than just credentials and experience.

The takeaway: Real projects help people see if they’re actually interested in the work, not just qualified to do it.

2. Say what’s in it for them

Perks are nice. Transparent compensation is even better.

But the ultimate thing that’s going to convince another cracked engineer to come work with you is work they’re excited by. Some examples:

• Impact from day one: You’re building agents on top of real customer data — not toy demos, not “when we get users” (AI Product Engineer, PostHog).

• You will engage with the open-source community and participate in discussions, aligning with our commitment to giving back to the developer community (Software Engineer, Vercel).

• We also own a $5M H200 GPU cluster that regularly lights up tens of thousands of machines (Software Engineer, Exa).

• Massive reach: Our docs platform serves 100 million+ developers every year and powers documentation for 18,000+ companies, including Anthropic, Cursor, PayPal, Coinbase, X, and over 20% of the last YC batch (Product Engineer, Mintlify).

• Autonomy: We have very few meetings. Just a Monday and a Friday to go over the Company Board. We think your time is sacred, whether it’s at work, or outside of work (Senior Full-Stack Engineer, Railway).

Talk to your current team and ask what made them join. Those answers are what belongs in your job post, not your mission statement.

The takeaway: Ambitious people are looking for places to learn, grow, and find fulfillment, not just collect a paycheck. Your value prop is the work, culture, and equity – sell them!

3. Avoid generic job titles

Generic job titles attract generic candidates.

For months, we had trouble hiring a product marketer. We got hundreds of applications from people who had been product marketers at other companies, but their experience was a bit too corporate for us.

It wasn’t until we changed the title to Developer Marketer that we started getting the right kind of candidates. Developers who could write, marketers who could code, the weird generalists we were looking for.

We do this now for a lot of roles like “Developers who love teaching” for the docs team, or “Developer who organizes events” for an event marketer.

One of our current openings is for an ad copywriter. The last thing we want is someone who writes “unlock growth” or “leverage your data stack”, so we’ve named it Propagandist to capture the unhinged energy we want to find.

This helps filter out people who want more traditional roles (nothing wrong with that, it’s just not what we do). More importantly though, it gets the M- and T-shaped people we want more excited and likely to apply.

The takeaway: Every job title comes with baggage. You’ll attract the unconventional candidates you want by clarifying what makes the role unique.

4. Detail your interview process

Everyone’s heard a story of a dreaded 10 step interview process with multiple on-site interviews and (unpaid) take home assignments that ends in a company ghosting them without an offer.

This nightmare scenario is what every candidate thinks your interview process is like if you don’t tell them.

Talented people are busy. Being transparent about your interview process respects their time. Some examples include:

• Supabase details their “simple, async-friendly” four step process, the bulk of which is up to four calls with the founders and future teammates.

• We, at PostHog, have a four step process with culture, technical, and founder interviews, then our paid ($1000) SuperDay of work.

• Railway also has a six step process with async project work and review, interviews, and a chat with the CEO.

This has the added benefit of forcing you to clarify and be accountable for your interview process, and provides a good first impression of your company values.

The takeaway: Clarifying, then including your interview process has a huge impact on candidate experience and makes your role more accessible to talented (but busy) potential hires.

5. Treat job posts like marketing

Job posts are often someone’s first impression of your company.

This is especially true in early stages. There’s a good chance your LinkedIn job ad is literally your most-viewed piece of content. Every view is a chance to build your brand to a potential customer, investor, or teammate, so you need to stand out.

The same rules for marketing copy apply here - lead with your value prop, skip the jargon, and write with personality.

The creators of Bolt.new do this well in their intro for this Full Stack Engineer role:

We’re StackBlitz!

We’re the team behind WebContainers, the groundbreaking technology that made it possible to run Node.js right in your browser. No installs, no setup, just instant dev environments. That innovation kickstarted our journey in 2019 and powers the blazing-fast online IDE used by over a million developers every month.

But we didn’t stop there.

We took everything we learned from building WebContainers and used it to create Bolt.new.

At PostHog, we keep that energy going throughout the entire post:

• You love getting things done. Engineers at PostHog have an incredible amount of autonomy to decide what to work on, so you’ll need to be proactive and just git it done (Platform Engineer, PostHog).

• Have created short-form videos (TikTok, Reels, Shorts) for companies. We don’t think most dance trends are relevant to B2B SaaS, but it would be helpful if you could confirm that for us (Social Poster (in chief), PostHog).

• Implementing AI features. LLMs, eh? They’re getting prettaaay, prettaay good. All our products integrate with PostHog AI, so you’ll likely be working with the PostHog AI team to implement AI features in your products (AI Product Engineer, PostHog).

Write these like how you would talk to a friend. Add what makes you unique. Lean into being super technical (or super weird). Brag a little, but not too much. Mention your traction, the money you’ve raised, and a bit of background, not your CEO’s high school pedigree. Make a joke; we say our founder interview is the “final boss”.

The takeaway: More people will read your job post than your landing page. Make it count.

Words by Jina Yoon, who applied to one of these job posts recently.

🦔 Jobs at PostHog

We’re biased but we’re proud of our job posts. Check them out (and apply):

• Product Engineer

• Founding Talent Sourcer

• Software Engineer — Warehouse Pipelines

• AI Product Engineer

• Forward Deployed Engineer

📚 More good reads

• Why We Built Our Own Background Agent - Ramp

• No management needed: anti-patterns in early-stage engineering teams - Antoine Boulange

• Stop AI slop: Run evals with LLM-as-a-Judge - Cleo Lant

• Hiring (and managing) cracked engineers - Charles Cook

• How to get a job at a startup - James Temperton

I’ve talked with people who have scaled some of the most successful software companies in the world and built tools that millions use every day. What I learned from them has fundamentally changed how we do things at PostHog.

I also increasingly have people asking me for advice about what they should do with their company. The main thing I’ve learned from both sides of the conversation is that getting good advice doesn’t just happen. It’s a skill.

These are the things I do to get good advice.

Be intentional and cast a wide net

My process is:

1. Pick a topic where I have ideas but not strong conviction about what to do

2. Find 4 people who have done that thing successfully

3. Either get intros or cold message them on LinkedIn

You need to talk to multiple people because they will all say different things, even if they worked at the same company. Pick companies that serve a similar ideal customer profile. If you are building a devtool, get advice about sales from someone at GitHub, not LinkedIn. If you are product-led, talk to someone from Figma, not Salesforce.

Cold messaging works because people are nice, but you need to a) have mutuals, and b) ask a specific question. Don’t say “I’d love to pick your brain” – a specific question from you lessens the mental load for them so they can be helpful.

Here’s basically the message I send:

Hi ____, if you have a minute to share some wisdom with someone building the sales machine at a heavily product-led company, I’d love to get your thoughts!

I lead the commercial teams at PostHog (joined as first non-eng hire), and we’re scaling up across sales, CS, demand gen, etc. fast.

One thing I’m trying to figure out is what our first BDR hire should look like – someone who has built a function before and knows what they’re doing, or a less experience/more cracked IC type who will just try things? Or something else entirely?

If you don’t see this no worries – huge fanboy of how you guys scaled [insert personal, genuine reason why you admire their work]

“But Charles, that won’t work for me – I’m not a fancy generic exec person like you are!”

Maybe I’m weird, but I hop on calls with people I don’t know about once a week to give them advice. Usually the ones I’ve said yes to have done similar to the above – if your story resonates, people will want to help you out.

Here’s an example of a message I received a couple of weeks ago that led to a call:

Hi Charles,

My name is ______. I recently applied to (and was then rejected by) PostHog. Sucks, but all part of the game. I’m reaching out because in my research of PostHog (I research every startup I apply to, I am still lucky to have the luxury of choosing where I apply to), I came across your website and writings and I became hooked, I especially loved your dictator or tech bro game, that was amazing, I think you need to introduce some quotes from Gurbanguly Berdymukhammedov (Turkmenistan’s dictator) because that guy is wild – here is a link to a last week tonight episode about him but careful because Turkmenistan is a youtube video rabbit hole.

Anyways. I really resonated with how you entered the world of startups and I am trying to do the same (I am a very new corporate lawyer, who is trying to leave the field all together) and was hoping I could get a few minutes of your time so that you could get give me some advice on breaking into the world of startups and so that I may ask you a few more questions about your “What startup recruiters actually see when you apply for a job” article.

Thank you so much for your time and for the great content you create!

Ask the “right” people

How do I know that people have done something successfully? Sure, LinkedIn, but that doesn’t give the full picture…

Honestly – I can’t really know! But I still learn something useful in every call:

• Sometimes, the person just validates that you are doing the right thing

• They may have made a bunch of mistakes, which is still great – now you can avoid making them

Generally, I’ve found that the most helpful people have done a decent stint – i.e. 5+ years at a good company. 5 years is long enough to genuinely help build something, and people who aren’t good generally get found out before then.

If they’ve collected 18 month stints at a bunch of cool companies, they may still be good, but they’ve left too quickly to ever really get found out. Generally, I’m looking for people who have been leaders at companies I admire and have 15+ years of overall experience.

Do some legwork

Once a call is set up, I write a one pager that summarizes where we are at and outline 3-4 questions I’d like to ask. I share this with them before the call. Here’s an example of what it looks like.

This is the single most important thing I’ve done to get better advice. Do not just turn up and start talking.

A one pager:

• Saves you precious time on a call telling someone all about your business they just heard about

• Helps you clarify and focus your thinking on what really matters

• Shows you are a person to take seriously

Here’s a template I use:

Summary
- Where our company/function was
- Where our company/function is today
- Where we’re heading in the near future

Team
- What the team looks like 

What we need help with
- Specific questions

Call notes
- 

When it comes to the questions, the best approach is to pick a specific area but ask for their general take or mental model. Don’t ask them how to solve a specific problem – you’ll never give them enough context and they’ll feel obliged to say something anyway. People are nice and don’t want to say “you have to figure that out for yourself.”

The person I am talking to may have already spoken about these topics in an article they wrote or an interview they did, but I don’t worry about that. If I’m trying to get in touch with someone because they were on Lenny’s Podcast, they are probably too busy/famous to talk to me anyway!

Start closer to home

If it’s an option, your own team can be a great source of advice! For example, I went through a period of interviewing every new sales hire about a month after they joined PostHog to get as much specific, detailed information out of them.

Here’s a template you can use:

Your background
- Tell me about the most successful _____ team(s) you have ever been a part of
- What were the specific things that made them successful?
- What were the processes? Team personality traits? Training?
- What were the mistakes you made?

At PostHog
- What are the things you think we are doing well as a ____ team?
- Why do you think we would fail to achieve our goals?
- What are 3 things we could start doing tomorrow that would make a difference?

You don’t really need to have a specific agenda – I find these conversations less good for solving specific problems, and better for casting the net wide and seeing what you find.

For example, we didn’t watch sales call recordings early on – we’re too busy selling to watch calls! But Scott convinced me that this is actually extremely important at any stage – “there isn’t a basketball team that doesn’t watch recordings of how they play.” (This is probably why I suck at basketball right?)

Diagnoses > solutions

Statistically speaking, the person giving you advice is not going to nail the solution every time. In fact, they’ll probably be right 50% of the time. If you get two people giving you conflicting advice, the number of correct opinions is either 0 or 1.

They will however be pretty likely to nail the problem you’re facing, because there are exponentially more potential solutions than there are problems, and problems tend not to vary as much over time. Everyone is dealing with how to hire, fire, manage, pay, acquire customers, retain customers, etc.

For example, I spoke to three companies who all agreed that relying on solely inbound sales won’t scale beyond a certain point, and you need to figure out outbound before you actually need it. However, one suggested hiring a senior BDR, another a go-to-market engineer, and the other an account executive who could do BDR experiments. We’re solving this with the first option, because that makes the most sense in the context of our business, customer base, and existing systems.

It’s a meme, but 80% of figuring out the right solution is getting to the root of the actual problem first.

Don’t underestimate the role of luck

One thing you should always ask yourself is “how much can I attribute this person’s success to their brilliance vs. external factors such as luck?”

We love a good Napoleon or Caesar biography where their success is attributed to a series of extremely smart decisions made after a period of intense contemplation, but the reality is that a lot of anybody’s success is down to a specific time/place/economy/environment/weather.

Many of our best decisions weren’t the result of deep, careful thinking – they were vibes that turned out to be right because that’s the way the wind was blowing. And we’ve got plenty of things wrong anyway that came after a bunch of analysis.

Getting advice from someone who has only worked at Google, Meta, and Netflix mayyy be helpful because they’ve probably worked with a lot of excellent people, but remember that you’ll be trying to apply lessons from some of the biggest outliers in history to your situation.

I think the best way to figure out whether the person is brilliant or lucky is gut feel:

• Do you find the person you’re talking to extremely impressive, or do you come away thinking “wow, this company nailed it?”

• Would you pay $1m to hire that person tomorrow to help you, or did you come away thinking “that was mildly interesting?”

If it’s the latter in both cases, the advice won’t necessarily be bad, but they might have been more lucky than good.

Words by Charles Cook, who is currently working on a billboard campaign around the slogan “what doesn’t kill you makes you PostHog”

🦔 Jobs at PostHog

Really, the best advice I can give you is to join us, we’re hiring these roles and more:

• Product Engineer

• Forward Deployed Engineer

• Product Manager (ex-founder or ex-product engineer)

• AI Product Engineer

• Software Engineer — Data Stack Tooling

📚 More good reads

• Why small teams crush tiger teams - Natalia Amorim

• Why doesn’t advice work? -

• where good ideas come from (for coding agents) - Sunil Pai

• One Year at PostHog - haacked

• What the AI Wizard taught us about LLM code generation at scale - Danilo Campos

• We published 28 posts that were read over 1M times.

• We started the year at ~38k subscribers and ended it at over 100k.

• PostHog launched error tracking, PostHog AI, LLM analytics, a fully revamped experiments experience, mobile session replay, an MCP server, a job board, Deskhog, our install wizard, a new website, and much more.

• We also raised a Series D and Series E and are now at 159 people and hiring many more.

To wrap up 2025, we’re rounding up the most noteworthy of our work this year.

Most popular posts

1. Collaboration sucks – ‘s anti-collaboration manifesto was our most popular post of the year with 112,220 views, 167 shares, and a considerable amount of controversy.

2. 50 things we’ve learned about building successful products – A roundup of many lessons we’ve learned while building PostHog also made the front page of Hacker News, leading it to be our second most popular post.

3. 32 things we’ve learned about building a startup that scales – Charles’ reflections on culture, hiring, product, and marketing as PostHog has grown from 11 people to over 150 rounds out our top 3.

Lottie’s favorite hedgehog

We’re lucky to have Lottie’s illustrations liven up nearly every edition of Product for Engineers. Of the dozens of hedgehogs she drew this year, here are her two favorites:

Underrated posts

Although we’re proud of every post we published, not every one was a winner. Here are three that didn’t get the attention we thought they deserved:

1. The deadline doom loop – James’ post against deadlines is still one we often reference internally and is basically the guide to how we do scheduling at PostHog (spoiler: we don’t).

2. WTF is activation and why should engineers care? – Activation is one of the product metrics we care the most about (and you should too). This post was a deep dive on how to do it.

3. Good taste makes great products – As everyone’s worried about AI taking their jobs, one concept stood as a valiant guardian: taste. Danilo’s post on taste’s importance and how to build it provides a much-needed guide.

James’ best tweet

Name a more iconic duo: and quick calls.

Our favorite posts

Beyond being popular or unpopular, here were our favorite posts to work on:

• Ian: What engineers get wrong about communication – Communicating well is a mystical aspiration. I learned a lot about what that actually means (and how to make it happen) while writing this post.

• Andy: Glue teams vs back-office teams – Michael is one of PostHog’s most talented and delightful engineers. His post is a great example of the writing culture of PostHog at its best, and a great exploration of a subtle but important dilemma that faces every company sooner or later.

• Charles: Non-obvious SEO advice for startups – It’s marketing-y but I always appreciate Andy’s SEO wisdom.

What we learned about writing a newsletter

• We had the goal of “going weekly” multiple times this year without realizing we were basically repeatedly running into the good/fast/cheap tradeoff as blocker. To ship the quality of newsletters we want to ship weekly, we simply need more people.

• Newsletters provide a secondary benefit of crystallizing what our team has already figured out. There is a lot of internal knowledge that we are able to solidify into a clear insight and share because of the newsletter.

• Unfortunately, Substack as a platform continues to develop in a way that’s misaligned with us. It focuses on creators with paid subscriptions, but this newsletter is free and always will be.

• You can’t predict which newsletters are going to do well or poorly. In another universe, “The deadline doom loop” is our most popular newsletter of the year and “Collaboration sucks” is a dud.

• No matter what you do, you’ll always be writing, editing, and tweaking up to the time you publish. Publishing consistently frees you from needing to make every post perfect.

Our founders IRL

It may surprise you, but our founders don’t just live inside their computers. Here are their best talks from this year:

• From Pivot Hell To $1.4 Billion Unicorn – A milestone for any founder: an interview on the YC Youtube channel.

• How to Not Break Up With Your Co-Founder – Worth a click purely for the thumbnail. 💪

• How to build a cult – James channeling his inner Adam Neumann or making salient points about startup branding. You’ll have to click to find out…

Our team’s favorite tools

Here are some less well known tools our team loves:

• Atuin – The shell tool some “legitimately can’t live without”. It solved remembering CLI commands for them.

• Flox – Goodbye broken developer environments. We migrated this year and “it’s worked exceptionally well for avoiding weird one off config issues.”

• 0github – A heatmap diff viewer for code reviews. The starting point for code reviews to discover sections that deserve real attention.

• Orbstack – Basically our whole team has migrated over from Docker.

• Mergiraf – “If you aren’t using mergiraf to solve Git merge conflicts, you are missing out.”

Top jobs of 2026

Want to help us make 2026 even better? We’re hiring:

• Product Engineer

• Technical Account Manager

• Product Manager (ex-founder or ex-product engineer)

• AI Product Engineer

• ClickHouse Operations Engineer

Words in 2025 by Andy, Ian, Charles, Lior, James, Michael, and more who thank you for not completely summarizing everything we write with AI. Maybe next year…

This is a trap.

Many founders learn this the hard way by spending weeks, months (maybe even years?!) building something people don’t want because they never stopped to do something very simple from the outset.

Validate their idea.

We know a bit about this. PostHog’s co-founders, James and Tim, pivoted five times before settling on PostHog. James admits “we had a lot of terrible ideas” and validation was there to tell them just how bad they were.

I wouldn’t be writing this newsletter without the success of the validation process they did back in the day, so I’m sharing their playbook here.

It has three simple steps, but you’re going to need something first…

A list of problems to solve

One idea is good; many are better.

Your ideas should be in the form of problems: jobs-to-be-done by your product for a specific customer.

Often, the specific customer is you and the problem is one you’ve had:

• Mercury’s founder “was just really frustrated” that, as an entrepreneur, “banking was this kind of static thing that I was forced to use and rely on.”

• Deel’s founders had faced repeated problems hiring internationally in past startups, such as a lack of legal legitimacy and high costs.

• ElevenLabs’ founders thought movies dubbed into their native Polish “were flat and monotonous” and thought they could do better using AI.

James started with a three-page Google Doc of ideas based on problems he encountered in his career up until then. More were added as he worked through validating them with Tim.

Many of their ideas were bad and never got past the first step of validation – seriously guys, a “1:1 tool for managers with predictive analytics?”

Others got further before being invalidated. Only PostHog, AKA “open-source product analytics built for engineers,” made it to the end. Ironically, they landed on this idea through the process of validating their other ideas.

Every time they built something and tried to deploy analytics, they were frustrated by hard-to-implement tools not designed for builders. They literally stumbled on the right idea by failing multiple times.

So, once you have some problems like these to solve (or at least one), you’re ready for…

Step 1: Validate your problem is real

You do this by talking to potential users.

No one else is going to do this for you and not working hard enough is a common failure mode here.

James got at least two meetings a day, five days a week while doing other random tasks, like building a website. He was constantly asking for intros and doing cold outreach via his network.

Another risk is caring too much too soon.

You don’t need to care about audience, solution, or even that it’s unique yet. If people have a burning problem, these details sort themselves out.

How to get meetings

Many guides to validation focus on analysis, but anyone who’s actually done validation will tell you that getting people to talk to you is the hardest part:

1. Use your network. Find people who want to respond to you, such as friends, former teammates, followers, members of communities you’re a part of.

2. Ask for intros. Sometimes the people you know can introduce you to other relevant people. Mercury’s founder, Immad Akhund, says “some of the most useful people were four intro chains down.”

3. Be concise. Two to three sentences, not walls of text. Be clear you want feedback on your idea – say it’s an interview. Don’t try to sell to them yet.

4. Be quick. Follow up fast. Startups win on speed, be glued to your messages.

5. Do interviews in-person (if possible). This helps you better understand their context and you can catch more non-verbal cues. Video calls are second best.

What to ask people

1. Validate that they’ve actually had the problem. Focus on their situation and get specific. The clearer the problem, the simpler it’ll be for you to validate.

2. Figure out how they have tried to solve it. What have they done and what are they doing now? If they have a crappy self-built system, there’s probably a good business in providing that thing for them.1

3. Get into the details. Go beyond “it’s hard.” Listen and get into the details. Open-ended questions can reveal why you’re close but not quite right.

If it’s not a “hair on fire” problem for them, or they’re not excited to talk about it with you, it’s probably time to pivot to a new problem.

If you can see people are desperate for a solution, and you’re excited to work on the problem, then you’re ready to move on to Step 2.

Common failure modes

• Just asking people if they like your idea: Most people will just say “yes” or “it’s interesting” to get you to stop talking to them. This doesn’t equal validation. You need to know if they’ve encountered the problem and tried to solve it.

• Asking the wrong people: Sometimes the problem is right and the audience is wrong. Double check your assumptions here before pivoting to a new idea.

• Telling people what they need: If you are reading advice on how to validate your product, you probably don’t have a product or design sense to “just make it work” like Steve Jobs. Validation fills in for this.

• Doing big business validation: You don’t need to run focus groups, start product managing, build a pitch deck, or spend weeks on competitor research. Validating your problem exists isn’t like writing an academic research paper.

• Going slow. James once said “the quicker you are, the worse you can be at product. If you are bad at product and slow, you are doomed.” Don’t worry about looking dumb because you are dead by default.

Step 2: Validate users want your solution

This phase is similar to the first, but now you’re validating your solution to the problem, not whether it’s a real problem or not.

Having two co-founders helps here. One can focus entirely on building, while the other does everything else necessary for validation.

In the early days of PostHog, Tim built it, James sold it. One of the first products they built leveraged James’ experience as a salesperson. It was a complicated sales territory management tool to help reps move on from accounts that weren’t moving forward.

After 15 sales leaders said they would use it, they built it and sent them a link. Only one person clicked the link and they didn’t even log in. This was a clear sign this wasn’t what users wanted and it was time to build something else.

Beyond just building the wrong thing, there are two other big problems you can run into at this phase:

Problem #1: Not explaining your solution clearly

Articulating the problem is only half the battle. You need to articulate your solution, too. Square the circle and explain how your solution solves their problem.

If you do this well, you might not need to do anything else. Many startups have built huge waitlists before their product even launches, validating demand.

A classic example is Dropbox, whose viral demo video led to thousands of signups before they built anything.

Problem #2: You lack credibility

If you’re still struggling to convince users of your solution, it may be because you don’t have enough “street cred.”

There is a reason every YC founder brags about their past startup and schooling successes. Even though they might not be successful yet, this gives them the credibility to convince others they can pull it off.

For PostHog, James and Tim thought of reasons why people wouldn’t want to use it:

1. Users might not believe there was a real company behind it. Publishing the handbook gave the company some legitimacy. They took inspiration from GitLab.

2. Users might not trust others with their data. Making PostHog open source and self-hostable was the solution to this.

Airbnb hosts famously weren’t getting bookings because their photos sucked. Brian Chesky and Joe Gebbia flew to New York to take better photos for them (while doing more validation).

The GOAT founders did something similar with sneakers, buying some and taking photos on different types of flooring to make their stock look more robust.

A bit of polish in the right places goes a long way at the early stage.

Step 3: Validate your solution works

You do this by retaining users.

If you can retain users, you are repeatedly solving their problems. This is rare, valuable, and a sign you should start investing more into product development.

At an early stage, this doesn’t need to be complicated. You can follow this simple product improvement loop:

Closing the loop above is the way to cement your product-market fit because:

1. Your product improves fast. Weight user feedback very heavily compared to your instincts around what to build.

2. It generates word of mouth growth. The one thing you can compete on is speed. You can outperform any competitors by providing an excellent experience to your early users so they tell their friends.

3. Listening to users compounds. The more you listen to users and act on their feedback, the more useful feedback they’ll share with you.

You should have deployed some analytics by now to track how people use your product, and you can create retention insights (like the one below) to track this.

You’re looking for a retention curve that flattens out like the one above. Other useful signals include:

1. Qualitative feedback. Talk to users. Run a feedback survey. Ask the PMF question → “How would you feel if you could no longer use the product?”

2. Session replays. Watching real users use your product shows which areas are most important and which ones they struggle with or are confused by.

3. Activation. Before you can retain a user, they have to activate. If they don’t, they can’t experience the value of your product. Get them to this point faster if you can, even activate them yourself if you have to.

4. Revenue. As long as you’re not selling dollar bills for 50 cents, having people pay you (or desperately want to pay you) is clear evidence.

If you’re getting conflicting feedback, you might have multiple user personas using your product. Defining your ideal customer profile can help you figure out whose feedback to listen to.

What’s after validation?

If you can clear all three stages, congratulations: your idea is validated and you’re on your way to the promised land of product-market fit.

The next step is really to turn your validated idea into a successful startup (this makes it seem easy, doesn’t it?). Some of our other posts will be helpful now like:

• The Product-Market Fit Game (Level 5)

• 50 things we’ve learned about building successful products

• How we got our first 1,000 users

• An engineer’s guide to talking to users

• How first-time founders fail

But the reality is you never stop validating. You still need to:

• Validate the features and products on your roadmap

• Talk to users and figure out their real problems

• Get people to try what you’ve built

• Activate and retain them

• Iterate on feedback

This can all be clouded by the success of the larger business, so you’ll probably need to work harder to find the real signal.

The nice part is that this gets easier when you have existing users. It’s easier to recruit them, they want to help you as it helps them. As Ali Rowghani once said “As you get more users, you can start to see around corners.”

Validation is thought of as a skill of only the earliest of startups, but it shouldn’t be. It’s a fundamental one that is useful at all stages of a company’s journey. Even if you’re not a founder, getting better at validation (and practicing it) will create dividends.

Words by Ian Vanagas, who believes liking, subscribing, and sharing is a good enough validation signal for this newsletter.

🦔 Jobs at PostHog

Want to help us validate more products? We’re hiring product engineers and more roles like:

• Software Engineer — Language Design

• Technical Account Manager

• Product Manager (ex-founder or ex-product engineer)

• AI Product Engineer

📙 More good reads

• How To Get Startup Ideas – Paul Graham

• (User) Interviewing Tips – Christina Cacioppo

• How we built user behavior analysis with multi-modal LLMs (in 5 not-so-easy steps) – Alex Lebedev

• 8 learnings from 1 year of agents – Michael Matloka

The following was written by a member of the PostHog team about their time at a past startup. We’ve removed identifying details as it’s not meant to bash the company, but be a lesson.

In American football, there’s a strategy called “prevent defense” that teams use when they’re leading late in the game. The logic is sound: give up small gains but prevent big plays, run out the clock, and protect your lead. It’s conservative, it’s textbook, but it often backfires.

The problem isn’t the strategy itself. It’s that you stop doing the things that got you ahead in the first place. You’re no longer playing to win, you’re playing not to lose, and in sports, in startups, in anything competitive, that shift in mindset is how you hand the game to someone hungrier than you.

I know because I saw this happen. I was one of the first 30 employees at a now public tech company you’ve probably heard of. When I joined, it had something special: tight culture, developer-first mindset, and a product-led motion that got us to hundreds of millions of annual revenue before thinking about sales.

Importantly, the founding team kept an iron grip on who got hired, the bar was high, and everyone who made it through understood what it meant to be part of the culture. But you can’t scale to IPO with founders interviewing everyone. You have to let go.

Culture becomes a game of telephone. The message stays mostly the same, but with each repetition, it drifts just slightly. Over years, those slight drifts compound and alter the trajectory of the company into an outcome 5-10x lower than it could have been.

I don’t want this to happen to your startup, so here’s how to avoid it.

When priorities shift

The inflection point came when an IPO became a tangible reality. When there’s real life-changing money on the table for everyone involved, it becomes incredibly easy to make concessions. Suddenly “just this once” starts to sound reasonable.

• The person who’s 90% culture fit but has IPO experience? Sure.

• The strategy that’s proven but doesn’t quite align with our values? Let’s try it.

• An idea that’s weird and fun, but a little out there? Better not to risk it.

Culture wasn’t the only thing that mattered anymore. Instead, we needed people who had “done this before,” experienced leaders who knew how to navigate public company requirements, quarterly earnings calls, and all the machinery that comes with being a real grown-up company.

The biggest example of this was hiring an entire sales team as a siloed function, separate from the product-led sales motion that got us to hundreds of millions in ARR (annual recurring revenue). We needed to grow faster, enterprise sales seemed like the obvious answer, and everyone does it eventually, right?

Prior to doing this, we had a technical team that was consultative-first, helped businesses leverage the products we built, and taught best practices. We were measured on net revenue retention and customer expansion.

That shifted. The technical folks took a back seat to the veteran enterprise sales people, who had no domain expertise or technical knowledge. We became a supporting function in service of sales. It sucked. I watched our existing team who got us so far relegated to supporting the traditional sales team.

I’m not against building out a sales team, the problem was how we did it. It was a completely separate motion divorced from what had actually worked, optimized for what public companies are supposed to do instead of what had made us successful. It was a cultural concession that completely changed the trajectory of the company.

The culture dilution problem

Although we were making a lot of cultural concessions, the company didn’t become a bad place to work. It kept doing good things up and through the IPO and beyond. The culture didn’t become toxic or negative. It just became boring. We stopped doing the wild, wacky, weird things that made us special in the first place.

Culture isn’t some abstract value statement printed on office walls (that’s gross and tacky). It’s every person, decision, priority, and judgment call about what matters. Dilution happens gradually and it’s almost invisible while it’s occurring.

• When you’re 20 people, founders set the tone directly through every interaction.

• When you’re 200, managers are making calls based on what they think the founders would want, filtered through their own experience and priorities.

• When you’re 2,000, you have managers managing managers, and now you’re playing telephone across multiple layers where each person is adding their own interpretation of “what we value here.”

It’s not that people are bad at their jobs or don’t care. It’s that culture is transmitted through observation and osmosis, not through documentation.

Across enough managers and interpretations, the culture becomes distorted. The edges get sanded down, the things that made you special start to feel risky or off-brand. Suddenly, you’re optimizing for what feels safe rather than what actually works.

Playing not to lose

There’s a scarcity mindset that creeps in as you scale, often without anyone noticing it’s happening. You become afraid of:

• Losing your culture, market position, and momentum

• Making the wrong hire

• Taking a bet that doesn’t pay off

• Looking stupid to your board, investors, or the market

So you get conservative in ways that feel responsible but are actually corrosive.

• You hire the “safe” candidate with the impressive resume instead of the weird brilliant one who might be special.

• You pursue the “proven” strategy that worked for other companies instead of the unproven thing that might work for you.

• You optimize for not-screwing-up instead of for winning, and the irony is that this is exactly how you screw up.

I watched this happen to our process for building products. At the start, we would say “we need to ship this feature,” have maybe one conversation, and get it done.

This evolved into a process of pitches, presentations, and approvals:

By the time you got to actually building something, the original insight that made the idea good had been committee’d into something safe and unremarkable.

The scarcity mindset is insidious because it masquerades as prudence, as grown-up decision-making, as the kind of thing serious companies with serious responsibilities should be doing. But it’s poison.

How to avoid this fate

The honest truth is I don’t have a perfect answer. Maybe it’s unsolvable as startups scale. Maybe every company that grows past a certain point loses some of what made it special.

But I think there are a few things that matter:

• Keep taking big bets. The moment you stop doing things that could fail spectacularly is the moment you stop doing things that could succeed spectacularly. Keep betting on what got you there.

• Resist the “experienced” hire. Of course, sometimes you need specific expertise. But the moment someone’s resume becomes more important than their culture fit, you’ve started conceding, and concessions compound.

• Question the conventional wisdom. Everyone said we needed a traditional sales team. Everyone was wrong, or at least, the way we did it was wrong. When advice sounds logical but contradicts what’s been working, be very suspicious.

• Understand the trickle-down effect. Every hire you make will hire people who are slightly different from what you meant. Every layer of management adds interpretation. This is hard to solve, but promoting from within can help.

• Keep teams small and autonomous. With fewer management layers, more of the original DNA is preserved because there are fewer layers of interpretation between the founders and the people doing the work. You can “just do it” rather than running it up the chain.

This means your startup is likely going to be messier and more chaotic. It’s not going to be “proper” or “grown up,” but you need to live with it to become exceptional.

The real risk

For companies with some success and a good culture, the biggest risk isn’t that they’ll become a bad company or fail outright, it’s that they become a fine company that could have been exceptional. They sand down their edges in pursuit of respectability and become indistinguishable from everyone else.

This company is still around and doing good work, but there was a window, a critical 18 to 24 month period, where different decisions could have changed the trajectory entirely. Staying aggressive could have meant 5-10x the outcome. We chose prevent defense and got a respectable result instead of an exceptional one.

For companies in this window, the question is whether they’ll recognize when they start playing prevent defense, notice when the “experienced hire” starts to matter more than the culture fit, and catch themselves optimizing for safety instead of for winning.

Because in the end, prevent defense doesn’t actually prevent anything other than winning.

Written by an anonymous member of the PostHog team, who is also probably one of the only people at PostHog who knows what “prevent defense” is.

🦔💼 Hedgejobs

Want to help us make that 10x outcome a reality (or just learn who wrote this piece)? We’re hiring product engineers and more roles like:

• Technical Account Manager

• Backend Engineer — Ingestion (Europe)

• AI Product Engineer

• Product Manager (ex-founder or ex-product engineer)

🛋️ More good reads

• Why we killed our AI product assistant

• How I Use Every Claude Code Feature

• How To Navigate the Pipeline Crisis

• Racing towards Bethlehem