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

“If you want to go fast, go alone; if you want to go far, go together”

This phrase will slowly kill your company and I’m here to prove it.

Imagine you are driving a car. It’s often useful to have someone give you directions, point out gas stations, and recommend stops for snacks. This is a helpful amount of collaboration.

An unhelpful amount of collaboration is getting out of your car to ask pedestrians if they like your car, swapping drivers every 10 minutes, or having someone constantly commenting on your driving.

In the first scenario, you get the right amount of feedback to get to your destination as fast as possible. In the second, you get more feedback, but it slows you down. You run the risk of not making it to the place you want to go.

The second scenario is also the one most startups (or companies, really) end up in because of ✨ collaboration ✨.

Being good at feedback means knowing when not to give it

As PostHog grows, I’ve seen more and more collaboration that doesn’t add value or adds far too little value for the time lost collaborating. So much so we made “collaboration sucks” the topic of the week during a recent company all hands.

“You’re the driver” is a key value for us at PostHog. We aim to hire people who are great at their jobs and get out of their way. No deadlines, minimal coordination, and no managers telling you what to do.

In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself. Marketers ship code, salespeople answer technical questions without backup, and product engineers work across the stack.

This means there is almost always someone better at what you are doing than you are. It is tempting to get them, or anybody really, involved and ✨ collaborate ✨, but collaboration forces the driver to slow down and explain stuff (background, context, their thinking).

This tendency reveals itself in a few key phrases:

• “Curious what X thinks”

• “Would love to hear Y’s take on this”

• “We should work with Z on this”

This sometimes leads to valuable insights, but always slows the driver down. It erodes their motivation, confidence, and effectiveness, and ultimately leads us to ship less.

If collaboration sucks, why do people do it?

Everyone is to blame.

• People want to be helpful. For example, when someone posts their work-in-progress in Slack, others feel obliged to give feedback because we have a culture of feedback.

• On the flip side, people don’t ask for feedback from specific people because it doesn’t feel inclusive, even though it would help.

• People aren’t specific enough about what feedback they need. This creates more space for collaboration to sneak in. A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it.

• When someone has a good idea, the response often defaults to “let’s discuss” rather than “ok, do it.” As proof, we have 175 mentions of “let’s discuss” in Slack.

• People just want to talk about stuff because they are too busy can’t be bothered to act on it. We drift from our ideal of a pull request to an issue/RFC to Slack (we are mostly here) to “let’s discuss”.

• It’s not clear who the owner is (or no one wants to own what’s being discussed).

• It is annoying, but sometimes a single person can’t ship certain things front to back to a high-enough quality and we can’t just ship and iterate. We can fix broken code, but we can’t resend a newsletter.

How to crush collaboration (and go farther, faster)

So if collaboration is your enemy, how do you defeat it? Here’s what we say:

• Default to shipping. Pull requests > issues > Slack messages.

• Every time you see ✨ collaboration ✨ happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw).

• Tag who you specifically want input from and what you want from them, not just throw things out there into the void.

• Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.

• If you are a team lead, or leader of leads, who has been asked for feedback, consider being more you can just do stuff.

• When it’s your thing, you are the “informed captain.” Listen to feedback, but know it’s ultimately up to you to decide what to do, not the people giving feedback.

Unfortunately for me, not all collaboration can be rooted out, and even I will admit that some collaboration is useful. Ian and Andy edited this newsletter after all.

The point is, if you aren’t actively attempting to collaborate less, you are probably collaborating too much by default and hurting your ability to go far, fast.

Words by Charles Cook, who also hates sparkling water, presumably because the bubbles are too collaborative.

👷 Jobs at PostHog

• AI Product Engineer working on PostHog AI, LLM Analytics or Array teams.

• Backend Engineer for Feature Flags and Ingestion teams

• Influencer Wrangler on the Marketing team

• YC Technical Onboarding Specialist on the Onboarding team (San Fran based)

• ClickHouse Operations Engineer on the ClickHouse team

📖 More good reads

• Workflows are now in Alpha and I already broke mine – Sara Miteva

• Your data model is your destiny – Matt Brown

• Spinning Plates – Dylan Martin

• 1000x: The Power of an Interface for Performance (video) – Joran Dirk Greef

📺 PostHog now supports tabs – Changelog S1E2

• Nearly all of our 14+ apps have separate pricing, so we’re always figuring it out for new products, or adjusting it for existing ones.

• Enduringly low prices is a core value, which our customers love. In the last 12 months, we’ve cut pricing for analytics events, session replay, surveys, and data pipelines.

• There are over 100 requests for comments (108 to be exact) about pricing in our private (sorry) product discussions repo, some with over 100 comments on them.

This is what we’ve learned.

1. How you price is who you are

Pricing isn’t just how you make money, it defines your identity, how you market, and how you sell. It’s just as impactful as your product’s functionality or design.

To illustrate, let’s imagine two feature flag tools.

Feature Flags “R” Us charges by seats and flags created:

• Their customers think about every flag and user they add, so they do less of both.

• The flags they do create are more heavily relied on.

This model appeals to companies that ship slowly and make more requests per flag. This means enterprise features, like auditability and access controls, are a priority.

The Flag Company of New York charges by requests:

• Their customers give access to every developer who create many more flags.

• This lets those developers use them more often (e.g. to test in production)

This model appeals to companies who ship faster and want flexibility. They need to be more thoughtful about where flags go in code so they don’t spend too much, which means cost controls and DevEx features, like local evaluation, matter more.

In short, how much you charge often doesn’t matter as much as how you charge. While they’re superficially similar products, how these two products charge leads to a totally different experience, and different sales motions, too.

Remember this: How you price your product should flow from your ideal customer profile (ICP). Our ICP is high-growth startups that are led by product engineers, which is why we’ve chosen a self-serve model and usage-based pricing. It gives product engineers control and they can use as many flags as they please.

2. Charging anything is better than giving it away

It’s easy to give things away, especially zero marginal cost software, but it’s a trap for early-stage startups. Typically, startups delay figuring out pricing because:

1. They are scared no one will pay them

2. They are afraid of getting pricing wrong and damaging growth

3. They think user growth is more important than revenue

But, unless you’re building Facebook, you’re always better off charging something as soon as possible, even if the unit economics don’t add up yet. Why? Because paying customers give you different, and more valuable, feedback than free users.

They care enough about your solution to give you money, so they’ll care more about it improving. They have skin in the game. This is why acquiring reference customers is a core part of finding product-market fit.

Don’t believe us? Consider the fate of Kite, a failed AI coding startup that had 500k monthly active users when it shut down. As the founder reflected in a blog post:

We failed to build a business because our product did not monetize, and it took too long to figure that out.

We sequenced building our business in the following order: First we built our team, then the product, then distribution, and then monetization.

The first three steps worked. They built a “world-class engineering team” and grew the product to 500k developers with “almost no marketing spend.”

But monetization let them down. Those developers did not pay to use Kite. All the work on previous steps did not pay off and they had to shut down after seven years.

If they had charged earlier, they would have learned faster and possibly avoided the “innumerable sacrifices” they had to make it keep the business going for so long.

Remember this: Pricing is just like product. The sooner you ship something, the sooner you’ll learn what users want. Speaking of which…

3. Frequently changing pricing is totally normal

You’ll almost certainly get your pricing wrong, especially if you are charging early. That’s normal, all companies do it.

PostHog’s early pricing was wildly different from our pricing now. In August 2020, we started as a monthly subscription with a limited free tier.

Later, in March 2021, we added our first iteration of usage-based pricing for a single product and have kept iterating on this model ever since.

Finally, in May 2021, we increased our free tier for events 100x and this combination of usage-based pricing with a generous free tier has been the core of our pricing ever since.

All of your favorite companies who aren’t called PostHog change their pricing regularly, too:

• Notion was paid only until 2020 when it added a free tier for personal use. It has since expanded the free tier to remove any paid personal plans, just focusing on paid teams plans.

• Figma launched an enterprise plan in 2022 with more admin tools, workspaces, and access controls. It also raised prices for Figma Design in 2025.

• Intercom reinvigorated and doubled its growth by launching its AI agent, Fin, with outcome-based pricing.

Ultimately, changing your pricing when needed means you'll better align the value you create with how you charge for it. For example, we recently changed how we charge for data pipelines from events ingested to rows exported and triggered events because it aligns better with that users actually used.

Remember this: Pricing changes require good communication. Give customers:

• Plenty of notice about changes. Figma gave three months.

• A warning, grace period, and discount if you’re raising prices.

• The option to keep old pricing unless it is more expensive or you have a good reason not to.

4. Settle free tier debates before they happen

How much free stuff should we give away? It’s easy to either debate this endlessly, or fall into one of two extremes:

1. Give away as much as possible. Users love free stuff, increasing your free tier is a good way to get more users.

2. Charge for everything. This makes more money and money is good.

Ideally, there should be nuance to this. The best way to create this (and settle debates) is to have clear principles for your free tier. For us, these are:

• Hobbyists or pre-PMF startups should be able to use PostHog for free. This creates ultra-valuable word-of-mouth growth. GitHub famously does the same.

• Be more generous than competitors, making it a no-brainer to choose PostHog. This often means a larger free tier with more features. We’re one of the few session replay tools that offers mobile session replay for free, for example.

• Every product should be priced separately. This means separate free tiers for each product. LLM analytics is separate from product analytics, even though they both use “events.”

