Las entrevistas de product manager sondean el pensamiento de producto, la comodidad con métricas, y cómo decides qué no construir. Aquí están las preguntas más comunes con respuestas modelo. Junior: teoría básica, definiciones y casos prácticos simples.
Un proyecto tiene un final definido — un alcance, una fecha, y un momento en que se entrega. Un producto continúa, y su éxito se mide después de la entrega por si la gente lo sigue usando. La consecuencia son preguntas distintas: un proyecto pregunta si se lanzó a tiempo, un producto pregunta si lanzarlo cambió algo.
El product manager decide qué debería construirse y por qué; el project manager se asegura de que el trabajo acordado se entregue. Uno es dueño del resultado, el otro es dueño del plan. En equipos pequeños la misma persona hace ambos, lo cual está bien hasta que los dos objetivos entran en conflicto — y lo hacen, cada vez que un deadline se topa con un hallazgo de discovery.
Es una declaración de intención sobre problemas y su orden, útil porque deja que todos los demás planeen alrededor de él. No es un compromiso con fechas y features a un año — un roadmap tratado como un contrato convierte al discovery en teatro, porque nada que se encuentre puede cambiar algo. La versión honesta tiene menos certeza mientras más lejos va.
Lo más pequeño que testea si la suposición se sostiene. Se confunde con una versión barata del producto completo, por eso los equipos lanzan algo incompleto, no aprenden nada, y dañan la marca en el proceso. La pregunta que lo mantiene honesto es qué harías diferente dependiendo del resultado — si la respuesta es nada, no vale la pena construirlo.
ARPU es el ingreso promedio por usuario en un período; LTV es el ingreso total esperado de un cliente durante toda su relación, menos lo que cuesta atenderlo. ARPU puede verse saludable mientras LTV está cayendo, porque ARPU no dice nada sobre cuánto tiempo se queda la gente. LTV es el número que decide cuánto puedes gastar en adquirir a alguien.
Decidiendo antes del lanzamiento qué contaría, luego revisando adopción, retención de esa adopción, y la métrica de resultado que debía mover. Una feature puede usarse ampliamente y aun así ser un fracaso si canibaliza un mejor flujo o eleva el volumen de soporte. Elegir la métrica después de ver los datos es cómo todo parece un éxito.
Es el trabajo de averiguar si el problema es real, si la solución lo aborda, y si vale la pena hacerlo — a través de entrevistas, prototipos, datos. Viene primero porque construir es la forma más cara de aprender, y porque un equipo que se lo saltó va a descubrir las mismas cosas después del release, habiéndolas pagado.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Junior Product Manager →