Dispatch from the Future: What AI-Native Companies Look Like
What an AI-native company actually looks like in 2026. 5-person teams doing what 50 did, built from day one with agents as first-class teammates.
Aug 20 · 18 min readInside the product engineer role at PostHog: how they hire, what they pay, why they killed PMs, and what the day-to-day actually looks like.
Felipe BarreirosSr. Product Engineer @ AWS
Leading a tech product at AWS with 35 engineers impacting 6.1M customers across 16 languages. 2x founder with exits (acquired by NASDAQ:XP). Coached 12,000 tech graduates. TEDx Speaker. Global Shaper by World Economic Forum. Building product.engineer because 2026 is the year engineers own the full product cycle.
What an AI-native company actually looks like in 2026. 5-person teams doing what 50 did, built from day one with agents as first-class teammates.
Aug 20 · 18 min readProduct engineer vs designer: how UX ownership works when engineers make design decisions. A collaboration model that ships faster.
Aug 19 · 16 min readA product design engineer works in physical hardware. A product engineer ships software outcomes. See how these roles differ in skills, salary, and career path.
Aug 14 · 13 min readThat is not a typo. PostHog, the open-source product analytics platform, reached a valuation north of $450 million (as reported in their Series B coverage by TechCrunch in 2023) while employing zero traditional product managers. Instead, they bet everything on a role they call the product engineer. According to product.engineer's guide, a product engineer is a software engineer who owns the entire product lifecycle: talking to users, deciding what to build, building it, shipping it, and measuring whether it worked. PostHog did not invent this concept, but they may have built the most deliberate organizational structure around it of any company at their scale.
This article breaks down exactly how PostHog operates. How they structure teams. How they hire. What they pay. Why they believe product managers create more problems than they solve. And whether this model could work for your team or your career.
Join 2,000+ engineers who define, build, and ship.
One email per week. Practical frameworks for product engineers. No spam.
If you are considering a role at PostHog, evaluating their model for your own company, or simply curious about what product engineering culture looks like when taken to its logical extreme, this is the deep dive you need.
PostHog organizes around what they call "small teams." As product.engineer's research shows, each team typically has two to six people, and every engineer on that team functions in the combined builder-and-owner role. There are no dedicated product managers. No project managers. No one whose full-time job is writing specs or managing backlogs.
Each small team owns a specific product area. As of early 2026, these include:
The team lead on each small team is usually the most senior engineer. They set direction, but they also write code daily. There is no managerial layer that stops coding.
Let me be precise here, because "no PMs" gets misunderstood constantly. It does not mean nobody does product work. It means engineers do the product work themselves. The responsibilities that a PM would handle at a traditional company still get handled. They just get distributed across the engineering team.
Specifically, engineers at PostHog are expected to:
This is not a theoretical aspiration. It is the daily operating reality. PostHog publishes their handbook publicly, and you can read the expectations word for word.
James Hawkins, PostHog's CEO, has written extensively about this decision. The core reasoning comes down to three beliefs:
Belief 1: Context loss kills velocity. Every handoff between a PM and an engineer degrades information quality. The PM talks to the user, interprets their pain, writes it down, and hands a filtered version to the engineer. By the time code gets written, the original context is gone. When the engineer talks to users directly, that compression never happens.
Belief 2: Engineers who understand users build better products. A PM might write a spec saying "users want faster load times." An engineer who watched a user stare at a spinner for 8 seconds understands something deeper than any ticket can convey. The emotional weight of direct observation changes how you build.
Belief 3: Small teams move faster without coordination overhead. PMs spend enormous amounts of time coordinating between design, engineering, leadership, sales, and support. Remove the PM, give engineers direct access to all those channels, and you eliminate meetings that exist purely as information-relay mechanisms.
PostHog's internal data supports this. According to their published metrics, they shipped over 200 product improvements in a single quarter with a team of roughly 45 people. That is approximately one shipped improvement per person per week, which is an extraordinary pace for a B2B SaaS product.
PostHog's job descriptions are refreshingly specific about what they want. Based on their public listings and handbook, the ideal candidate:
Notice what is absent from this list. There is no mention of specific tech stack requirements (though they run primarily on Python, TypeScript, React, ClickHouse, and Django). There is no emphasis on system design at hyperscale. The signal they optimize for is product sense combined with shipping speed.
PostHog publishes their interview process openly. It typically follows this structure:
| Stage | Format | Duration | Focus |
|---|---|---|---|
| Application review | Async | N/A | Resume, portfolio, written responses |
| Culture screen | Video call | 30 min | Values alignment, communication style |
| Technical interview | Video call | 60 min | Coding ability, problem decomposition |
| Product interview | Video call | 45 min | Product thinking, prioritization, user empathy |
| SuperDay | Paid trial day | Full day | Real work on a real problem |
The SuperDay is the most distinctive element. Instead of a contrived coding challenge, they pay candidates to work on an actual problem for one full day. You get access to the codebase, a real issue to solve, and the expectation to ship something (or make meaningful progress). They pay candidates for this time, which is both ethical and revealing. If you can ship real value in one day with minimal guidance, you probably belong in this role.
This approach filters heavily for autonomy. If you need extensive direction, detailed specs, or hand-holding on architecture decisions, the SuperDay will expose that immediately. It is also a filter for shipping speed. One day is not enough time for extensive planning. You have to make decisions quickly and move.
Based on patterns from people who have shared their PostHog interview experiences publicly, common rejection signals include:
The underlying pattern: they reject people who optimize for correctness over velocity, or who build for engineers rather than for users. If you want to prepare for an interview at PostHog, study the patterns we cover in our product engineer interview guide.
PostHog uses a transparent compensation calculator. It is one of the few companies that publishes their salary formula publicly. The formula factors in:
According to their public calculator (as of early 2026) and cross-referenced with Levels.fyi data, compensation at PostHog falls in these ranges:
| Level | US-based total comp | SF/NYC adjustment |
|---|---|---|
| Mid-level (IC3) | $160K - $195K | +15% location factor |
| Senior (IC4-5) | $200K - $270K | +15% location factor |
| Staff/Lead (IC6) | $260K - $320K | +15% location factor |
These numbers include base salary plus equity. PostHog grants equity as options with a 4-year vest and 1-year cliff. For a company at their valuation stage, the equity upside is real but speculative.
Compared to FAANG companies, PostHog's cash compensation is lower. A senior engineer at Google or Meta might earn $350K-$500K in total comp. But the comparison is misleading. PostHog offers something those companies cannot: radical autonomy, direct customer impact, and the absence of organizational bureaucracy. For a deeper analysis of market rates, see our salary breakdown.
PostHog is fully remote and adjusts compensation based on location. Their published bands show location multipliers ranging from 0.55x (lowest cost-of-labor regions) to 1.15x (San Francisco, New York). This is a common practice among remote-first companies, though it remains controversial.
The practical implication: a senior engineer in Lisbon earns roughly 70% of what the same role pays in San Francisco. Whether that is fair depends on your philosophy about paying for labor versus paying for output. PostHog argues that location adjustments help them hire globally while remaining competitive in each local market.
What does the daily reality look like? Based on public employee blog posts, podcast appearances, and handbook documentation, here is a representative day:
Morning (async work):
Midday (focused building):
Afternoon (communication and planning):
What is notably absent: no sprint planning that takes two hours, no backlog grooming sessions, no PM syncs, no design review committees, no architecture review boards. The meeting load is minimal by industry standards. Most PostHog engineers report spending less than 4 hours per week in meetings.
PostHog is not alone in embracing this approach, but their implementation is among the most extreme. Here is how they compare:
| Dimension | PostHog | Linear | Vercel | Stripe |
|---|---|---|---|---|
| Product managers | None | None (founders fill PM-like role) | Few, mostly senior | Yes, but engineers own metrics |
| Team size | 2-6 | 2-4 | 3-8 | 5-12 |
| Engineer customer access | Direct, daily | Direct, frequent | Varies by team | Limited, mostly through PMs |
| Deploy frequency | Multiple times/day | Multiple times/day | Continuous | Multiple times/day |
| Spec-writing responsibility | Engineers | Engineers + founders | Mix | PMs write high-level, engineers own details |
| Public handbook | Yes | Partial | No | No |
| Compensation transparency | Full public formula | Internal only | Internal only | Internal only |
Linear comes closest to PostHog's model but maintains stronger founder direction on product decisions. Vercel gives engineers significant ownership but retains PMs for larger strategic initiatives. Stripe employs PMs but has a strong culture of engineer-driven product thinking.
Having hired over 600 engineers across two startups and AWS, and coached more than 12,000 engineers on career growth, I have seen every flavor of engineering organization. PostHog's model is impressive but not universally applicable.
What they get right: eliminating the context gap between users and builders produces genuinely better products. Every time I have seen an engineer sit with a real user for 30 minutes, their next PR was fundamentally different than it would have been reading a ticket. PostHog systematizes that exposure. They also attract extraordinary talent because their model appeals to the kind of senior engineer who left a big company precisely because they were tired of building specs someone else wrote.
What is harder to replicate: this model requires an exceptionally high hiring bar. Not every engineer wants to (or can) do product work. Not every engineer is articulate enough to write customer-facing content or confident enough to run user interviews. PostHog can maintain this because they are selective, well-funded, and building a product for developers (who are easier for engineers to empathize with). A company building insurance software for claims adjusters would face a different challenge entirely. The domain expertise gap between builder and user is much wider.
If the PostHog model excites you but you are not sure you are ready, read our guide on how to become a product engineer. The transition from traditional software engineering to product engineering is learnable, but it requires deliberate practice in areas most engineers never develop. You can also browse current openings in our product engineer jobs roundup to see how PostHog's listings compare to others in the market.
PostHog's success without PMs is not an argument that all companies should fire their product managers. It is evidence that one specific organizational structure, built around engineer-led product ownership, can produce exceptional results when the conditions are right.
Those conditions include: a developer-focused product, a fully remote company with strong written communication norms, a high hiring bar with a paid trial day, small teams with clear ownership boundaries, radical transparency (public handbook, public compensation, public roadmap), and leadership that genuinely believes engineers should own product outcomes.
If three or four of those conditions are missing, the model collapses. You end up with engineers who do not talk to users, build whatever is technically interesting, and never measure outcomes. That is not product engineering. That is engineering without accountability.
For more on the differences between these approaches, see our breakdown of product engineer vs software engineer.
PostHog's primary stack includes Python (Django) for the backend, TypeScript and React for the frontend, ClickHouse for analytics data, PostgreSQL for application data, and Redis for caching. They deploy on AWS using Kubernetes. However, their hiring process emphasizes product thinking over specific technology expertise. They have publicly stated they would rather hire a great product thinker who needs to learn ClickHouse than a ClickHouse expert who cannot make product decisions.
No formal PM experience is required. What PostHog looks for is evidence that you have made product decisions in the past, whether that was at a previous job, a side project, or an open-source contribution. Demonstrating that you can prioritize based on user value rather than technical elegance matters more than any PM certification or prior PM title.
Base cash compensation at PostHog is typically 60-80% of what FAANG companies pay for equivalent seniority. However, PostHog offers meaningful equity in a high-growth company, radical autonomy, minimal meeting load, and the kind of direct impact that large companies cannot provide. Many engineers who join PostHog explicitly trade cash for ownership and agency. Whether that tradeoff makes sense depends on your financial situation and career goals.
It becomes significantly harder as companies scale beyond 100-150 engineers. PostHog can maintain the model because their product targets developers (reducing the user-empathy gap), their teams stay small (2-6 people), and their hiring bar is extremely high. Companies like Spotify tried similar models and eventually reintroduced PMs at scale. The sweet spot for this pure model appears to be companies with fewer than 200 engineers building technical products.
PostHog offers an IC (individual contributor) track that progresses from mid-level through senior to staff and principal levels. There is no requirement to move into management. The most senior ICs at PostHog influence company-level product strategy while still writing code daily. Some team leads have management responsibilities, but these are lightweight compared to traditional engineering management roles. PostHog explicitly values IC contribution over organizational influence.