• Features that increase stickiness should be free with a reasonable limit. A good question to ask here is: “If I were to switch away to a competitor, what would I feel like I am losing?” It’s tough to leave Figma when all your projects and designs are in one place.

Remember this: Principles prevent every discussion about the free tier from becoming a debate, while avoiding the extremes of giving away too much or charging for too little. Pricing principles should guide all your pricing decisions, too.

5. Billing will become a bottleneck

If you want to go beyond the simple subscription model most billing systems offer, you will need at least one engineer dedicated to it.

This has been the case at PostHog as long as I’ve been here. Three years ago, billing was the growth team’s responsibility, but eventually transitioned to a glue team focused on billing, which now has four people and dedicated support engineer.

Why do we need so many people involved in billing?

• It enables us to charge the way we want. It can be tempting to just accept the simple subscription model most billing systems offer, but this limits your ability to have pricing that aligns with your value creation. Our billing team lets us price products, add-ons, and platform packages how we want.

• The billing system needs the flexibility to handle many situations, such as discounts, contracts, credits, invoicing, and weird payment methods (pay by cheque anyone? Please don’t).

• It needs to be reliable. Charge too much and customers will be super unhappy. Charge too little (or miss failed/late payments) and you are literally leaving money on the table.

• It enables us to make more accurate revenue models and projections, which helps us with everything from hiring to fundraising to product roadmaps.

Remember this: Without someone dedicated to billing, pricing launches are painful, your ability to charge users is limited, more errors and unhappy customers pop up, and any decision involving revenue becomes more difficult.

6. Predictable and transparent pricing > simple pricing

Everyone hates being charged more than they expected. This, of course, hurts the customer, but it also hurts you, as it leads to more churn and a worse reputation.

The solution to this, for many companies, is to make their pricing simpler. Fewer tiers, a unified credit system, a single subscription for everything. For B2B companies, this is a mistake as it limits your ability to charge users for the value they receive.

The alternative we recommend is making your pricing more predictable and transparent. Some ways to do this include:

• Creating a transparent and detailed pricing page. Stripe and Twilio are great examples of this. People want to know roughly how much they’ll pay before they start. We take this a step further and list our sales discounts publicly too.

• Give users a clear view on how much they’ve spent so far and how much they are projected to spend. We do this on our billing page, along with a billable usage dashboard and a docs page on ways to estimate your spend.

• Add spend limits. If customers don’t want to pay over a certain amount, respect that, but make it clear what they’ll lose when they hit the cap.

• Help users tune their spend to what they’re actually using. Our customer success team helps a lot with this and we provide docs pages on cutting costs for most of our products like product analytics, session replay, and feature flags. Data infrastructure companies like Snowflake, Supabase, and PlanetScale all offer ways to identify costly queries and resources to optimize their spend.

• Be generous with refunds. For example, we have side project insurance that protects customers from huge bills if their product goes viral.

Some may call this “leaving money on the table” but we see it as doing the right thing. I’m sure others have had success with the dodgiest pricing tactics possible, but the trust we’ve built with customers is core to what makes PostHog successful, so we won’t be changing these.

Words by Ian Vanagas, free tier enjoyer.

🦔🤵 Jobs at PostHog

Interested in seeing all 108 internal pricing RFCs? We’re hiring product engineers and more specialist roles like:

• Backend Engineer – Feature Flags

• Software Engineer – Data Stack

• Product Engineer – Platform Features

• Technical Customer Success Manager

📙 More good reads

• I’ve consistently underestimated how important communication is as a CEO – James Hawkins

• How we made feature flags even faster and more reliable – Dylan Martin

• How to Compete in SaaS –

• Your pricing is (probably) broken –

• Tailscale Pricing v3, plans, packages, and debugging – Avery Pennarun

Culture and hiring

1. Optimism is more important than hard technical skills. The splash damage from pessimism is high.

2. You will relax your standards for that one hire, then regret it. You will keep re-learning this lesson, but hopefully with longer gaps between each one.

3. It is 1,000x easier to say no at the interview stage than to let someone go later.

4. It is MUCH more important to make sure your existing team is effective before hiring more people.

5. The SuperDay is still our single best source of signal for new hires. Being good at interviews very weakly correlates to being great at PostHog.

6. Hiring the first person to do X is not the time for a wildcard hire. They need to have actual experience doing that thing.

7. We’ve never had an experience where working with an external agency was better than doing it ourselves.

8. It’s easy to drift from giving feedback after something has shipped, to front loading it so your feedback basically turns into an approval process. Resist the urge.

9. It doesn’t matter how big or small the problem is, if you don’t have one person ultimately owning it, you will probably fail.

10. Salary exceptions always result in unacceptable culture debt: don’t do it. You will regret it every time you do pay reviews.

11. If people start to talk in fancy management-speak rather than like real people, call it out. Use words that you would actually say in real life.

12. Copy the bits you like about other, more successful companies or leaders – don’t import them in their entirety. Remember, you are probably not as smart as Jensen Huang.

Product and engineering

13. Small teams scale extremely well. One of the best things we’ve ever done is to keep engineering teams to six people or fewer.

14. Ask yourself who your ICP is over and over (and over) again. Finding PMF is not a one-time thing: the market, your users, and technologies change.

15. Ask not what you can do with AI, but what AI can do for you.

16. If a problem isn’t specific and valuable to solve, AI will not magically make it one.

17. Keep talking to users. Your assumptions about what they want and how they might use your product may have changed. Actually, they definitely have.

18. Make goals about shipping, not outcomes. This still magically works way better than OKRs, and is more fun.

19. If you really can’t decide what to prioritize, do the most fun thing first.

20. The best engineer is not always the best manager. Being a team lead should not be a ‘reward’ for being a great IC.

21. 0% of stretch goals ever get completed. If something is a stretch goal, delete it from your plans.

22. The opinion of your users after you ship >>> opinion of other PostHog people before you ship.

Marketing and sales

23. Going upmarket doesn’t mean neutering your brand; enterprises are full of real people too who like to read fun stuff.

24. As you grow and serve a wider audience, it’s easy to become less opinionated. This is the best way to lose your ICP’s interest.

25. Keep building a great product, then telling people about it. If you are product-led, ask yourself why you think paid ads are now how you grow your business if they weren’t before.

26. Selling features over benefits works surprisingly well up-market too. Sometimes people at giant corporations really do just want ‘a tool that does X’.

27. You will never find a way to do merch fast and well. Moving physical stuff around the world has its limits.

28. People will tell you hiring technical people to sell software does not scale beyond the first handful. This is not true, it’s just hard.

29. Even at scale, we’re still focused on getting a relatively small number of marketing channels right versus trying to be everywhere.

30. You will never be happy with attribution. Trying to ‘solve’ it is a fool’s errand; reasonable approximations are fine.

31. It’s ok if marketing and sales lag product. A user’s default is to not care about you. You can do a launch months after a product first shipped, nobody cares.

32. Your competition is for attention, i.e. TikTok, not the blogs of other B2B SaaS companies.

Words by Charles Cook, generic exec person and head of the PostHog Transparency Commission.

🦔🤵 Jobs at PostHog

Want to help us scale further? We’re hiring product engineers and more specialist roles like:

• AI Product Engineer

• ClickHouse Operations Engineer

• Dev Advocates, Technical Writers, and Content Creators (write for this newsletter!)

• Technical Account Manager

• YC Technical Onboarding Specialist

More jobs at PostHog

Some find autocomplete great, but need to rip out anything beyond that. Others find they’re a huge speedup, but only in specific circumstances.

Everyone agreed on thing though: coding with AI is a skill. It takes practice and a lot of mistakes to get good at it.

We know this because we’ve made a bunch of mistakes over the past few years working with these tools, building AI-powered features, and working with companies in the space.

Here’s what we’ve learned.

1. Treating your big codebase like a small codebase

Like many “real” companies, PostHog’s codebase is big: 8,984 files and 1,623,533 lines of code, to be exact.

Sadly, most of the AI coding advice out there isn’t written for this scenario. It’s written for new developers vibe coding from zero to one, and that advice doesn’t work when you’re working with a large, existing code base.

Although it’s less sexy than vibe coding, being thoughtful about using AI is more important in a larger codebase for the following reasons:

• Less of your app fits into the AI tool’s context windows, which means you need to be more careful about what goes into it. This is true of both coding and building AI-powered features.

• AI can go and make changes to parts of your apps you don’t expect. Radically changing the UI might be fine in a small prototype, but it can ruin a lot of things in a big app like ours.

• Tests, linting, and type checking increase in importance as they help protect against AI making changes with unintended consequences.

• Be specific with your prompts. In a larger codebase, individual files and features can take over your context window. Vaguely asking “make it better” will leave the agent confused and ineffective.

As one of our product engineers, Paul D’Ambra, noted in a blog on how he uses LLMs:

They’re not actually very good software engineers… particularly since most of the data they’ve ingested about software engineering is “blogs on how to start something from scratch”. So, if that’s not the task. Then I find it often harder to prompt an LLM to do than to do it myself

2. Not providing the right context, rules, and guardrails

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION! I DON’T WANT “Here’s how you can blablabla” - posthog/.cursorrules

As LLMs are non-deterministic, they can go off the rails in a lot of ways. You need a structure in place to keep them on track.

Our AI install wizard is basically a big scaffold to do just this. Users could ask AI to install PostHog for them, but would quickly start using out-of-date patterns, hallucinated API keys, and phantom libraries. By providing context on PostHog along with guardrails for implementing it, the wizard prevents all of this.

