Preguntas de entrevista Product Manager

Uso una combinación de frameworks según el contexto. Para productos en etapa temprana suelo apoyarme en RICE (Alcance, Impacto, Confianza, Esfuerzo) para crear un sistema de puntuación compartido. Para productos más maduros añado una capa de alineación estratégica: ¿esta funcionalidad mueve una métrica clave? También organizo sincronizaciones regulares con los stakeholders para detectar conflictos de prioridad pronto, y mantengo una lista documentada de temas aplazados. El objetivo no es solo elegir el elemento con mayor puntuación, sino secuenciar el trabajo para que las piezas fundamentales desbloqueen valor futuro. Reviso las prioridades en cada sprint y las ajusto cuando cambian las señales del mercado.

Empiezo alineando el resultado que el producto debe generar, no solo los entregables. Trabajo con los stakeholders para acordar una métrica principal y dos o tres métricas de apoyo antes de construir nada. Para una funcionalidad de crecimiento puede ser la tasa de activación más la retención a 30 días. Para una de monetización, la tasa de conversión y el ingreso medio por usuario. También defino una contra-métrica para detectar efectos secundarios no deseados: por ejemplo, vigilar el volumen de tickets de soporte al simplificar el onboarding. Tras el lanzamiento, hago una revisión estructurada a los 30 y 90 días y comparto los aprendizajes con el equipo.

Veo mi rol como el de crear las condiciones para que ingenieros y diseñadores hagan su mejor trabajo, no el de dirigirlos. Involucro a ambas disciplinas lo antes posible, idealmente en la fase de definición del problema. Con los diseñadores me centro en una comprensión compartida del problema del usuario antes de hablar de soluciones. Con los ingenieros priorizo la transparencia sobre el "por qué" de cada iniciativa y busco activamente su opinión sobre los compromisos de alcance. Tengo una sincronización semanal para eliminar bloqueos y una retrospectiva quincenal para mejorar el proceso. También doy visibilidad a los ingenieros sobre los comentarios de usuarios y las métricas.

La IA forma ya parte de varias etapas de mi flujo de trabajo como PM. Para la investigación de usuarios, la uso para analizar transcripciones de entrevistas a escala: puedo identificar patrones en diez sesiones en minutos, algo que antes llevaba horas de codificación manual. Para la redacción de specs, proporciono puntos clave a un modelo y obtengo un primer borrador de PRD estructurado que luego edito en profundidad. Me lleva al 40% del camino en pocos minutos. Para la comunicación con stakeholders, uso la IA para reformular conceptos técnicos para audiencias no técnicas y para verificar si mi formulación de un problema es clara. Los ámbitos donde todavía no me fío de la IA son las decisiones de priorización y los juicios finales: la pregunta de qué construir y por qué necesita el contexto completo del negocio, el equipo y los usuarios, que el modelo no tiene. Trato la IA como un acelerador para el trabajo estructural, no como un sustituto del juicio.

En mi empresa anterior debíamos decidir si reconstruir nuestro flujo de onboarding. Los datos mostraban un alto abandono en el paso tres, pero no sabíamos por qué. Teníamos dos semanas antes de un congelamiento de ingeniería. Realicé cinco entrevistas rápidas con usuarios y una prueba de usabilidad sin moderación. Las entrevistas revelaron que los usuarios estaban confundidos por una solicitud de permiso no explicada. En lugar de una reconstrucción completa, propuse una corrección específica: añadir una pantalla explicativa antes de la solicitud de permiso. Lo lanzamos en tres días. El abandono en el paso tres bajó un 22 % en dos semanas.

Nuestro CEO quería añadir una funcionalidad de compartir en redes sociales basándose en el feedback de dos clientes importantes. Revisé nuestros datos y encontré que menos del 4 % de los usuarios había utilizado nuestra función de compartir existente. Preparé un breve documento con los datos de uso, el coste estimado de ingeniería y tres usos alternativos de esa capacidad que se alineaban mejor con nuestro objetivo de retención. Lo presenté como una pregunta de priorización, no un desacuerdo, y ofrecí realizar un experimento ligero para validar la demanda. El CEO aceptó diferir la funcionalidad y aprobó un spike de dos semanas para probar un mecanismo de compartir más sencillo.

Lideré un módulo de reporting B2B construido en tres meses. El lanzamiento tuvo una baja adopción: menos del 10 % del segmento objetivo lo usó en los primeros 60 días. En el post-mortem identificamos dos causas principales. Primero, habíamos validado el problema con los compradores pero no con los usuarios finales, que tenían flujos de trabajo muy diferentes. Segundo, subestimamos el coste de migración desde las hojas de cálculo que ya usaban. Aprendí a separar la validación del comprador de la del usuario, y a mapear siempre el comportamiento existente antes de diseñar un reemplazo. Introduje el framework "jobs to be done" en nuestro proceso de discovery, lo que mejoró las tasas de adopción posteriores.

Trato los datos como una entrada más junto a la investigación cualitativa. Mi conjunto de herramientas habitual incluye analytics de eventos (Mixpanel, Amplitude), SQL para consultas ad hoc y pruebas A/B. Antes de cualquier experimento escribo una hipótesis con el formato "si hacemos X, esperamos Y porque Z", defino la métrica principal y el efecto mínimo detectable, y calculo el tamaño de muestra necesario. Tras el experimento analizo los resultados completos incluyendo métricas secundarias y segmentaciones. Distingo cuidadosamente entre significatividad estadística y significatividad práctica: un gain del 2 % que no justifica el coste de mantenimiento no es una victoria.

Construyo roadmaps en torno a resultados, no funcionalidades. Parto de la estrategia de la empresa y los OKRs del trimestre, luego identifico los dos o tres problemas cuya resolución movería más directamente esas métricas. Cada elemento se asocia a un enunciado del problema, una hipótesis y una métrica de éxito. Uso una estructura "ahora, próximamente, más adelante" para mantener al equipo enfocado en el corto plazo con visibilidad de la dirección. Comparto una versión del roadmap con los stakeholders clave mensualmente y lo actualizo cuando cambian las prioridades estratégicas.

Empiezo por el problema, no la solución. La primera sección cubre el problema del usuario, la evidencia que lo respalda y el caso de negocio. Luego defino los objetivos y los no-objetivos explícitos: esta sección es a menudo la más valiosa porque previene la expansión del alcance. Incluyo user stories con el formato "como [usuario], quiero [acción] para que [resultado]" y criterios de aceptación verificables. Añado una sección de preguntas abiertas con responsables y plazos, y una sección de riesgos técnicos, de UX y de negocio. Reviso el PRD con ingeniería y diseño antes de finalizarlo.