PostHog built a $450M company without product managers
That 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.
The PostHog organizational model
Small teams, full ownership
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:
- Product Analytics (the core dashboards and insights product)
- Session Replay (recording user sessions)
- Feature Flags (experimentation and rollouts)
- Surveys (in-app user feedback)
- Data Warehouse (connecting external data sources)
- Web Analytics (lightweight website tracking)
- Pipeline (event ingestion and transformation)
- Infrastructure (keeping everything running)
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.
What "no PMs" actually means
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:
- Talk to customers directly via Slack community channels, support tickets, and user interviews
- Prioritize their own roadmap based on customer feedback, usage data, and business goals
- Design solutions (sometimes with input from their one-person design team per area)
- Build and ship with minimal review overhead
- Measure outcomes using their own product (naturally)
- Write public content including changelog entries, tutorials, and blog posts
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.
Why they killed the PM role
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.
How PostHog hires product engineers
The profile they look for
PostHog's job descriptions are refreshingly specific about what they want. Based on their public listings and handbook, the ideal candidate:
- Has 5+ years of software engineering experience
- Has shipped products that real users relied on
- Can articulate opinions about what to build, not just how to build it
- Writes well (because so much of the role involves written communication)
- Feels comfortable talking to customers without a PM as intermediary
- Has strong opinions about product quality and user experience
- Prefers shipping fast over planning extensively
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.
The interview process
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.
What disqualifies candidates
Based on patterns from people who have shared their PostHog interview experiences publicly, common rejection signals include:
- Asking too many clarifying questions before attempting a solution (suggesting spec-dependency)
- Proposing overly complex architectures when a simpler approach would work
- Focusing on edge cases before solving the core problem
- Not demonstrating curiosity about users or business impact
- Writing code that works but is difficult for others to understand
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.
What PostHog pays product engineers
Compensation philosophy
PostHog uses a transparent compensation calculator. It is one of the few companies that publishes their salary formula publicly. The formula factors in:
- Role level (IC5, IC6, etc.)
- Location (adjusted by a location factor based on cost of labor)
- Step within level (experience progression within a given level)
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.
Location-based pay adjustments
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.
A day in the life of a PostHog product engineer
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):
- Check PostHog usage data for your product area (literally using the product you build)
- Read and respond to user feedback in the community Slack
- Review any open PRs from teammates
- Ship a small improvement that has been in progress
Midday (focused building):
- Work on the primary project for the sprint (2-week cycles)
- Make design decisions on the fly, consulting the team designer when needed
- Push code to production (PostHog deploys multiple times per day)
Afternoon (communication and planning):
- Write a brief update in the team channel about what shipped
- Participate in one 30-minute standup (the only recurring meeting most teams have)
- Record a short Loom for a feature you shipped, for the changelog
- Read customer support tickets to identify patterns
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.
The PostHog model compared to other product engineering cultures
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.
From my perspective: what PostHog gets right and wrong
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.
Should you apply to PostHog as a product engineer?
You would thrive there if:
- You have opinions about what to build, not just how
- You find talking to users energizing rather than draining
- You prefer shipping imperfect things fast over shipping perfect things slowly
- You write well and enjoy public communication
- You are comfortable making decisions without approval from above
- You want your impact measured in user outcomes, not story points
You would struggle there if:
- You prefer deep technical challenges over product breadth
- You dislike context-switching between coding, writing, and user research
- You need clear specs before you start building
- You find customer conversations awkward or unproductive
- You value stability and process over speed and ambiguity
- You define seniority by technical depth alone
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.
The broader implications for the industry
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.
Key takeaways
- PostHog eliminated product managers entirely and gives every engineer full ownership from problem discovery to shipped feature.
- Their hiring prioritizes product thinking over specific technology expertise; they teach the stack, not the instinct.
- Engineers watch session recordings of real users within hours of shipping and write public ship reviews with data.
- The PostHog model proves that small, autonomous teams of product engineers can outship much larger organizations.
FAQ
What tech stack does PostHog use for product engineers?
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.
Do you need product management experience to be a product engineer at PostHog?
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.
How does PostHog's product engineer salary compare to FAANG?
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.
Can PostHog's no-PM model work at larger companies?
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.
What is the career path for a product engineer at PostHog?
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.