Unfortunately, these are rarely set up for you. You need to do this yourself. To help, here are some context, rules, and guardrails we rely on (and recommend):

• Reference examples of code already written whenever possible, such as pre-built UI components, database schema, optimized database queries, testing patterns, and state management structures.

• Documentation, source code, and examples for the libraries, frameworks, or tools you are using. Danilo calls LLMs “a delayed, lossy, compressed snapshot of the web” so this ensures they have as complete of a picture as possible. We added “Copy as Markdown” buttons to all our docs pages to help with this.

• .cursor/rules. Have different rule files for different languages (like Python, Typescript, and Rust). Include principles, project structure, dependencies, best practices, naming conventions, logging, testing, and security details.

• claude.md and other specification files. A lot of what to include here overlaps with .cursor/rules but having clear spec of what you want to do matters a lot more as well as commands Claude can use for tests, linting, and building. See ours here.

• Subagents for Claude to help with specific tasks like code reviews, systematic debugging, test writing, and prompt engineering. For example, some of our team use a combination of Claude and Mergiraf to resolve gnarly merge conflicts.

Of course, engineers have built a whole set of non-AI (😱) tools for preventing mistakes and issues. These work just as well (if not better) with AI, and upgrades to these tools often have a bigger impact on developer productivity than AI tools do. Examples for us include:

• Ruff, Oxlint, mypy, Prettier, and more for linting, formatting, and type checking.

• Jest, Playwright, pytest for testing.

• Type hinting required in both Python and Typescript.

• IDE tooling like PyCharm, JetBrains’ testing suite, and IntelliJ.

• Style guides and coding standards.

Developers, especially product engineers, were already relying on tools like these prior to AI. AI has just made these deterministic checks and guardrails even more important.

Like AI, the rise in importance of these tools isn’t expected to slow down either. As Gergely from Pragmatic Engineer says:

Google is preparing for 10x more code to be shipped. A former Google Site Reliability Engineer (SRE) told me:

“What I’m hearing from SRE friends is that they are preparing for 10x the lines of code making their way into production.”

If any company has data on the likely impact of AI tools, it’s Google. 10x as much code generated will likely also mean 10x more:

• Code review

• Deployments

• Feature flags

• Source control footprint

• … and, perhaps, even bugs and outages, if not handled with care

3. Trying to use AI on something you know it’s not good at

Claude Code writing Rust is a while loop that accelerates climate change - Nick Best, Team Ingestion Product Engineer

Using AI most effectively requires piling up a collection of examples of situations where AI is and isn’t useful. You can waste a lot of time and energy repeatedly asking it to do something you know it can’t do.

A helpful way to remember all of this is anthropomorphizing your AI assistant like it’s a coworker. Some call AI “an army of interns” while Birgitta Böckeler settles on giving it the specific characteristics of being “eager, stubborn, well-read, inexperienced, and won’t admit when they don’t ‘know’ something.” Anthropomorphizing your AI is basically the AI age’s version of rubberducking.

Once you’ve anthropomorphized your AI, you can get specific with the situations it excels at. For our team, these include:

• Autocomplete. Everyone loves hitting tab repeatedly to get their work done.

• Adding more versions of tests and fixing them.

• Using it for rubberducking. Asking deep questions, learning more about the codebase and context. It’s easier to understand any file or function with an LLM.

• Doing research. This is not necessarily a coding-related task, but something engineers still need to do for you. No more Googling for StackOverflow answers.

On the other side, our team finds AI sucks at:

• Writing code in a language it is unfamiliar with, like our internal version of SQL, HogQL.

• Using the correct (or even existing) methods, classes, libraries. It regularly hallucinates these and assumes their functionality based on their name (rather than their contents).

• Following best, up to date, and existing practices. It often uses deprecated APIs for example.

• Writing tests from scratch. Paul says there are so many bad examples of tests out there that LLMs often churn out the same bad tests.

Identifying what AI is and isn’t good at also helps you at a meta level. It stops you from falling into the pitfall of doing easy things AI can do instead of the hard (and important) things that maybe it can’t.

4. Being content with your existing workflow

A personality trait of a great product engineer is that they are always experimenting. When it comes to AI tools, this is no different.

Our team is always testing (and talking about) new tools and approaches. There are 1,104 messages with the word “Cursor” in our Slack, 187 with “Claude Code.” This started early and is led by our cofounders.

James is an avid vibe coder, (in)famously building a prototype of our job board on a flight (before it was completely rewritten by the website team 🙈) while Tim is a real developer™ and regularly contributes mild to hot takes on AI workflows:

Beyond founder mode, what are some specific ways we aim to improve our workflows?

• Raising our AI tool budget to $300. This enables people to try Claude Max and other top tier models.

• Testing different tools, agents, and frameworks like Claude Squad (which didn’t work), Git worktrees, Traycer, Relace, Robusta, and more.

• Trying different models with the same tools to figure out which models are good at what. For example, a lot of our engineers find switching to Opus extremely beneficial (over Sonnet) and have been experimenting with Qwen in Cursor.

• Building and dogfooding our own AI engineering tools like Max AI, the PostHog MCP, and LLM analytics. This also means we talk to a lot of teams on the cutting edge of AI engineering like Lovable and ElevenLabs.

• Nearly every hackathon has had AI-related projects being built in it. This gives more of the team opportunities to explore new tools and understand what AI is good/not good at.

At a more granular level, great engineers are always experimenting with different prompts and references. They are constantly judging the output of these to create the ideal workflow that works for them (this never ends).

5. Not using AI (at least a little bit)

Even if you dislike AI personally, it is a mistake to not use it for two reasons unrelated to you:

1. Your competitors are using AI. Customers will be comparing your product to AI-powered alternatives. The engineers of (good) competitors will also be trying to use AI to out ship you. You need to know what makes you product and process better than an AI-powered alternative.

2. Your users are almost certainly using it. They have AI in their workflows. Some of them will try to fit what you’ve built into those workflows. Especially if you are building for developers, you won’t understand the full experience of using AI in software development if you don’t try it.

In both cases, knowing the capabilities and limits of AI is helpful, and there is nothing that beats hands-on experience. In this way, coding with AI can provide huge benefits even if you use none of the code it writes.

6. Letting AI do everything for you

Because AI can seemingly do anything you ask of it, it is tempting to let it do everything. For example, we’re seeing an increasing number of people use AI tools to answer questions in live job interviews (yes, we can tell and we’ll fail you if you do it).

Ultimately, you are responsible for the end product of what you create. This is true whether you use AI or not. For nearly all work, using AI exclusively is probably a bad idea. As I’ve said before, you can’t one shot your way to a billion dollars.

AI is reshaping software. As model capacities and adoption increase, more and more of software (and software development) will be reshaped. What’s important as an individual isn’t using AI for the sake of it, but, like everything else, understanding it and fitting it into how you work.

Getting big architecture decisions right, figuring out what to build, positioning correctly, and choosing the right tools will all remain important, but it also remains up to you to figure these out, with or without AI. If you do choose to use AI, avoiding the mistakes here will help improve your odds that you’re successful.

Words by Ian Vanagas, quote misattribution aficionado.

🦔🤵 Jobs at PostHog

Want to help us make more mistakes we can learn from (or just make use of our AI coding budget)? We’re hiring product engineers and more specialist roles like:

• AI Product Engineer

• Ingestion Backend Engineer

• Data Warehouse Backend Engineer

• Developer who loves teaching (write for this newsletter!)

• Developer Community Manager

  More jobs at PostHog

Max AI just got even more powerful

From the outside, Bolt seems like an overnight success story – another startup riding the wave of the AI boom. In fact, Bolt is among the most successful startup pivots ever. An overnight success that was seven years in the making.

This graph speaks for itself. Since that pivot in October 2024, Bolt’s users have created millions of apps, and Bolt is generating $40 million in ARR with an engineering team of just 15. A truly epic turnaround.

I spoke with co‑founder and CTO Albert  Pai, and founding engineer Dominic Elm, to understand how Bolt puts the rabbit into the hat.

How Bolt works

To understand some of the technical challenges of building Bolt, let's see what happens after entering a prompt:

1. User types in a prompt, e.g. “Build a Tinder for Dogs web app”.

2. Prompt is sent to LLM to generate the code for the app.

3. In the meantime, the browser boots up WebContainer, an in-browser virtual machine where all the code will run.

4. WebContainer receives the necessary commands to set up and install the project – e.g. it runs npm install, creates project files, etc.

5. Once code is completed, the VM runs the code and displays the preview.

What's fascinating to me is how simple it all is.

I thought Bolt would be orchestrating a whole chain of LLM calls and fine‑tuned models, but in reality the entire app springs from a single, meticulously crafted prompt.

The real story here is WebContainer, Bolt's in‑browser VM. As Albert Pai, Bolt’s founder and CTO, notes: “People assume we’re running a giant server farm. In reality, the server is your browser.”

Before pivoting to building Bolt, the team spent seven years building StackBlitz, a browser‑based IDE. StackBlitz's core tech was WebContainer, an open-source runtime they built that boots up Node.js entirely in a browser.

Despite millions of developer sessions, StackBlitz was on the brink of shutting down. Then, in mid‑2024, the latest wave of LLMs proved that AI could build high quality apps end-to-end.

