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. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
RICE, ICE o el weighted scoring todos convierten opinión en números que puedes comparar. Donde se rompen es que los inputs son estimaciones y el score hereda su error, así una suposición confiada sobre impact le gana a una cautelosa sin importar la verdad. El valor no es el ranking — es que el desacuerdo se vuelve visible, usualmente en impact, y se puede discutir en vez de pelear.
Ser una tarea disfrazada: 'como usuario quiero un dropdown' nombra una solución y esconde la necesidad. Una story usable dice quién, qué está tratando de lograr, y por qué, con criterios de aceptación que hacen inequívoco lo terminado. El otro fallo es una story demasiado grande para terminar en un sprint, que es cómo un tablero se llena de cosas casi completas por semanas.
Segmenta antes de teorizar: qué cohorte, qué plataforma, qué fuente de adquisición, y cuándo empezó. Una caída confinada a cohortes nuevas usualmente es onboarding o un cambio en el mix de tráfico; a través de todas las cohortes a la vez usualmente es el producto o un outage. Revisa qué se lanzó, y revisa si cambió el tracking — una rotura de analytics se ve exactamente como una caída de retention.
Qué cuesta adquirir a un cliente, qué paga y por cuánto tiempo, y qué cuesta atenderlo. De esos tres vienen el payback period y el ratio que decide si el crecimiento se financia a sí mismo o consume caja. El número que la gente se salta es el costo de atención, que para cualquier cosa con soporte o infraestructura no es pequeño.
Moviendo el argumento de preferencia a evidencia: qué resultado sirve cada pedido, qué vale, y qué cuesta. La escalación es una herramienta legítima cuando el desacuerdo es genuinamente sobre prioridades de la empresa en vez de sobre detalle de producto. Lo que no funciona es construir ambos, que es cómo un producto adquiere dos medias-features y ninguna posición.
No. Un test cuesta tráfico, tiempo y atención, y algunas preguntas se responden más barato mirando datos existentes o hablando con cinco usuarios. Testea cuando la decisión es cara de revertir, cuando el equipo genuinamente no está de acuerdo, y cuando la muestra hace posible un resultado — correr un test que no puede alcanzar significancia es peor que no correrlo, porque produce un número que la gente va a citar.
Los pocos números que te harían actuar: adquisición, activación, retention, ingresos, y la métrica específica de lo que hace el producto. No todo lo medible — un dashboard de cuarenta gráficos nadie lo lee y esconde los tres que importan. Cada métrica debería tener un dueño y una comparación, porque un número sin línea base no se puede interpretar.
En el tamaño de muestra y duración que fijaste antes de empezar. Espiar y detenerlo en el momento en que se ve significativo es cómo lanzas ruido — la tasa de falsos positivos sube mientras más a menudo miras. Corre al menos un ciclo semanal completo así el comportamiento de día de semana y fin de semana están ambos ahí, y decide de antemano qué resultado te haría no lanzarlo, porque un test que ignorarías no vale el tráfico.
En orden creciente de costo: habla con la gente sobre el problema sin mencionar tu solución, muestra un prototipo y observa dónde se detienen, pon una landing page y cuenta quién la pide, luego corre una versión concierge donde haces el trabajo manualmente. Cada una responde una pregunta distinta, y ninguna es 'usarías esto' — todos dicen que sí a eso, por eso la señal útil es lo que la gente ya hace o paga hoy.
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 Middle Product Manager →