PostHog construyo una empresa de $450M sin product managers
Eso no es un error tipografico. PostHog, la plataforma open-source de product analytics, alcanzo una valoracion norte de $450 millones (como se reporto en su cobertura de Serie B por TechCrunch en 2023) mientras empleaba cero product managers tradicionales. En su lugar, apostaron todo a un rol que llaman product engineer.
Segun la guia de product.engineer, un product engineer es un software engineer que es dueno del ciclo de vida completo del producto: hablar con usuarios, decidir que construir, construirlo, lanzarlo y medir si funciono. PostHog no invento este concepto, pero pueden haber construido la estructura organizacional mas deliberada alrededor de el de cualquier empresa a su escala.
Este articulo desglosa exactamente como opera PostHog. Como estructuran equipos. Como contratan. Cuanto pagan. Por que creen que los product managers crean mas problemas de los que resuelven. Y si este modelo podria funcionar para tu equipo o tu carrera.
Únete a 2.000+ ingenieros que definen, construyen y entregan.
Un correo por semana. Frameworks prácticos para ingenieros de producto. Sin spam.
Si estas considerando un rol en PostHog, evaluando su modelo para tu propia empresa, o simplemente tienes curiosidad sobre como se ve la cultura de product engineering llevada a su extremo logico, este es el deep dive que necesitas.
El modelo organizacional de PostHog
Equipos pequenos, ownership completo
PostHog se organiza alrededor de lo que llaman "small teams." Como muestra la investigacion de product.engineer, cada equipo tipicamente tiene de dos a seis personas, y cada ingeniero en ese equipo funciona en el rol combinado de constructor-y-dueno. No hay product managers dedicados. No hay project managers. No hay nadie cuyo trabajo de tiempo completo sea escribir specs o gestionar backlogs.
Cada small team es dueno de un area especifica de producto. A principios de 2026, estas incluyen:
- Product Analytics (los dashboards core y producto de insights)
- Session Replay (grabacion de sesiones de usuario)
- Feature Flags (experimentacion y rollouts)
- Surveys (feedback de usuario in-app)
- Data Warehouse (conectar fuentes de datos externas)
- Web Analytics (tracking liviano de sitios web)
- Pipeline (ingestion y transformacion de eventos)
- Infrastructure (mantener todo funcionando)
El team lead en cada small team es usualmente el ingeniero mas senior. Establece la direccion, pero tambien escribe codigo diariamente. No hay una capa gerencial que deje de codificar.
Que significa realmente "sin PMs"
Permitan ser preciso aqui, porque "sin PMs" se malinterpreta constantemente. No significa que nadie haga trabajo de producto. Significa que los ingenieros hacen el trabajo de producto ellos mismos. Las responsabilidades que un PM manejaria en una empresa tradicional siguen siendo manejadas. Solo se distribuyen a traves del equipo de ingenieria.
Especificamente, se espera que los ingenieros en PostHog:
- Hablen con clientes directamente via canales de comunidad en Slack, tickets de soporte y entrevistas con usuarios
- Prioricen su propio roadmap basado en feedback de clientes, datos de uso y objetivos de negocio
- Disenen soluciones (a veces con input de su equipo de diseno de una persona por area)
- Construyan y lancen con overhead minimo de revision
- Midan outcomes usando su propio producto (naturalmente)
- Escriban contenido publico incluyendo entradas de changelog, tutoriales y blog posts
Esto no es una aspiracion teorica. Es la realidad operativa diaria. PostHog publica su handbook publicamente, y puedes leer las expectativas palabra por palabra.
Por que eliminaron el rol de PM
James Hawkins, CEO de PostHog, ha escrito extensamente sobre esta decision. El razonamiento central se reduce a tres creencias:
Creencia 1: La perdida de contexto mata la velocidad. Cada handoff entre un PM y un ingeniero degrada la calidad de la informacion. El PM habla con el usuario, interpreta su dolor, lo escribe y entrega una version filtrada al ingeniero. Para cuando se escribe codigo, el contexto original se fue. Cuando el ingeniero habla con usuarios directamente, esa compresion nunca sucede.
Creencia 2: Los ingenieros que entienden a los usuarios construyen mejores productos. Un PM podria escribir un spec diciendo "los usuarios quieren tiempos de carga mas rapidos." Un ingeniero que miro a un usuario ver un spinner por 8 segundos entiende algo mas profundo que lo que cualquier ticket puede transmitir. El peso emocional de la observacion directa cambia como construyes.
Creencia 3: Los equipos pequenos se mueven mas rapido sin overhead de coordinacion. Los PMs pasan enormes cantidades de tiempo coordinando entre diseno, ingenieria, liderazgo, ventas y soporte. Remueve al PM, dale a los ingenieros acceso directo a todos esos canales, y eliminas reuniones que existen puramente como mecanismos de transmision de informacion.
Los datos internos de PostHog respaldan esto. Segun sus metricas publicadas, lanzaron mas de 200 mejoras de producto en un solo trimestre con un equipo de aproximadamente 45 personas. Eso es aproximadamente una mejora lanzada por persona por semana, lo cual es un ritmo extraordinario para un producto B2B SaaS.
Como PostHog contrata product engineers
El perfil que buscan
Las descripciones de puesto de PostHog son refrescantemente especificas sobre lo que quieren. Basado en sus ofertas publicas y handbook, el candidato ideal:
- Tiene 5+ anos de experiencia en software engineering
- Ha lanzado productos de los que usuarios reales dependieron
- Puede articular opiniones sobre que construir, no solo como construirlo
- Escribe bien (porque gran parte del rol involucra comunicacion escrita)
- Se siente comodo hablando con clientes sin un PM como intermediario
- Tiene opiniones fuertes sobre calidad de producto y experiencia de usuario
- Prefiere lanzar rapido sobre planificar extensamente
Nota lo que esta ausente de esta lista. No hay mencion de requisitos especificos de tech stack (aunque corren principalmente en Python, TypeScript, React, ClickHouse y Django). No hay enfasis en diseno de sistemas a hiperescala. La senal para la que optimizan es sentido de producto combinado con velocidad de lanzamiento.
El proceso de entrevista
PostHog publica su proceso de entrevista abiertamente. Tipicamente sigue esta estructura:
| Etapa | Formato | Duracion | Enfoque |
|---|---|---|---|
| Revision de aplicacion | Asincrono | N/A | Resume, portafolio, respuestas escritas |
| Screen de cultura | Videollamada | 30 min | Alineacion de valores, estilo de comunicacion |
| Entrevista tecnica | Videollamada | 60 min | Capacidad de codificacion, descomposicion de problemas |
| Entrevista de producto | Videollamada | 45 min | Pensamiento de producto, priorizacion, empatia con el usuario |
| SuperDay | Dia de prueba pagado | Dia completo | Trabajo real en un problema real |
El SuperDay es el elemento mas distintivo. En lugar de un desafio de codificacion artificial, pagan a los candidatos para trabajar en un problema real por un dia completo. Obtienes acceso al codebase, un issue real para resolver, y la expectativa de lanzar algo (o hacer progreso significativo). Pagan a los candidatos por este tiempo, lo cual es tanto etico como revelador. Si puedes entregar valor real en un dia con guia minima, probablemente perteneces a este rol.
Este enfoque filtra fuertemente por autonomia. Si necesitas direccion extensa, specs detallados, o acompanamiento en decisiones de arquitectura, el SuperDay lo expondra inmediatamente. Tambien es un filtro por velocidad de lanzamiento. Un dia no es suficiente tiempo para planificacion extensa. Tienes que tomar decisiones rapido y moverte.
Que descalifica candidatos
Basado en patrones de personas que han compartido sus experiencias de entrevista con PostHog publicamente, las senales comunes de rechazo incluyen:
- Hacer demasiadas preguntas de clarificacion antes de intentar una solucion (sugiriendo dependencia de specs)
- Proponer arquitecturas excesivamente complejas cuando un enfoque mas simple funcionaria
- Enfocarse en edge cases antes de resolver el problema core
- No demostrar curiosidad sobre usuarios o impacto en el negocio
- Escribir codigo que funciona pero es dificil para otros de entender
El patron subyacente: rechazan personas que optimizan por correccion sobre velocidad, o que construyen para ingenieros en lugar de para usuarios. Si quieres prepararte para una entrevista en PostHog, estudia los patrones que cubrimos en nuestra guia de entrevista de product engineer.
Cuanto paga PostHog a product engineers
Filosofia de compensacion
PostHog usa un calculador de compensacion transparente. Es una de las pocas empresas que publica su formula salarial publicamente. La formula tiene en cuenta:
- Nivel del rol (IC5, IC6, etc.)
- Ubicacion (ajustada por un factor de ubicacion basado en costo de mano de obra)
- Step dentro del nivel (progresion de experiencia dentro de un nivel dado)
Segun su calculador publico (a principios de 2026) y cruzado con datos de Levels.fyi, la compensacion en PostHog cae en estos rangos:
| Nivel | Comp total basada en EE.UU. | Ajuste SF/NYC |
|---|---|---|
| Mid-level (IC3) | $160K - $195K | +15% factor de ubicacion |
| Senior (IC4-5) | $200K - $270K | +15% factor de ubicacion |
| Staff/Lead (IC6) | $260K - $320K | +15% factor de ubicacion |
Estos numeros incluyen salario base mas equity. PostHog otorga equity como opciones con vesting de 4 anos y cliff de 1 ano. Para una empresa en su etapa de valoracion, el upside de equity es real pero especulativo.
Comparado con empresas FAANG, la compensacion en efectivo de PostHog es menor. Un senior engineer en Google o Meta podria ganar $350K-$500K en comp total. Pero la comparacion es enganosa. PostHog ofrece algo que esas empresas no pueden: autonomia radical, impacto directo al cliente, y la ausencia de burocracia organizacional. Para un analisis mas profundo de tasas de mercado, consulta nuestro desglose de salarios.
Ajustes de pago basados en ubicacion
PostHog es completamente remoto y ajusta la compensacion basada en ubicacion. Sus bandas publicadas muestran multiplicadores de ubicacion que van de 0.55x (regiones con menor costo de mano de obra) a 1.15x (San Francisco, Nueva York). Esta es una practica comun entre empresas remote-first, aunque sigue siendo controversial.
La implicacion practica: un senior engineer en Lisboa gana aproximadamente 70% de lo que el mismo rol paga en San Francisco. Si eso es justo depende de tu filosofia sobre pagar por mano de obra versus pagar por output. PostHog argumenta que los ajustes de ubicacion les ayudan a contratar globalmente mientras se mantienen competitivos en cada mercado local.
Un dia en la vida de un product engineer en PostHog
¿Como se ve la realidad diaria? Basado en blog posts publicos de empleados, apariciones en podcasts y documentacion del handbook, aqui hay un dia representativo:
Manana (trabajo asincrono):
- Revisar datos de uso de PostHog para tu area de producto (literalmente usando el producto que construyes)
- Leer y responder a feedback de usuarios en la comunidad de Slack
- Revisar PRs abiertos de companeros de equipo
- Lanzar una mejora pequena que ha estado en progreso
Mediodia (construccion enfocada):
- Trabajar en el proyecto principal del sprint (ciclos de 2 semanas)
- Tomar decisiones de diseno sobre la marcha, consultando al disenador del equipo cuando sea necesario
- Pushear codigo a produccion (PostHog deploya multiples veces al dia)
Tarde (comunicacion y planificacion):
- Escribir una actualizacion breve en el canal del equipo sobre lo que se lanzo
- Participar en un standup de 30 minutos (la unica reunion recurrente que la mayoria de equipos tiene)
- Grabar un Loom corto para un feature que lanzaste, para el changelog
- Leer tickets de soporte al cliente para identificar patrones
Lo que es notablemente ausente: no hay sprint planning que tome dos horas, no hay sesiones de backlog grooming, no hay syncs con PM, no hay comites de revision de diseno, no hay boards de revision de arquitectura. La carga de reuniones es minima para estandares de la industria. La mayoria de los ingenieros de PostHog reportan pasar menos de 4 horas por semana en reuniones.
El modelo PostHog comparado con otras culturas de product engineering
PostHog no esta solo en adoptar este enfoque, pero su implementacion es de las mas extremas. Aqui esta como se comparan:
| Dimension | PostHog | Linear | Vercel | Stripe |
|---|---|---|---|---|
| Product managers | Ninguno | Ninguno (founders cumplen rol similar a PM) | Pocos, mayormente senior | Si, pero ingenieros son duenos de metricas |
| Tamano de equipo | 2-6 | 2-4 | 3-8 | 5-12 |
| Acceso de ingenieros a clientes | Directo, diario | Directo, frecuente | Varia por equipo | Limitado, mayormente a traves de PMs |
| Frecuencia de deploy | Multiples veces/dia | Multiples veces/dia | Continuo | Multiples veces/dia |
| Responsabilidad de escribir specs | Ingenieros | Ingenieros + founders | Mixto | PMs escriben alto nivel, ingenieros son duenos de detalles |
| Handbook publico | Si | Parcial | No | No |
| Transparencia de compensacion | Formula publica completa | Solo interna | Solo interna | Solo interna |
Linear se acerca mas al modelo de PostHog pero mantiene una direccion de producto mas fuerte por parte de los founders. Vercel da a los ingenieros ownership significativo pero retiene PMs para iniciativas estrategicas mas grandes. Stripe emplea PMs pero tiene una cultura fuerte de pensamiento de producto impulsado por ingenieros.
Desde mi perspectiva: que hace bien y que hace mal PostHog
Habiendo contratado a mas de 600 ingenieros en dos startups y AWS, y entrenado a mas de 12,000 ingenieros en crecimiento de carrera, he visto cada variante de organizacion de ingenieria. El modelo de PostHog es impresionante pero no universalmente aplicable.
Lo que hacen bien: eliminar la brecha de contexto entre usuarios y constructores produce productos genuinamente mejores. Cada vez que he visto a un ingeniero sentarse con un usuario real por 30 minutos, su siguiente PR fue fundamentalmente diferente de lo que habria sido leyendo un ticket. PostHog sistematiza esa exposicion. Tambien atraen talento extraordinario porque su modelo atrae al tipo de ingeniero senior que dejo una empresa grande precisamente porque estaba cansado de construir specs que alguien mas escribio.
Lo que es mas dificil de replicar: este modelo requiere una barra de contratacion excepcionalmente alta. No todo ingeniero quiere (o puede) hacer trabajo de producto. No todo ingeniero es lo suficientemente articulado para escribir contenido orientado al cliente o lo suficientemente seguro para ejecutar entrevistas con usuarios. PostHog puede mantener esto porque son selectivos, bien financiados, y construyen un producto para desarrolladores (con quienes es mas facil para los ingenieros empatizar). Una empresa construyendo software de seguros para ajustadores de reclamos enfrentaria un desafio completamente diferente. La brecha de expertise de dominio entre constructor y usuario es mucho mas amplia.
¿Deberias aplicar a PostHog como product engineer?
Prosperarias ahi si:
- Tienes opiniones sobre que construir, no solo como
- Encuentras que hablar con usuarios es energizante en lugar de agotador
- Prefieres lanzar cosas imperfectas rapido sobre lanzar cosas perfectas lentamente
- Escribes bien y disfrutas la comunicacion publica
- Te sientes comodo tomando decisiones sin aprobacion de arriba
- Quieres que tu impacto se mida en resultados de usuario, no en story points
Tendrias dificultades ahi si:
- Prefieres desafios tecnicos profundos sobre amplitud de producto
- No te gusta cambiar contexto entre codificar, escribir e investigacion de usuarios
- Necesitas specs claros antes de empezar a construir
- Encuentras las conversaciones con clientes incomodas o improductivas
- Valoras estabilidad y proceso sobre velocidad y ambiguedad
- Defines seniority solo por profundidad tecnica
Si el modelo de PostHog te emociona pero no estas seguro de que estas listo, lee nuestra guia sobre como convertirse en product engineer. La transicion de software engineering tradicional a product engineering es aprendible, pero requiere practica deliberada en areas que la mayoria de los ingenieros nunca desarrollan. Tambien puedes explorar ofertas actuales en nuestro resumen de empleos de product engineer para ver como las ofertas de PostHog se comparan con otras en el mercado.
Las implicaciones mas amplias para la industria
El exito de PostHog sin PMs no es un argumento de que todas las empresas deberian despedir a sus product managers. Es evidencia de que una estructura organizacional especifica, construida alrededor del ownership de producto liderado por ingenieros, puede producir resultados excepcionales cuando las condiciones son correctas.
Esas condiciones incluyen: un producto enfocado en desarrolladores, una empresa completamente remota con normas fuertes de comunicacion escrita, una barra de contratacion alta con un dia de prueba pagado, equipos pequenos con limites claros de ownership, transparencia radical (handbook publico, compensacion publica, roadmap publico), y liderazgo que genuinamente cree que los ingenieros deberian ser duenos de los resultados de producto.
Si tres o cuatro de esas condiciones faltan, el modelo colapsa. Terminas con ingenieros que no hablan con usuarios, construyen lo que sea tecnicamente interesante, y nunca miden resultados. Eso no es product engineering. Es ingenieria sin responsabilidad.
Para mas sobre las diferencias entre estos enfoques, consulta nuestro desglose de product engineer vs software engineer.
Puntos clave
- PostHog elimino product managers por completo y da a cada ingeniero ownership completo desde descubrimiento del problema hasta feature lanzado.
- Su contratacion prioriza pensamiento de producto sobre expertise tecnologico especifico; ensenan el stack, no el instinto.
- Los ingenieros miran grabaciones de sesiones de usuarios reales dentro de horas de lanzar y escriben ship reviews publicas con datos.
- El modelo PostHog prueba que equipos pequenos y autonomos de product engineers pueden superar en lanzamientos a organizaciones mucho mas grandes.
FAQ
¿Que tech stack usa PostHog para product engineers?
El stack principal de PostHog incluye Python (Django) para el backend, TypeScript y React para el frontend, ClickHouse para datos de analytics, PostgreSQL para datos de aplicacion, y Redis para caching. Deployean en AWS usando Kubernetes. Sin embargo, su proceso de contratacion enfatiza pensamiento de producto sobre expertise tecnologico especifico. Han declarado publicamente que preferirian contratar a un gran pensador de producto que necesite aprender ClickHouse que a un experto en ClickHouse que no pueda tomar decisiones de producto.
¿Necesitas experiencia en product management para ser product engineer en PostHog?
No se requiere experiencia formal de PM. Lo que PostHog busca es evidencia de que has tomado decisiones de producto en el pasado, ya sea en un trabajo anterior, un proyecto personal, o una contribucion open-source. Demostrar que puedes priorizar basado en valor para el usuario en lugar de elegancia tecnica importa mas que cualquier certificacion de PM o titulo previo de PM.
¿Como se compara el salario de product engineer en PostHog con FAANG?
La compensacion en efectivo base en PostHog es tipicamente 60-80% de lo que pagan las empresas FAANG para seniority equivalente. Sin embargo, PostHog ofrece equity significativo en una empresa de alto crecimiento, autonomia radical, carga minima de reuniones, y el tipo de impacto directo que las empresas grandes no pueden proveer. Muchos ingenieros que se unen a PostHog explicitamente intercambian efectivo por ownership y agencia. Si ese tradeoff tiene sentido depende de tu situacion financiera y metas de carrera.
¿Puede funcionar el modelo sin PMs de PostHog en empresas mas grandes?
Se vuelve significativamente mas dificil a medida que las empresas escalan mas alla de 100-150 ingenieros. PostHog puede mantener el modelo porque su producto se dirige a desarrolladores (reduciendo la brecha de empatia con el usuario), sus equipos se mantienen pequenos (2-6 personas), y su barra de contratacion es extremadamente alta. Empresas como Spotify intentaron modelos similares y eventualmente reintrodujeron PMs a escala. El punto dulce para este modelo puro parece ser empresas con menos de 200 ingenieros construyendo productos tecnicos.
¿Cual es el camino de carrera para un product engineer en PostHog?
PostHog ofrece un track IC (individual contributor) que progresa de mid-level a traves de senior hasta staff y principal. No hay requisito de moverse a management. Los ICs mas senior en PostHog influyen en la estrategia de producto a nivel empresa mientras todavia escriben codigo diariamente. Algunos team leads tienen responsabilidades de management, pero estas son ligeras comparadas con roles tradicionales de engineering management. PostHog explicitamente valora contribucion IC sobre influencia organizacional.