Recognizing that WebContainer was the perfect runtime for this new workflow, they pivoted and relaunched as Bolt in October 2024. In only 30 days they rocketed from $0 to $4M ARR, and six months later they 10x'ed to $40M.

WebContainer is Bolt’s superpower. Most AI app builders spin up a fresh container in the cloud for every session, which adds cold starts, network round-trips, and per-user costs. WebContainer flips that model: it runs the app inside your browser.

“The big win is latency. It feels as if you’re developing on localhost”, says founding engineer Dominic Elm. “Plus it has security benefits. With remote compute you get abuse like people trying to run bitcoin miners. With WebContainer, if someone tries, they’re just using their own CPU.”

Why squeezing Node.js into a browser tab is hard – and how Bolt pulled it off

Building this super power wasn’t as easy as being bitten by a radioactive spider.

“At the beginning, we weren’t even sure it was possible. Browsers don’t expose the syscalls Node expects and have strict security rules,” says Albert. “We ended up spending years porting and building our own pieces until it actually felt like a local dev environment.”

Below, each major hurdle becomes its own mini‑story.

1. A virtual file system

Node's fs API expects a concurrent POSIX‑compliant disk (POSIX is a common standard for OS interfaces). Without it, even a simple npm install falls apart.

🛑 Why this is hard to do in a browser

Browsers don't expose the low-level file system operations that Node relies on – e.g. opening a file, locking it, writing raw bytes, etc. You have to simulate a real disk and safe concurrent access on top of higher-level browser primitives, which increases latency and the risk of race conditions.

It took three full attempts before the team had a browser-native file system fast enough.

First, they tried to fork an existing browser file system library. This failed quickly as most libraries only emulate the basics of a disk. Node expects dozens of low‑level operations, such as file‐descriptor locks, atomic writes, access controls, so the missing functions caused many errors.

Next they tried to write their own JavaScript-based file system. This approach relied on keeping every file in memory, and using a single dedicated Web Worker to handle all reads and writes via postMessage – a browser API for sending messages between the main thread and Web Workers.

However, with thousands of tiny files in something like a React app, requests pile up behind the worker, causing performance to tank and the UI to freeze.

💪 How Bolt pulled it off

Bolt solved its problem by building a Rust-based file system. Rust has the advantage of running close to C-speed, has zero garbage-collection pauses, and strong guarantees around memory safety – exactly what you want for something acting like an OS kernel. Combine this with the Atomics API and you can build the atomic writes and file locks Node expects, making thread-safety work just like on Linux.

Whenever a Bolt tab opens, the file system module is loaded into a single SharedArrayBuffer – a block of memory that all Web Workers can access at the same time. Each Worker gets a reference to this buffer and treats it as the “disk”. Because they read/write directly in shared memory, there's no JSON copying and no slow async storage calls, making it far faster than the postMessage approach, or even other alternatives like IndexedDB or OPFS.

Finally, at build-time the Rust code compiles to WebAssembly (WASM), so any modern browser can run it at near-native speed. The result is a crash-resistant, high-speed file system that finally meets Node's expectations.

2. A true process and threading model

Modern Node apps don't run in a single thread. When you type npm run dev, Node may:

• Spawn the TypeScript compiler in one process

• Launch Vite's web server in another

• Keep the Jest test‑runner idling in the background

• Spin up worker threads for CPU‑heavy tasks

🛑 Why this is a problem in a browser

Inside the browser you only get one UI thread and a handful of Web Workers. Workers can't fork() new processes, share open files or sockets, or handle OS-level signals. Node's tool-chain expects full operating-system processes with all those capabilities, so the browser's native concurrency model just isn't enough.

💪 How Bolt pulled it off

a. Web Workers as processes.
Every Node "process" becomes its own Worker. A tiny Rust "kernel" keeps a list of running tasks and exposes functions, so commands like ps or kill still work as expected.

b. One shared memory space.
All Workers share a single SharedArrayBuffer, so they read/write bytes directly. Atomics provides locks and atomic writes for safe concurrent FS access and fast inter-process communication, making the runtime feel OS-like.

c. Signal & stdio emulation
In a normal Unix environment you stop a process by sending it a signal such as SIGTERM, and you read its output through two standard streams: stdout for regular logs and stderr for errors. Browsers provide neither, so Bolt fakes them in shared memory:

The kernel sets tiny in-memory flags to request a task stop; Workers check those flags and shut down cleanly. For output, each Worker writes logs into its own shared log buffer, which the terminal reads directly.

d. Custom shell
Since you can't embed a full Bash binary in a tab, Bolt shipped its own TypeScript shell called JSH. It understands everyday commands (cd, ls, npm run dev), keeps arrow-key history, and everything else you would expect.

Behind the scenes every command runs in a Web Worker, but JSH funnels their input and output into one terminal pane, giving you a familiar “local” shell experience entirely inside the browser

3. Networking without localhost

Dev servers usually bind to 127.0.0.1:PORT to run and test apps.

🛑 Why this is a problem in a browser

Code running inside a browser cannot listen on a port. The sandbox only lets pages initiate requests with fetch() or WebSockets. There's no raw TCP API, no listen(), and therefore no true localhost.

💪 How Bolt pulled it off

a. Virtual localhost via Service Worker
A Service Worker watches for special in-page URLs (e.g. /__bolt/3000/…). When it sees one, it hands the request straight to the Web Worker that owns port 3000 via a fast MessagePort. To the dev server, it feels like a normal socket; to the page, it's just another fetch().

b. WebSocket bridge for hot‑reload
The same Service Worker intercepts WebSocket connections to that internal URL, opens a channel to the dev-server Worker, and forwards messages between them. That keeps Vite/Next.js hot-reload working in tens of milliseconds.

c. Fallback tunnel for tools that expect raw TCP
If some code tries to open a raw TCP socket (e.g., a Postgres client), Bolt swaps in a WebSocket replacement. The browser connects a Bolt relay server, which opens the real TCP connection and relays bytes both ways. This way the code keeps working while the browser stays sandboxed.

4. Standards‑compliant ES Modules (ESM)

Modern Node lets you mix ES Modules (import …) and legacy CommonJS (require(…), __dirname, etc.). If Bolt didn't support both inside the tab, most of the npm ecosystem would refuse to run.

🛑 Why this is a problem in a browser

Browsers do have native ESM, but the rules are different:

• URL‑based resolution. Browsers fetch modules by absolute or relative URLs, but Node resolves via node_modules, package.json exports, file extensions, etc.

• CommonJS is missing. require(), module.exports, and dynamic import() tricks don't exist natively.

• Node's VM & loader APIs (vm.Module, createRequire) are written in C++ and deeply tied to the host OS.

💪 How Bolt pulled it off

a. Node‑style resolver in TypeScript
A custom loader reproduces everything Node does: climbs directories, reads package.json, honors exports/imports, adds missing extensions, falls back to index.js.

b. ESM ↔ CommonJS bridge
If a module calls require('./utils'), Bolt's loader detects it, wraps the CommonJS code in a tiny function, and injects it into the same dependency graph, so ESM and CJS can import each other seamlessly.

c. Virtual Node internals
The Rust/WASM kernel exposes a fake process object (env, argv, cwd) and a slim vm API, giving Babel, TypeScript, and friends the hooks they expect.

5. Boot‑time and runtime performance

Bolt has to feel as quick as opening a folder locally, even though the browser must download a Node‑sized runtime and thousands of other project files.

🛑 Why this is hard in a browser

• Big download. A Node‑compatible runtime plus helpers can weigh tens of MB.

• Thousands of tiny files. Extracting them one‑by‑one would freeze the UI.

• Slow installs. npm install is network‑heavy and noisy on the file system.

• Tight CPU and memory budgets. A long compile or garbage collection pause can freeze the tab.

💪 How Bolt pulled it off

a. Slim runtime bundle
Dead code, debug symbols and bulky unicode tables are stripped from the Rust→WASM build, pushing the cold download to well under 10 MB.

b. Snapshot‑first file system
The entire node_modules tree and project source are packed into one compressed blob. First load streams it straight into shared memory. Subsequent visits just copy it from the HTTP cache, taking hundreds of ms instead of seconds.

c. Instant installs
Popular packages live on Bolt's CDN in pre‑compressed layers. After the first hit they sit in the browser cache, so npm install often finishes in < 500 ms, or is even skipped entirely.

d. Work off the main thread
Compiles and builds run in Web Workers that yield regularly, keeping the UI thread free and garbage collection pauses invisible.

Great tech + staying alive = Profit $

WebContainer is clearly an impressive piece of technology, but what really mattered was that the team never gave up on it.

“For seven years we kept grinding even when the results looked thin, and we were disciplined enough not to run out of money.” says Albert.

“This persistence meant that when LLMs finally became good enough to generate entire apps, we were holding the exact missing piece.”

Suddenly WebContainer wasn’t just a clever runtime, it was also the perfect companion for AI. With it, a one-line prompt could turn into a running full-stack app.

Bolt pivoted their business into the moment and, with a single tweet, years of quiet work ignited into explosive growth.

With thanks to Albert  Pai and Dominic Elm for sharing their time and knowledge

Everyone’s staking claims and panning for quick wins. A minority are building mines that create long-term value, but most of the shiny demos are fool’s gold: bolted-on, rarely used, and quick to tarnish.

We took our time entering this gold rush. In 2023, when many started adding AI-powered features, we tinkered but felt the model capabilities weren't good enough.

