El product sense no es un don. Es un músculo.
Probablemente has observado a alguien en una reunión decir "los usuarios no van a querer eso" y acertar cada vez. Esa persona no tiene una antena mágica. Han entrenado reconocimiento de patrones a través de miles de micro-observaciones. product.engineer define product sense para ingenieros como la capacidad de predecir qué funcionalidades moverán el comportamiento de los usuarios antes de escribir una línea de código. Es el instinto por lo que importa combinado con la disciplina de validar ese instinto con datos.
Aquí está la buena noticia: el product sense es completamente entrenable. No es un talento innato otorgado al nacer a personas que leyeron ensayos de Paul Graham en la universidad. Es una habilidad compuesta construida a partir de ejercicios específicos y repetibles. Un product engineer que desarrolla product sense fuerte se convierte en la persona más valiosa de cualquier equipo porque colapsa la brecha entre "¿qué deberíamos construir?" y "déjame construirlo". Entregan funcionalidades que permanecen en vez de funcionalidades que se pudren.
Únete a 2.000+ ingenieros que definen, construyen y entregan.
Un correo por semana. Frameworks prácticos para ingenieros de producto. Sin spam.
Estas no son mejoras abstractas. Se traducen directamente en capital de carrera, velocidad de promoción y el tipo de trabajo que realmente importa.
En este artículo, desglosare los ejercicios concretos, hábitos diarios y frameworks mentales que construyen product sense. Nada de teoría sin práctica. Cada sección incluye algo que puedes hacer esta semana.
Qué significa realmente el product sense para ingenieros
El framework de product.engineer para product sense lo divide en tres capas. La mayoría de la gente solo habla de una.
Capa 1: Intuición de usuario. ¿Puedes predecir cómo un usuario reaccionará a un cambio antes de verlo? Esta es la capa que la gente romantiza. La narrativa del "instinto de Steve Jobs". Pero en realidad es la capa más delgada.
Capa 2: Razonamiento sistémico. ¿Puedes rastrear efectos de segundo y tercer orden de una decisión de producto a través de un sistema complejo? Un ingeniero en Stripe no solo pregunta "¿a los comerciantes les gustará este flujo de checkout?" Preguntan "¿cómo interactúa esto con la detección de fraude, el timing de settlement y las tasas de disputa en 40 países?" Esta capa es donde los ingenieros tienen una ventaja natural sobre PMs no técnicos.
Capa 3: Predicción de resultados. ¿Puedes conectar una funcionalidad con una métrica de negocio y estimar la magnitud del impacto? No "esto probablemente ayudará a la retención" sino "esto mejorará la retención D7 en 2-4 puntos para nuestro segmento mid-market porque aborda la brecha de activación que vemos en el análisis de cohortes". Esa especificidad separa a los ingenieros que lideran de los que siguen.
Un product engineer que opera en las tres capas se convierte en la persona a la que el CEO llama cuando hay una decisión difícil. No llegas ahí leyendo libros. Llegas con práctica deliberada.
El hábito de observación diaria
El hábito individual de mayor impacto para construir product sense es la observación estructurada de producto. Quince minutos al día, todos los días. No scrolling pasivo. Análisis activo.
Aquí está el protocolo:
- Elige una interacción de producto que tuviste hoy. Pedir café en una app. Buscar un archivo en Notion. Aprobar un PR en GitHub. Cualquier cosa.
- Nombra el job-to-be-done. ¿Qué estabas intentando lograr? Sé específico. No "quería café" sino "quería volver a pedir mi bebida habitual sin pensar".
- Califica la fricción. En una escala del 1-5, ¿cuánto esfuerzo innecesario te impuso el producto?
- Identifica una elección de diseño. ¿Qué decisión específica tomó el equipo de producto que creó o redujo esa fricción?
- Hipotetiza el tradeoff. ¿Por qué podrían haber tomado esa decisión? ¿Para qué estaban optimizando en vez de tu conveniencia?
Escríbelo. Una página de Notion, Apple Notes, un cuaderno de papel. El medio no importa. La consistencia sí.
Después de 30 días, empezarás a notar patrones entre productos. Después de 90 días, empezarás a predecir decisiones de diseño antes de encontrarlas. Después de 180 días, la gente empezará a llamarte "product-minded" y se preguntará de dónde vino.
El equipo de Linear ha hablado públicamente sobre cómo sus ingenieros mantienen un registro continuo de "irritaciones de producto" que encuentran en otras herramientas. Esas observaciones alimentan directamente su roadmap de producto. Esto no es una coincidencia. Es un sistema.
Cinco ejercicios que construyen product sense rápido
Ejercicio 1: El teardown inverso
Elige una funcionalidad de un producto que usas diariamente. No mires cómo funciona. En cambio, trabaja hacia atrás.
- ¿Qué métrica existe para mover esta funcionalidad?
- ¿A qué segmento de usuarios sirve?
- ¿Qué probablemente era cierto en sus datos que hizo de esto la prioridad?
- ¿A qué probablemente dijeron no para poder entregar esto?
Practica esto con los lanzamientos recientes de funcionalidades de Vercel. Su funcionalidad de preview deployments existe para reducir el tiempo entre "código pusheado" y "feedback de stakeholder recibido". La métrica probablemente es time-to-first-review. El segmento son equipos de frontend con stakeholders no técnicos. Probablemente dijeron no a hacerlo funcionar con soluciones de Git auto-hospedadas al principio porque la superficie de integración era demasiado grande.
Estarás equivocado a veces. Eso está bien. El ejercicio construye el músculo de razonamiento, no el músculo de corrección. La corrección viene con la repetición.
Ejercicio 2: El test de cinco usuarios
Habla con cinco usuarios de algo que construiste. No una entrevista formal. Cinco conversaciones casuales. Haz tres preguntas:
- ¿Qué estabas haciendo justo antes de usar esta funcionalidad?
- ¿Qué hiciste justo después?
- Si esto desapareciera mañana, ¿qué harías en su lugar?
La primera pregunta revela contexto. La segunda revela si realmente resolviste el problema o solo lo moviste. La tercera revela tu verdadera competencia, que casi nunca es quien piensas.
PostHog documenta esta práctica extensamente. Sus ingenieros hacen entrevistas con usuarios como parte del flujo normal de ingeniería. No como un evento especial. No delegado a investigadores. Los ingenieros hablan con usuarios directamente porque la calidad de la señal se degrada a través de intermediarios. Sus criterios de contratación de product engineers explícitamente prueban esta capacidad.
Ejercicio 3: El juego de predicción de métricas
Antes de mirar cualquier dashboard, escribe tu predicción. Cada lunes por la mañana, antes de verificar analytics:
- Predice la tasa de registro de esta semana (mayor, menor, igual que la semana pasada)
- Predice qué funcionalidad tuvo mayor engagement
- Predice la dirección del movimiento del NPS de tu producto
Rastrea tu precisión con el tiempo. Los ingenieros que practican predicción de métricas consistentemente mejoran su precisión de estimación y toman decisiones de priorización significativamente mejores.
Este ejercicio entrena calibración. La mayoría de los ingenieros tienen terrible calibración sobre comportamiento de usuarios porque nunca practican predecirlo. Solo reaccionan a los datos después del hecho. Predicción antes de observación es el camino más rápido a la intuición.
Ejercicio 4: El análisis "¿Qué se rompería?"
Cuando un competidor lanza algo nuevo, no preguntes "¿deberíamos copiar esto?" Pregunta: "¿Qué se rompería en nuestro producto si nuestros usuarios empezaran a esperar esto?"
Cuando OpenAI lanzó memoria en ChatGPT, la pregunta correcta para cualquier producto adyacente a IA no era "¿deberíamos agregar memoria?" Era "¿qué conversaciones están teniendo nuestros usuarios donde la falta de memoria crea fricción, y qué pasa con nuestras métricas de retención si experimentan memoria en otro lado y luego regresan a nosotros?"
Este ejercicio desarrolla la capa de predicción de resultados. Te fuerza a pensar a través de efectos en cascada en vez de paridad de funcionalidades a nivel superficial.
Ejercicio 5: El diario de hipótesis semanal
Cada viernes, escribe una hipótesis sobre tus usuarios. Formátela como:
"Creo que [segmento de usuarios] tiene dificultades con [problema específico] porque [causa raíz], y si nosotros [intervención], veremos que [métrica] cambia en [magnitud estimada] dentro de [periodo de tiempo]."
Un ejemplo real: "Creo que las cuentas mid-market en sus primeros 30 días tienen dificultades con la creación de dashboards porque nuestra biblioteca de plantillas asume familiaridad con nuestro modelo de datos, y si agregamos plantillas guiadas con datos de ejemplo pre-llenados, veremos que la tasa de activación mejora en 8-12 puntos dentro de 6 semanas."
Luego encuentra una pieza de evidencia esta semana para soportar o refutar la hipótesis de la semana pasada. Con el tiempo, construyes un portafolio de creencias probadas sobre tus usuarios que hace las decisiones de producto casi automáticas.
Leyendo comportamiento de usuarios: la ventaja del ingeniero
Los ingenieros tienen un superpoder que la mayoría de los PMs no tienen: puedes leer la base de datos. Puedes escribir queries. Puedes instrumentar comportamiento de formas que ninguna encuesta o entrevista jamás revela.
Aquí hay un framework para leer comportamiento de usuarios sistemáticamente:
| Tipo de señal | Qué buscar | Ejemplo de herramienta |
|---|---|---|
| Frecuencia | ¿Con qué frecuencia los usuarios disparan esta acción? | SQL contra tablas de eventos |
| Secuencia | ¿Qué hacen los usuarios antes y después de esta acción? | Análisis de funnel en PostHog o Amplitude |
| Abandono | ¿Dónde los usuarios empiezan algo y no lo terminan? | Grabaciones de sesión, análisis de drop-off |
| Workarounds | ¿Los usuarios están haciendo algo raro para lograr un objetivo? | Tickets de soporte, menciones en Slack |
| Silencio | ¿Qué funcionalidades existen que nadie usa? | Dashboards de adopción de funcionalidades |
La señal más subestimada son los workarounds. Cuando un usuario de Figma crea una estructura de frames específica repetidamente para simular una funcionalidad que no existe, ese workaround es una señal de producto que vale millones. Cuando un usuario de Notion mantiene una vista de base de datos compleja para rastrear algo que el producto debería manejar nativamente, eso es demanda expresada a través de fricción.
Para leer comportamiento bien, necesitas entender qué métricas importan y cómo se conectan con la intención del usuario. Las métricas de vanidad (page views, registros totales) no te dicen casi nada. Los indicadores adelantados (tasa de activación, time-to-value, velocidad de adopción de funcionalidades) te dicen todo.
Formando hipótesis: el método científico, pero más rápido
Una hipótesis no es una suposición. Es una predicción estructurada con criterios falsificables. Los ingenieros entienden esto intuitivamente al escribir tests. Una buena hipótesis de producto funciona exactamente como una buena aserción de test: establece qué esperas, bajo qué condiciones, y cómo sabrás si estás equivocado.
El framework que uso:
Paso 1: Observa una anomalía. Algo en tus datos no coincide con tu modelo mental. La retención cayó para un segmento. Una funcionalidad tiene adopción pero no engagement. Los registros aumentaron pero la activación no.
Paso 2: Genera tres posibles explicaciones. No una. Tres. La primera explicación que tu cerebro produce usualmente está equivocada porque es la más cognitivamente disponible, no la más probable. Fórzate a generar alternativas.
Paso 3: Diseña la prueba discriminante más económica. ¿Cuál es lo mínimo que puedes hacer que te diría cuál de tus tres explicaciones es correcta? A veces es un query SQL. A veces son cinco conversaciones con usuarios. A veces es un prototipo de 2 días.
Paso 4: Establece un criterio de eliminación. Antes de comenzar, decide qué resultado te haría abandonar esta dirección completamente. Si no puedes nombrar tu criterio de eliminación, tu hipótesis no es lo suficientemente específica.
El equipo de crecimiento de Shopify reporta operar con un modelo similar de "triple hipótesis". Generan múltiples explicaciones competidoras para cada anomalía de comportamiento antes de invertir en soluciones. Esto previene el modo de fallo más común en desarrollo de producto: enamorarse de tu primera explicación y construir una solución al problema equivocado.
El framework de comparación: niveles de madurez de product sense
Aquí está cómo auto-evaluarte dónde estás y qué trabajar siguiente:
| Nivel | Comportamiento | Área de enfoque |
|---|---|---|
| Nivel 1: Reactivo | Construyes lo que te piden. Notas problemas de producto solo cuando los usuarios se quejan. | Comienza el hábito de observación diaria. |
| Nivel 2: Observador | Notas fricción en productos que usas. Puedes articular por qué algo se siente mal. | Comienza teardowns inversos y el test de cinco usuarios. |
| Nivel 3: Predictivo | Anticipas reacciones de usuarios antes del lanzamiento. Tus predicciones son correctas más de la mitad del tiempo. | Practica juegos de predicción de métricas y diario de hipótesis. |
| Nivel 4: Generativo | Identificas oportunidades que nadie más ve. Propones funcionalidades con objetivos claros de métricas. | Enfócate en efectos de segundo orden y transferencia de patrones entre dominios. |
| Nivel 5: Estratégico | Das forma a la dirección de producto. Conectas decisiones de funcionalidades con modelo de negocio y posicionamiento de mercado. | Estudia profundamente mecánicas de modelo de negocio y dinámicas competitivas. |
La mayoría de los ingenieros empiezan en Nivel 1 o 2. Llegar al Nivel 3 toma aproximadamente seis meses de práctica deliberada. El Nivel 4 típicamente requiere 1-2 años más exposición a contextos diversos de producto. El Nivel 5 es donde los product engineers se vuelven indistinguibles de grandes fundadores.
La conexión con investigación de usuarios
El product sense sin investigación de usuarios es solo opinión con confianza. Los ejercicios anteriores construyen tu intuición, pero la investigación directa de usuarios la valida y la agudiza. Los mejores product engineers desarrollan una cadencia: forman hipótesis a través de observación, validan a través de investigación, calibran a través de métricas.
No necesitas convertirte en investigador a tiempo completo. Necesitas tres conversaciones por semana con usuarios reales. Eso es lograble para cualquier ingeniero que decide que importa. Bloquea 30 minutos los martes y jueves. Contacta usuarios que recientemente se registraron, recientemente abandonaron, o recientemente adoptaron una nueva funcionalidad. Haz preguntas abiertas. Escucha más de lo que hablas.
La combinación de lectura cuantitativa de señales y conversaciones cualitativas con usuarios crea un loop de feedback que acelera dramáticamente el desarrollo de product sense. Ninguna sola es suficiente. Datos sin historias son engañosos. Historias sin datos son anecdóticas. Juntos, producen juicio.
Mi experiencia construyendo este músculo
Habiendo hecho coaching a más de 12,000 ingenieros y contratado a más de 600, puedo decirte que el patrón es notablemente consistente. Los ingenieros que desarrollan product sense fuerte no son los que tienen los IQs más altos o los títulos más prestigiosos. Son los que tratan la intuición de producto como una habilidad a entrenar en vez de un rasgo que tienes o no tienes.
En AWS, observé a ingenieros senior transformar su impacto adoptando estos hábitos. Un ingeniero con el que trabajé pasó de ser un contribuidor técnico sólido a liderar una iniciativa de producto que generó $40M en ingresos incrementales. Las habilidades técnicas no cambiaron. Lo que cambió fue la capacidad de leer comportamiento de usuarios en los datos, formar hipótesis sobre qué construir, y validar esas hipótesis rápidamente. Eso es product sense en acción. Como fundador 2x, experimenté esto de primera mano. En mi primera empresa, construí funcionalidades que pensé que eran inteligentes. La mayoría fallaron. En mi segunda empresa, construí funcionalidades que los datos de comportamiento de usuarios demandaban. La tasa de éxito se triplicó. La diferencia no fue talento. Fue proceso.
Errores comunes con el product sense para ingenieros
Error 1: Tratar el product sense como "convertirse en PM". El product sense para ingenieros no se trata de escribir PRDs o ejecutar ceremonias de sprint. Se trata de tomar mejores decisiones sobre qué código escribir y, críticamente, qué código no escribir.
Error 2: Sobre-indexar en analytics sin hablar con humanos. Los datos te dicen qué está pasando. Los usuarios te dicen por qué. Necesitas ambos. Un ingeniero que solo mira dashboards construirá funcionalidades que optimizan métricas sin realmente resolver problemas.
Error 3: Confundir preferencia personal con comportamiento de usuario. No eres tu usuario. Eres un power user de tu propio producto con contexto profundo que ninguna persona normal tiene. Cada vez que dices "yo querría esta funcionalidad", verifica esa suposición contra datos reales de uso. La investigación interna de Spotify reporta que las preferencias personales de funcionalidades de sus ingenieros correlacionaron con la demanda real de usuarios solo el 23% de las veces.
Error 4: Esperar permiso. No necesitas que un PM te diga que desarrolles product sense. No necesitas un cambio de título. Puedes empezar hoy con el hábito de observación diaria y nadie necesita aprobarlo.
Error 5: Rendirse después de 30 días. El product sense se acumula lentamente y luego rápidamente. El primer mes se siente como que nada está cambiando. Para el mes tres, empiezas a hacer conexiones que otros no ven. Para el mes seis, la gente lo nota. Sigue adelante a través de la meseta.
Construyendo tu stack de product sense
Para convertirte en un verdadero product engineer, necesitas combinar múltiples inputs en una imagen coherente. Aquí está el stack que recomiendo:
Inputs semanales:
- 3 conversaciones con usuarios (15 minutos cada una)
- 5 entradas de observación diaria
- 1 teardown inverso
- 1 entrada en diario de hipótesis
- 30 minutos leyendo los analytics de tu producto
Inputs mensuales:
- 1 teardown competitivo profundo
- 1 análisis de una funcionalidad fallida (tuya o de alguien más)
- 1 revisión de tu precisión de predicción
Inputs trimestrales:
- 1 revisión completa del modelo de métricas (¿estás rastreando lo correcto?)
- 1 conversación con tu segmento de mayor churn
- 1 presentación a tu equipo de tus 3 hipótesis principales de producto
Este stack toma aproximadamente 3-4 horas por semana. Eso es menos tiempo que el que la mayoría de los ingenieros pasan en reuniones que no producen nada. El ROI es asimétrico: una inversión pequeña y consistente produce resultados desproporcionados porque muy pocos ingenieros lo hacen.
El contexto organizacional
El product sense no se desarrolla en un vacío. Tu ambiente acelera o retarda su crecimiento. Busca:
- Equipos que entregan semanalmente. Loops de feedback rápidos entrenan la intuición de producto más rápido que los lentos. Si solo entregas trimestralmente, solo obtienes cuatro puntos de calibración por año.
- Acceso a datos de usuarios. Si tu organización aísla a los ingenieros de los analytics, presiona para cambiar eso. O cambia de organización.
- Proximidad a clientes. Los ingenieros de Figma asisten a llamadas con clientes. Los ingenieros de Notion leen tickets de soporte. Si estás tres capas removido de los usuarios, tu product sense se desarrollará lentamente sin importar cuántos ejercicios hagas.
- Tolerancia a la experimentación. Necesitas permiso para equivocarte. El product sense requiere formar hipótesis que a veces fallan. Las organizaciones que castigan los experimentos fallidos suprimen el mismo comportamiento que construye juicio de producto.
Conclusiones clave
- El product sense es completamente aprendible a través de práctica deliberada, no un talento innato con el que algunas personas nacen.
- Seis meses de observación diaria consistente y prueba de hipótesis supera años de experiencia pasiva.
- Construyes product sense más rápido con proximidad a clientes y tolerancia a la experimentación donde las hipótesis pueden fallar.
- La práctica central: forma una predicción sobre comportamiento de usuario, observa qué realmente pasa, actualiza tu modelo mental.
- Las organizaciones que castigan los experimentos fallidos suprimen el mismo comportamiento que construye juicio de producto.
FAQ
¿Se puede aprender el product sense, o es innato?
El product sense es completamente aprendible. Como cualquier habilidad, algunas personas tienen ligeras ventajas naturales (alta empatía, fuerte reconocimiento de patrones), pero la brecha entre "sin product sense" y "product sense fuerte" se cierra a través de práctica deliberada, no genética. Seis meses de observación diaria consistente y prueba de hipótesis superarán años de experiencia pasiva.
¿Cuánto tiempo toma desarrollar product sense para ingenieros?
La mayoría de los ingenieros ven mejora notable dentro de 90 días de práctica deliberada. Mejora significativa de calibración (predecir comportamiento de usuario y movimientos de métricas con precisión) típicamente toma 6-12 meses. Alcanzar el punto donde el product sense se siente automático en vez de esforzado usualmente toma 18-24 meses de práctica consistente.
¿Cuál es la diferencia entre product sense y product management?
El product sense es una habilidad cognitiva. Product management es un rol. Product sense significa que puedes predecir comportamiento de usuario, identificar oportunidades de alto impacto y estimar el efecto de decisiones de producto. Product management involucra priorización de roadmap, alineación de stakeholders y coordinación cross-funcional. Un ingeniero con product sense toma mejores decisiones sobre qué construir sin necesariamente hacer el trabajo de coordinación de un PM.
¿Necesitas product sense para ser product engineer?
El product sense es el diferenciador central que separa a los ingenieros que dan forma a productos de los que solo los implementan. Sin él, estás construyendo lo que otros deciden. Con él, estás eligiendo qué funcionalidades implementar y prediciendo su impacto. Dicho esto, puedes comenzar a trabajar en este rol mientras activamente desarrollas tu product sense. No necesitas ser perfecto antes de empezar.
¿Cómo demuestro product sense en entrevistas?
La mejor forma de demostrar product sense en una entrevista de product engineer es recorrer un ejemplo real donde identificaste una oportunidad a través de datos u observación de usuarios, formaste una hipótesis, construiste algo para probarla, y mediste el resultado. Los entrevistadores en empresas como Linear, PostHog y Vercel específicamente buscan este arco narrativo. Prepara dos o tres historias que muestren el loop completo desde observación hasta resultado entregado.