A year later, in an August 2024 hackathon, we built a trends generator agent and it was obvious things had changed. Given the proper context, models were now good enough to generate useful insights.

That was 12 months ago. Since then, we shipped Max AI, our AI-powered product analyst, and we’ve learned a bunch of lessons along the way.

The first one? Don’t make your product worse.

Choosing what to build

Yes, AI really can make your product worse if you choose to build the wrong thing, either because it’s too slow, unreliable, or it solves a problem no one cares about.

There are three key lessons here:

1. Learn the patterns AI is good at

You don’t need to reinvent the wheel.

A bunch of smart people have already figured out effective AI patterns you can copy. These have the advantage of being UX patterns that users are familiar with, while also being functionality AI is actually good at.

First is the classic “chat with your docs/data/PDF.” AI is great at search and summarization, and can use this to build reports and recommendations.

Second are generators of various kinds: titles, code, documents, SQL, images, and filters. App builders like Lovable and Bolt.new are the most notable examples, but numerous companies, such as Figma, Rippling, and Notion, have integrated generation features into their products.

Third, and finally, is tool use. AI can use well-defined tools. This is what MCP servers are all about. Companies like Zapier, Atlassian, Asana, and many more have used this to automate and improve workflows. And yes, there’s a PostHog MCP server, too.

Knowing the common AI patterns helps you identify where you can use them in your product. Max AI uses several of these, including:

• Chat with your data and our docs

• Generate SQL insights and filters

• Use tools, like creating surveys and analytics insights.

Soon, Max AI will go further in its tool use by watching and analyzing session recordings for you, among other (somewhat secret) things.

2. Identify problems that AI might solve

With the patterns AI is good at in mind, go through your product and figure out the jobs to be done that AI could potentially do, such as:

• A well-defined single task that takes more than 30 seconds to do, like filling a long form, manually entering data, setting up an integration, or installing an SDK.

• Instances where users need to use a language or interface they don’t understand, such as a complex UI, SQL queries, or building an app.

• Something users do more than 20 times, such as writing descriptions, summaries, or creating an entry.

As Stephen Whitworth of incident.io said in Lenny's Newsletter:

Look less at “what cool new things could AI do” but more at “what’s the thing our users do 100 times a day that AI could make better.”

An example for us is writing a summary for an incident. It turns out that users vastly, vastly prefer automatically generated summaries to writing these themselves; 75% of incident summaries are now AI-generated.

We’ve applied this thinking in many ways, such as:

1. Creating an AI install wizard, which lowers the time to install PostHog from ~10 minutes to 90 seconds – perfect for vibe coders or anyone frequently starting new projects.

2. Max AI makes writing complex SQL queries easy by acting as a natural language translator. This especially helps less technical users of PostHog who aren’t familiar with SQL create more customized insights.

3. Validate the problem is specific and valuable

Now that you have some patterns and problems, narrow them down to the ones that are both specific and valuable.

Avoid these traps:

1. Using an existing pattern on a problem that isn’t valuable. You probably don’t need a “chat to your docs” feature in a simple, early-stage product. It might even be a negative as it could hide core usability issues.

2. Trying to solve too large a problem with AI. An AI can’t one-shot making you a billion dollars. It’s better to solve a narrow problem first before expanding outward. If you’re stuck, try enhancing something that already exists.

When building Max, we quickly realized answering questions like “How do I increase revenue?” were too broad. Instead, we focused on building specific functionality that leverages its advantage of being integrated into PostHog with your PostHog context.

For example, Max can write better SQL because it knows which tables are available, and answer product questions with native visualizations because it’s built-in and understands the tools available.

Implementing your idea

Now that you have an idea of what you want to build, you need to make sure it actually works. Here are some core bits to focus on getting right:

4. Your app’s context and state are critical

Everyone can call the OpenAI API, but your app's context is unique. This can include data like:

• What a user is trying to do

• Who is doing it

• Their account status

• Where they are in the app

• The app’s data schema looks like

When a user asks Max why signups dropped last week, for example, the API receives information on the:

• Current page (dashboard, visible insights, applied filters, user role)

• Data schema (available events, event properties, person properties)

• Account (organization tier, timezone, retention)

The code for this literally looks like this:

# From root/nodes.py - Context gets formatted into the AI prompt
def _format_ui_context(self, ui_context: MaxUIContext) -> str:
  if ui_context.dashboards:
    dashboard_context = f"""
    Current dashboard: "{dashboard.name}"
    Visible insights: {[insight.name for insight in dashboard.tiles]}
    Applied filters: {dashboard.filters}
    Date range: {dashboard.date_from} to {dashboard.date_to}
    """

  if ui_context.insights:
    insight_context = f"""
    Current insight: "{insight.name}" 
    Query type: {insight.query.kind}
    Events analyzed: {insight.query.events}
    Breakdown: {insight.query.breakdown}
    """

  return f"User context: {dashboard_context}\n{insight_context}"

You also need to handle “context” within the workflow (aka state). As the conversation progresses, you don’t want that context to be lost, and this is especially likely to happen when you have multiple sub-agents. To get this right, we store and include context through every part of the workflow like this:

class AssistantState(TypedDict):
  messages: list[BaseMessage]
  intermediate_steps: list[AgentAction]
  plan: str | None
  current_query: SupportedQueryTypes | None
  visualization_result: dict | None
  # ... plus error handling, retry counts, etc.

We find doing this, combined with optimizing our model choice, is more effective and useful than fine tuning a model would be.

5. Steer AI to success with query planning and conditional routing

AI will run off and do all sorts of crazy things if you let it. It needs guidance to be successful.

We do this by orchestrating and chaining together multiple steps like query planning → data retrieval → visualization.

Beyond state management, this requires:

• The AI knowing what tools and data it has at its disposal.

• Being able to select the correct tools and data based on the intended task.

• Making sure those tools, like query execution and formatting, actually work.

In PostHog, at the highest level, this functionality comes from a router like this:

# From root/nodes.py
def router(self, state: AssistantState) -> Literal["insights", 
"search_documentation", "billing"]:
  if self._should_generate_insight(state):
    return "insights"
  elif self._should_search_docs(state):
    return "search_documentation"
  # ... etc

Each node of the router then has its own conditions to route through to get to the right data and tools for the job. This ensures the AI has the pieces it needs to complete the task and makes successfully completing that task more likely.

6. Plan for failure by adding monitoring, guardrails, and error handling

Ideally all the structure you’ve built up to this point prevents failure, but you still need to give the AI guardrails because it will inevitably smash into them.

First, you need to know when something goes wrong, so implement monitoring from the beginning. Georgiy from our Max AI team relayed how important this is:

Monitoring production traces is essential. We even built a monitoring tool for dogfooding, and I wish we had that tool from the beginning. It becomes harder to monitor traces at scale (we’re here), so online evaluations will be helpful (our next priority).

It’s hard to review 100 conversations. It’s impossible to review 1,000 conversations per day. Those conversations are real-world user questions and struggles, and provide all the insights you need to build the agent.

Second, anything an AI can hallucinate, it will hallucinate. To prevent this, we are explicit about the data that needs to be set directly, and the rules it needs to follow.

In our AI installation wizard, for example, we include rules like:

• Never hallucinate an API key. Instead, always use the API key populated in the .env file.

• Do not add placeholder comments like "// In a real app..."

• Do not modify the existing business logic or add simulation code

• Never import new packages or libraries that aren't already used

• Do not assume any authentication library (Clerk, Auth.js, etc.) is available

You also need guardrails for people. When people see an empty text box, they get scared and forget everything.

The solution? Add suggestions for how they can use your AI-powered features, nudge them in the right direction, and help them remember what’s possible.

Beyond issues with humanity and hallucination, sometimes your workflows just break. You need to be able to handle these gracefully with retries and rate limiting.

For real pros, you can also set up LLM analytics, error tracking, and feature flags to help. Conveniently we provide all three, which is a weird coincidence.

Improving your feature

AI models are evolving rapidly and in unpredictable ways, so your AI-powered features require more maintenance and continual improvement than you might expect.

From experience, here's what we've found is most important when trying to do this:

7. Avoid AI knowledge silos

Building AI-powered features shouldn’t be the responsibility of some “AI guy” on your team. AI should be deeply integrated into your product and this means you need the expertise of the people talking to users and building something for them.

There are a few ways you can encourage this:

• Build primitives and make your AI functionality composable, so teams don’t need to re-invent prompts, streaming, consent, evals, and analytics. This helps teams focus on unique and value-added AI functionality.

• Have a consistent UX pattern across your app. For us, that’s Max. This prevents death by a thousand AI widgets.

• Get your AI experts to embed in teams temporarily to help those teams build AI functionality (our Max AI team does this). This helps AI-powered features get built faster while distributing AI knowledge throughout the organization.

8. Focus on speed

One of the big challenges with AI-powered features, especially complex ones, is that they are slow. A workflow can often mean multiple calls to LLM providers, which can add up to a lot of time waiting for responses. This can be especially frustrating when alternative ways to complete a task exist in an app or website.

As the founder of Superhuman, Rahul Vohra, noted in Lenny’s Newsletter:

The thing we’ve learned: speed wins.

Take, for example, Instant Reply or Auto Summarize. Gmail and Outlook have similar features, but you have to generate the replies and summaries on demand—and then wait for them to finish generating.

In Superhuman, we pre-compute them, so they are always instantaneous. That simple difference is a massive lever on the user experience.

Some ways to improve this:

• Be aware of model benchmarks and new model releases. When a better, faster model releases, test it out and use it. This can often have the biggest boost to both functionality and speed. Use LLM analytics to test this.

• Mix fast and slow models depending on the task. We use fast models, like gpt-4.1-mini and gpt-4.1-nano, for title generation, session replay filters, survey summarization, and insight search. We use slow models (like gpt-4.1) for schema generation, conversation handling, and context management.

• Use async processing. Complex AI operations, such as session summaries and pattern extraction, run asynchronously via Temporal workflows to avoid blocking user interactions. These are then cached in Redis to support retries without recomputation.

9. Constantly monitor and evaluate effectiveness

Your new feature shouldn’t be judged less strictly just because it’s ✨ AI ✨.

Not only can the wrong idea make your product worse, changes in models can negatively impact the experience without your knowledge.

There are multiple methods we found work best for evaluating effectiveness:

• Add evals early. We found even small golden or synthetic datasets were giving insane performance boosts compared to the typical development cycle. Even at our scale, implementing this was an easier task than expected. This makes building future features faster too.

• A/B test AI-powered features vs the normal experience as well as different prompts, contexts, workflows, and more.

• Check AI usage rates for different types of customers – e.g. free users vs enterprise, or product vs sales. We found product managers and marketers were using Max more often than our ideal customer profile of product engineers, which led us to reconsider our roadmap.

• Let users rate AI responses as good or bad. When users rate responses poorly, ask them for more details. Use this to tweak context, prompts, and workflows.

• Compare AI vs non-AI usage using your existing activation and retention metrics. This helps you understand where AI ideally fits into your product and user lifecycle, and whether it’s having a positive impact.

Wrapping up

These nine lessons are not isolated takeaways, they work in tandem. It’s a mistake to skip to the end and think that optimizing evals = building a great product.

Remember, you’re aiming to build something valuable to users, not shiny tech demos. Just because it’s AI does not mean users will find it valuable.

All the lessons you’ve learned about building great products still apply. Talk to users, ship fast, run experiments, and repeat.

Words by Ian Vanagas, who wrote this newsletter by hand as much as he would have liked to one-shot it with AI.

🧑‍💻 Jobs at PostHog

Did this post get you nodding along? Looking to join a team that builds like this? We’re hiring product engineers and more specialist roles like:

• AI Product Engineer

• SalesOps Backend Engineer

• ClickHouse data platform engineer

• Developer who loves writing (write for this newsletter!)

More jobs at PostHog

In the early days of a startup, there’s clarity.

You’ve got a tight team. Everyone builds the product. Everyone’s “customer-obsessed”. Everyone is scrambling for product-market fit.

The org chart is a circle with a post-it note saying “build something people want”. A customer wants to pay the SSO tax? Say no more.

But then you grow. Areas need to be split up for ownership. Some bits get chopped up cleanly, others turn into murky waters. This is where the problems start.

Two types of teams

As product-focused companies scale, you’ll hear calls for two kinds of engineering teams1: back-office teams and glue teams.

People think they’re the same because they both:

1. Span multiple product areas.

2. Own features and problems no one else wants to own.

3. (Theoretically) bring order to previously messy and opaque systems.

Spoiler: they’re worlds apart.

Back-office teams serve other teams. Period.

Their customers are on the same payroll. Like the back office of a bank, paying customers never see them.

They provide backend infrastructure, build developer tools, maintain component libraries, and run data platforms. It’s neat stuff. Stuff that makes developers happy.

But back-office teams are always one layer removed from real impact.

They make tools that help people who help users. There’s a layer of indirection, and an inevitable loss of context.

Blink, and that team just spent a week solving an internal problem with minimal impact. Useful? Sure. Valuable? Not so much.

Glue teams serve users. Directly.

These folks do glue work at the level of the product. They’re product teams that just happen to cut horizontally across features instead of owning vertical slices.

Think, auth. Not flashy, not a standalone product line, yet it keeps the product together in one piece. It makes or breaks enterprise deals, or a user’s day.

Billing? The ultimate glue. That’s systems, UI, and accounting, all in one. The spice must flow.

The folks owning these areas should be talking to users, they should be owning product metrics.

Resist the calls for nice-to-haves

People want more back-office teams as you grow because it feels safer. They soothe anxiety. Reduce chaos. “It would be nice to have XYZ”, they say.

But here’s the uncomfortable truth: you can get away without back-office teams much longer than you think, and you should.

I know. Engineers are complaining about CI. Internal tools could be better. Still, keep that zero degrees of separation from customers for as long as you can.

The space of possible work is infinite; the set of tasks needed for success? Surprisingly narrow.

Distance from users makes it hard to see which is which, whether you’re an engineer, designer, or founder!

Distributed ownership is the name of the game for those internal aspects. It takes some healthy agency, for example:

• One person improves the dev environment as a side quest.

• Someone else maintains the component library between feature work.

• Another migrates you to the latest language version.

It’s not their full-time job, and it shouldn’t be yet. And, for the hairiest problems, you agree to spin up a short-lived project team to address that specifically.

Obviously, some back-office work is an early must-have. You won’t get far without a clear owner of data infra, especially if you run a data-intensive SaaS like we do at PostHog.2

But, beyond the absolute essentials, only start a back-office team when you can honestly call its resources a rounding error compared to product development. Backend infra at 20 engineers, anything else at 50+.

Until then – a little bit of chaos is valuable: desirable, even. It teaches everyone which problems actually matter.

Address must-have gaps

Meanwhile, it’s easy to set aside shared areas of the product and forget about them. Don’t mistake them for back-office functions. This is precisely where you need glue teams.

We’re talking about aspects users hit all the time. Customers using your SDKs across 10 platforms? Without dedicated owners, the quality of those SDKs plummets over time. Paying users suffer, and not only them, as the mess is also making other teams less productive.

Auth? Billing? You already know the story.

Those glue areas don’t bring product-market fit by themselves, but neglecting them sure as hell can lose you product-user fit.

The bottom line

Spin up back-office teams when the ROI of such a team starts feeling unreasonably large – much later than you think.

Spin up glue teams when users run into pain in cross-cutting areas of the product – often earlier than you think. Keep building something people want this way.

And remember: an org that over indexes on back-office teams early will:

1. Optimize for fluffy internal goals more than real value.

2. Create an approval culture that erodes autonomy and slows you down.

That’s a death sentence, so choose wisely.

If you liked this, consider sharing it on Hacker News, X, LinkedIn, or your internet points provider of choice. You can subscribe here – it’s free and always will be.

🧠 Good reads for people who build cool stuff

• How we use PostHog's built-in data warehouse – Ian Vanagas

• Why LLMs Can't Really Build Software – Conrad Irwin

• Everything I know about good system design – Sean Goedecke

• If you're remote, ramble – Steph Ango

Being a team lead is a strange job. You still code, but now the team's success is your responsibility too. It's two full-time jobs.

And here's the tricky part: it's easy to slip into habits that slow your team down, kill motivation, and stall progress.

These are some failure modes we sometimes see among team leads at PostHog, and how to avoid them.

They're written for senior engineers, tech leads, staff engineers, EMs – basically anyone guiding a team, whether it's in their job title or not.

1. You’re always the bottleneck

Symptom

You insert yourself into every decision, review every PR, and plan every ticket. Shipping grinds to a halt as everyone waits for your decisions.

Why it happens

In an effort to keep quality high and make the right calls, you start acting more like a PM than an engineer. It's the easiest way to feel in control. Unfortunately, it also turns you into a bottleneck.

How to fix it

Don't treat engineers like children. They're capable of making great product decisions and owning their impact.

Here are a few ways to empower them to do that:

• Work transparently. It gives your team the visibility and context they need to make smart, independent decisions. Use public Slack channels and shared docs.

• Push decisions down. When someone asks, "Should we do X or Y?" reply with, "What do you think and why?". Ship their answer if it's 80% as good as yours. This builds trust and confidence.

• Don't be the sole point of communication between your team and others. Instead, connect the right people together. Act as a bridge, not a gate.

• Define outcomes for your team, not tasks. How they get there is up to them.

🏆 You'll know you're successful if: You can disappear for two weeks without affecting the quality and frequency of releases.

2. You stopped writing code

Symptom

Slack is your new IDE and your calendar is a Tetris game of stand-ups, retros, and quick syncs. Your GitHub graph looks like an empty game of minesweeper.

Why it happens

Meetings are the easiest way for you to keep an eye on things, so now you only manage the work instead of actually doing it.

Another factor is ego: all those invites make you feel important. They create an illusion of productivity, and nobody pings you afterward asking what you actually got done.

Before you know it, you're stuck in a doom loop: more meetings → fewer commits → coding skills fade → you hide in meetings → repeat.

How to fix it

Aim for 80‑90 % of your week in the codebase. Kill the meetings and work asynchronously. Here's how:

• Add at least two no-meeting days in your team's calendar.

• Batch 1:1s, skip a cycle, or consider skipping them altogether.

• Replace daily stand-ups with async updates in Slack.

• Record Loom walk-throughs instead of live demos.

• Default to written RFCs instead of meetings. Give teammates 24-48 hours to comment, then merge the doc and treat it as a source of truth.

• Cancel all reoccurring meetings and only add back the ones you really need.

🏆 You'll know you're successful if: You spend the majority of your time coding. Your team's respect comes from what you've shipped, not what you've said.

3. You're scared of changing goals

Symptom

Mid-quarter you discover growth is flat and churn is increasing, but you move ahead with what's on the roadmap. By the time the quarter ends, the team has delivered everything except real impact.

Why it happens

You're scared of rocking the boat, or looking like a failure if you change goals. It's easier to keep moving than to admit you're going in the wrong direction.

How to fix it

Add a regular feedback loop to evaluate your team's progress.

At PostHog, we do monthly growth reviews. We gather all available data – revenue metrics, product analytics, user feedback, etc, then, the team meets once a month to discuss hard questions like:

• Are our 10 biggest customers happy users of the product?

• Where is churn spiking and why?

• Are new releases shifting core metrics or just vanity stats?

• What surprised us in user interviews?

• Where are users struggling?

This paints a full picture of how the product and team are doing. Then it's up to you to decide if the team should continue on their course or if something needs to change.

🏆 You'll know you're successful if: You're confident your team is working on the most important tasks nearly all the time. Your reviews end with projects being removed from the roadmap because the data showed better opportunities. At the end of the quarter, your core metrics are higher than ever.

4. You don't keep the talent bar high

Symptom

The same bugs and sloppy PRs keep reappearing from the same people, yet no one seems surprised.

Why it happens

You're scared of giving hard feedback, so mediocrity coasts by unchecked. Gradually, your expectations lower and buggy code becomes the standard. Before you know it, you're fighting the same bugs every week instead of making real progress.

How to fix it

Run the Keeper Test quarterly: "If this person resigned today, would I fight to keep them?".

Dig into where the answer is "no" and ask yourself what would it take for it to be a "yes". Be honest about what’s missing: is it skill, mindset, ownership, or impact?

Then, address it immediately through coaching, clearer expectations, or, when necessary, parting ways.

🏆 You'll know you're successful if: Your team has a strong reputation for delivering results, and it's the one everyone wants to join.

📝 Side note: Anyone can ask their team lead "how hard would you work to change my mind if I were thinking of leaving?". It's a great way to get valuable feedback.

5. You're always the hero

Symptom

You personally fill in every gap, put out every fire, and jump in whenever the team hesitates, all while juggling your regular work. Your day starts way before breakfast and ends late into the night. You're exhausted and slowly burning out.

Why it happens

When your team isn't yet confident or experienced enough, handling things yourself feels like the fastest way to get things done. But over time, it teaches your team to escalate rather than solve. What saved time in the short term starts costing you in the long run.

How to fix it

• Pair once, then step back. The next time something gnarly comes up, co-solve for an hour with the right person, then step back. Next time, they own it.

• Document as you go. Treat every hero moment as an opportunity to write a short runbook or doc.

• Upskill with micro-talks. Ask people who've just mastered something to give a 5-minute lightning talk in the next team meeting.

• Hire for constraints. When you realise the work no longer matches anyone's strengths, treat it as a signal that you need to bring on a new person to the team.

🏆 You'll know you're successful if: you're no longer the first name that pops up when something breaks, and the fix is merged before you even open Slack.

Words by Lior Neu-ner, who hates leaf blowers and lawn mowers equally.

🧠 Some more food for your brain

• I Know When You’re Vibe Coding – Alex Kondov

• Reflections on Open AI – Calvin French-Owen

• My AI Skeptic Friends Are All Nuts – Thomas Ptacek

1. We're a dev tool who markets mostly to software developers.

2. We care a lot about our brand, content, website, and launches. Other marketing channels, less so.

Here's what we've learned about marketing for developers.

1. If you wouldn't be proud to share your marketing with a friend, you shouldn't do it.

2. Do something remarkable. Marketing something remarkable is easy.

3. Developers build things because what exists isn't good enough. Tell people that! Be opinionated, unhappy with the status quo, and take a stand. Don't follow the crowd or dilute your message with a bunch of corporate speak.

4. Building a great product and telling people about it is a more sustainable path to success than spamming people with generic content, ads, or emails. Putting in the effort to make what you produce a bit higher quality pays off.

5. Assume your audience is smart. Don't try to trick them with tedious, clickbaity, hyperbolic marketing tactics. It's patronizing. Make honest claims about the functionality of your product. Don't unfairly or make false claims about competitors.

6. Marketing lore tells you to focus on the why, but we think the opposite. Focusing on benefits rather than features is tired, the language is vague, it makes it harder to understand what something does. Trust that your customers can figure it out and focus on features instead.

7. Your entire strategy is downstream of your ideal customer profile. For any decision (marketing and beyond), ask yourself what your ICP wants and what will be useful to them. You need to create your brand for someone. For us, that's product engineers at high growth startups.

8. The best way to create your ICP is to start with your best guess and test it. Figure out what your customer needs, what they have, and what they don't need. Gather intel, ask questions, and fill in details from there.

9. Because our ICP is developers, we hire developers to do marketing. This gives us the skills we need to understand developers, speak their language, and create content they find genuinely useful.

10. Speak like your users. Find out the terms and phrases they use and use those. Talking to users is a great way to figure this out. Doing so helps make your product legible to them.

11. Word of mouth is the best marketing. Overly optimizing for revenue can kill this as it encourages you to obsess over sales rather than building a great product and brand. Marketing is a lot easier if you have a great product to back you up.

12. Think of the biggest reasons that would stop someone from using your product and address those with your marketing. Early at PostHog, these were people doubting whether the team was strong and if the product would exist. Our public handbook was our solution to this.

13. Treat your website like a product and invest in it accordingly. In lots of ways, your website is your best sales person and is key to getting people to self-serve successfully.

14. On the other hand, your brand isn't just your website, it's how your company is experienced by others. This can include how much you invest in each function, what you look for when hiring, your reputation in the community, what you talk about, and more.

15. You're not going to win by copying what your competitors are already doing. This means you should be weirder, more opinionated, and go a bit more in-depth. As our lead designer Cory says: "We aren't the best in the world at being polished, but we can be the best in the world at being ourselves."

16. You can't 80:20 everything. A lot of brand work has an increasing marginal return. This is because a great brand's purpose is that you stand out. You don't stand out by being average! We have spent a ton of time making our merch world-class (and figuring out a lot of logistics to make it happen).

17. On merch, it's cool and people love it, but it does take a lot of work. Fulfillment companies are a pain (we've been through 3 in 2 years). Also, don't expect to make any money from it, we give most of ours away.

18. Video is similarly difficult. It's easy to create mediocre videos, but high-quality ones that capture a ton of attention are hard. Video requires much more planning, coordination, equipment, and time than most marketing does.

19. Identify what you want to be great at and spend your time there. List the areas you don't want to spend time on too, otherwise you will be distracted by a bunch of random opportunities and never go into the depth you need to succeed in one channel.

20. Compete on depth rather than breadth. Larger competitors will always be able to do “more” marketing than you are, so you need to focus on quality to stand out. When we choose to spend time on something, we invest a lot more into it than others usually do.

21. Never underestimate the power of being funny on the internet. Many people discover us from James' social posts, our onboarding emails, or our DPA generator.

22. To keep quality high, enforce reviews on your content (like you would with code). Start with big picture feedback and go into line edits and details later. Early feedback can save you a lot of time when the feedback is “you should probably ditch this entirely.”

23. SEO still matters in the age of AI (people have been saying it's dead for a decade), but it's a long play. Expect it to take 5 to 6 months to see progress. This means it's less valuable before product-market-fit.

24. If you're looking for a place to start with SEO, start with defensive SEO. This means comparisons with competitors, how to integrate your product with others, and the best tools in your category. These can act as sales collateral, but are also high-intent.

25. Another good option are low volume keywords. These are easier to rank for and can create a solid base of traffic. Writing dozens of these can create a steady stream of traffic. This adds up so don't underestimate them.

26. Google is dumber than you think. It doesn't understand your content. It understands user behavior. Users clicking and spending a lot time on reading shows it is good. This means you should care about first impressions and realize that quality really matters.

27. If your content doesn't rank well, it's probably because it just isn't very good. Would you share it with a friend you like and respect? Would someone who knows a lot about the topic share it? Is it opinionated? If not, try to improve this first.

28. AI platforms like ChatGPT seem to be more influential than Google already. We've seen a 41x increase in visitors from AI platforms in the last 12 months as well as a 15x increase in them being mentioned on signup since November.

29. No one has figured out how to improve your visibility on AI platforms (AKA "generative engine optimization") yet. We're relying on our SEO content, but also added LLM-friendly features like llms.text and "Copy as Markdown" to our site.

30. Build a channel you actually own, like email. Twitter, LinkedIn, or praying for HackerNews success is fickle and transient. This is why we launched our newsletter. Other options include creating a Discord, subreddit, or podcast.

31. HackerNews is a double-edged sword. Although a lot of people see it as the ultimate success for marketing and it provides a huge ego-boost, the actual signup boost you get from it is much lower. It's also unreliable, even if you're great, you'll have a 1 in 10 hit rate (and don't try to game it).

32. You should care a lot about launches. These are opportunities to capitalize on the work people put into building a product or feature and break through the noise. Doing this well gives products momentum to help them succeed.

33. Beware the attribution mirage. UTM parameters might tell you users come from one source, but the reality of where they heard about you is likely different. A user could read an article they found, search “posthog,” and click a Google Ad. This would tell us “Google Ads are awesome” when maybe that isn't the case.

34. Although not perfect, a counter to the attribution mirage is a box that asks “where did you hear about PostHog” on signup. This provides a lot of interesting insights about what's working and a bunch of unexpected sources to explore.

35. When it comes to paid ads, there are two objectives you should care about: conversion and awareness. Conversion means people click your ad then do something you want (like sign up). Awareness means you just want people to see it, they create demand. We split our budget 50/50 between the two.

36. You might read this and think you are immune to ads; and therefore, they are useless. You're wrong. Ads work on you (and developers like you), we've collected the quantitative data to back this up.

37. You cannot simply outsource your marketing to an agency. They can be helpful with paid ad creative, setting it up on the ad platform, and analyzing results, but you need to give constant guidance, feedback, and ideas to make the most of them.

38. To get started with paid ads, run a lot of experiments across multiple channels. Each will need ~$500 and 2 weeks. Try Google Search brand keywords, relevant keywords, and cheap awareness campaigns on Twitter or Reddit.

39. It's ok to waste money on sponsorships. A majority of them don't work, but some are big hits. Ask your users who they actually read and watch and sponsor them.

40. People love getting an honest look behind the scenes (like this one). James' early posts on moving to SF and raising money were early marketing successes and led to transparency being a core part of our brand (and company).

Words by Ian Vanagas, “technical content marketer”

• Makes and owns product decisions

• Talks to users and cares deeply about their needs

• Cares more about outcomes than shipping perfect code

• Is opinionated about what they should be building

• And can back that up with persuasive arguments

• Understands how their work impacts the business

• Tests in production and iterates with real users

• Thrives when given autonomy to engineer every element of the product

We see first hand how developers who work like this deliver amazing results. They ship faster, spark joy in customers, and have a lot of fun doing so. It's satisfying.

That's the good news.

The bad? Product engineer roles are harder to find and harder to win. You have to be cracked. You have to really want it and you need to know where to look.

1. Choosing the right companies

This is harder than it sounds.

Typing "companies that hire product engineers" into Google doesn't work. ChatGPT has some smart suggestions, but it will only get you so far.

None of these points are universally true, but here's what we'd look for:

• Founder-led companies, provided at least one of the founders is an engineer. Companies that are no longer led by their founders are less likely to maintain a strong product engineering culture.

• Early and growth-stage startups. Inevitably, startups are often the first place to look if you want a product engineer-style role, though companies like GitHub and Intercom prove larger companies can be great places for product engineers too.

• High engineer ratio. A company with a high ratio of engineers is more likely to give them autonomy in decision making, especially product decisions. A lower ratio doesn’t mean a company is a bad place to work, but it’s less likely to give engineers autonomy, or have adopt a maker’s schedule.1

• Product-led companies – i.e. companies that are self-serve with a free tier, user-centric, and where growth is driven by product usage. This is a great environment for a product engineer because they put users, not buyers, first. PostHog is a product-led company, as are companies like Supabase, Cal.com, Tailscale, Notion, and Vercel.

• Bootstrapped companies can be a great place for an aspiring product engineer to develop their skills. Bootstrappers value efficiency and people who want to take ownership. Look out for bootstrapped open-source companies, especially.

• Low-meeting culture. Most early-stage companies will be like this by default, but this is something you'll have to check for during interviews. Explicit meeting-free days and a preference for async communication are good signs. Dig into how decisions are made during interviews.

Red flags

• No engineers as founders. A company where none of the founders are engineers is unlikely to foster a product engineer culture, and more likely to view engineering as a cost center that needs to be “optimized”.

• Declining headcount. Companies that have let go of people recently are unlikely to be healthy, and any unhealthy companies aren’t a great place for engineers seeking autonomy.

• Enterprise-ey vibes. White and blue websites. No public pricing. Generic messaging. These are all signs that a company is going to be sales-led and focused on selling big contracts to slow-moving companies. Many huge companies are built this way, but they’re not a great place for product engineers.

2. How and where to find them

You're unlikely to find these companies and their open roles on Indeed.

The obvious place to start is Y Combinator's Work at a Startup job board – it's the largest and most well-known startup accelerator the culture of YC is inherently product-engineer friendly.

When searching, do the following:

• Filter Role by Engineering

• Filter Company stage by Seed, Series A, and Growth

• Tick the Show founder details option (this is important)

• (Optional) Filter by company size depending on your preferences

Now experiment with a few search parameters that communicate the values we want, such as:

• product engineer

• product-minded

• autonomy

• open source

• ownership

This will help narrow down your search to roles and companies that are looking for product engineer-style people.

Pay attention to how much detail companies add to their profiles. Most will include a basic bio of the founders, what they're building, and their tech stack; the really good ones will go into the detail about the type of company they want to build.

Other companies may have this kind of context on their careers website, or in their ads, but many don’t. Fostering a product engineering culture requires intent. Anyone with intent should want to tell people about it.

Other places to look

• Monthly Who's hiring? thread on Hacker News – good for engineering-led startups

• Launches on Hacker News for new companies that might be hiring

• Trending on GitHub for finding open-source startups that are gaining traction

• Brian's Job Search, which makes it easy to search ads hosted on popular application tracking systems, like Greenhouse, Lever, and Ashby

• VC job boards like Sequoia and a16z

• LinkedIn alerts using its AI search (the prompt "jobs for product-minded engineers at startups and scaleups" provides some good results)

• Our Cool Tech Jobs board, where you can filter roles by Engineers decide what to build and High engineer ratio

3. Reading between the lines

Here's the next problem:

1. Product engineer isn't a universally used or understood term

2. Its presence doesn't guarantee the job will be what you expect

You need to learn to read between the lines based on what companies include in their ads, and on their career pages.

Exhibit #1 is a role for a Senior Full-Stack Engineer - Product at Railway. It doesn't use the product engineer title, but its website and ads are packed with good signs.

This bullet point from the "About the role" section stands out:

"Write Engineering Requirement Documents to take something from idea, to defined tasks, to implementation, to monitoring its success."

This is a great summary of what product engineers do. Own the idea and execution, but also following through and owning its success.

The "About you" section (below) backs this up and emphasises on the need to "lead autonomously" and work in a "mostly-asynchronous manner". Railway has clearly thought deeply about how to communicate what it wants, so tip-of-the-hat to them.

Incident.io nails the key points, too. I particularly love the focus on interacting with customers, and navigating ambiguity – a vital quality for any product engineer.

It's not just early-stage startups that want product engineers. Intercom’s career pages emphasize shipping fast, agency, autonomy, and “full ownership of what we build from beginning to end."

An interesting contrast is Vercel, which advertises some roles as "product engineer", but mostly focuses on technical requirements. In these situations, a little due diligence using Glassdoor (if you can tolerate the UX) and Blind can help you research the culture.

Remember, too, that culture can vary from team-to-team in larger companies, so it becomes more about asking good questions at the interview stage, like:

• "What are the company / team values, and why?"

• "Can you give me some specific ways you follow them?"

• "Who decides what to build?"

• "What does a typical work day look like?"

• "What are the things or behaviors that would cause a person in this role to fail?"

4. Increasing your odds

You need to think like a recruiter.

You may spend hours, days even, researching a company, crafting a cover letter, resumé, and so on, but even mid-sized startups get hundreds of applications.

We typically average one minute per application review, but this is just an average. Some applications can be dismissed in seconds, which gives us time to spend five to 10 minutes reading the really good ones.

Your goal is to be in the 5 to 10-minute cohort. You can increase your odds by:

a) Writing a short and obviously personalized cover letter

• 5-10 sentences on why you're interested in this role specifically is fine. No essays

• Don't just re-write your CV

• Don't use ChatGPT. It's really obvious

• Figure out what the company cares about and share how you can help

• Share what you find interesting and motivating

Not writing a cover letter might work for bigger companies that are hiring at a huge scale, but not submitting one (especially if asked) just gives a recruiter a reason to ignore you.

b) Keeping your resumé simple and up-to-date

• Prioritize clarity over design

• No profile pics. This isn't social media

• Keep your LinkedIn up-to-date – big discrepancies are suspicious

• If you took a career break, just say so. It's not a big deal. Unexplained gaps are

c) Showing your product engineer credentials

• Side projects are great. Building something people actually pay for is even better. This is where the real war stories come from, where you can talk about decisions you made, user interactions, and what you learned. It’s proof you can do everything needed to be a product engineer.

• Write about your experiences. A personal website where you write about things you've built, lessons you learned, tools and technologies you've chosen and why, will add color to your application.2 You don't need to go viral on Hacker News. The habit is enough to build a narrative that gets you an interview.

• Start a company! Ok, this is a stretch goal, but ex-technical founders make great product engineers. We look for them specifically.

• Contribute to open source. Being a great contributor is both good for your resume, and can actually land you jobs at those companies, especially when they're early-stage companies. Fixing typos in their docs doesn't count.

The more of these things you do, the more likely your application will get 10 minutes, rather than 10 seconds, of someone’s attention.

Further reading:

• How to get a job at a startup

• Interview questions engineers should ask (but don’t)

• What startup recruiters actually see when you apply for a job

🧠 Things we’ve been feeding our brains with

• Introducing Max AI – PostHog

• If you are useful, it doesn’t mean you are valued –

• Product engineers – Lee Robinson

• Dotfiles Are Meant to Be Forked – Zach Holman

• Efficiency trades off against resiliency – Nelson Elhage

• Reverse engineering Claude Code – Kir Shatrov