Preguntas de entrevista Junior Product Manager

Qué se espera en el nivel Junior

Se espera sentido de producto, métricas básicas y problemas guiados y bien delimitados.

Preguntas de ejemplo para entrevista de Product Manager

• ConductualDiseña un producto para ayudar a la gente a desplazarse de forma más sostenible.
  Lo que cubre una buena respuesta

  • Definición de sostenibilidad en movilidad
  • Segmentación de usuarios (urbanos vs. suburbanos)
  • Integración multimodal (transporte público, bicicletas, coche compartido)
  • Gamificación y recompensas por hábitos sostenibles
  • Métricas de éxito: reducción de emisiones, adopción, retención

  Ver respuesta de ejemplo

  Para diseñar un producto que fomente el desplazamiento sostenible, primero hay que entender las barreras actuales: falta de información en tiempo real, coste percibido y comodidad. El producto sería una app que integra todas las opciones de movilidad (transporte público, bicicletas compartidas, patinetes, vehículos eléctricos, carpooling) en un solo planificador multimodal. Ofrecería rutas optimizadas no solo por tiempo, sino por huella de carbono, con un score de sostenibilidad para cada opción. Incluiría gamificación: puntos por cada viaje verde canjeables en comercios locales o descuentos en recarga de vehículos eléctricos. Para los usuarios recurrentes, se podrían ofrecer suscripciones mensuales con ventajas. El backend usaría APIs abiertas de operadores de transporte y un motor de optimización de rutas multiobjetivo. Un error común es centrarse solo en la tecnología sin considerar incentivos de comportamiento; la gamificación y la transparencia en el impacto ambiental son clave. El éxito se mediría con métricas como reducción de emisiones calculadas, tasa de adopción semanal y Net Promoter Score. A escala, se podría añadir machine learning para predecir demanda y ajustar oferta.

• ConductualElige un producto que te encante y explica cómo lo mejorarías.
  Lo que cubre una buena respuesta

  • Elección de producto con alta afinidad
  • Identificación de dolor o ineficiencia específica
  • Propuesta de mejora concreta y viable
  • Impacto medible en experiencia o métricas
  • Consideración de viabilidad técnica y de negocio

  Ver respuesta de ejemplo

  El producto que elijo es la app de mapas Google Maps. Me encanta por su precisión y cobertura, pero la mejora que propongo es la funcionalidad de 'rutas colaborativas en tiempo real' para evitar zonas peligrosas o con incidencias. Muchos usuarios confían en las sugerencias de la comunidad, pero Google Maps no incorpora feedback sobre seguridad vial (obras, zonas con alta siniestralidad, atascos repentinos por accidentes). La mejora permitiría que los usuarios reporten eventos (ej. 'bache peligroso', 'corte de carril') y la app los verifique con datos de sensores y usuarios cercanos. Esto haría que las rutas sean más seguras y eficientes. La implementación sería un sistema de reportes con un mecanismo de reputación (votos positivos/negativos) y moderación automática mediante machine learning. El impacto se mediría con la reducción de incidentes reportados vs. reales (conexión con datos de tráfico de Waze) y mejora en la satisfacción del usuario. Un riesgo es el abuso de reportes falsos, por lo que se necesita un sistema de confianza. Esta mejora diferenciaría a Google Maps de competidores como Waze, integrando lo mejor de ambos.

• TécnicaLos usuarios activos diarios cayeron un 10% de la noche a la mañana: ¿cómo lo investigas?
  Lo que cubre una buena respuesta

  • Verificación de datos: error de medición vs. cambio real
  • Segmentación de la caída (por cohorte, geografía, plataforma)
  • Análisis de cambios recientes (app, servidor, campañas)
  • Investigación de causas externas (eventos, competencia)
  • Plan de acción con hipótesis priorizadas

  Ver respuesta de ejemplo

  Ante una caída del 10% en DAU de la noche a la mañana, lo primero es validar que la métrica es correcta: revisar pipelines de datos, posibles errores de instrumentación o cambios en la definición de 'activo'. Si confirmo que es real, segmento la caída por plataforma (iOS/Android), geografía, tipo de usuario (nuevo vs. recurrente) y versión de la app. Así puedo ver si es un problema generalizado o localizado. Luego, reviso todos los cambios desplegados en las últimas 48 horas: nuevas versiones, cambios en servidores, actualizaciones de APIs, o campañas de marketing. También miro eventos externos: fallos de infraestructura (cloud), noticias, o entrada de un competidor con alguna promoción. Con esa información, formulo hipótesis: por ejemplo, 'un cambio en el feed algorítmico redujo la frecuencia de publicaciones visibles'. Para cada hipótesis, realizo tests A/B o análisis de cohortes. Por ejemplo, comparar la retención entre usuarios expuestos al nuevo feed vs. antiguo. El error común es actuar sin datos: primero hay que contener el problema (por ejemplo, rollback si se identifica un cambio), pero siempre midiendo. Documento todo y establezco un proceso de monitoreo para detectar caídas similares más rápido.

• Técnica¿Cómo medirías el éxito de un nuevo flujo de onboarding?
  Lo que cubre una buena respuesta

  • Definición de objetivos del onboarding (activación vs. retención)
  • Métricas de embudo: tasas de finalización, tiempo por paso
  • Métricas de calidad: comprensión del valor, encuestas NPS/CSAT
  • Métricas a largo plazo: retención D1, D7, D30, feature adoption
  • Experimentos A/B para optimizar

  Ver respuesta de ejemplo

  Para medir el éxito de un nuevo flujo de onboarding, primero hay que definir el objetivo: no solo que el usuario complete los pasos, sino que entienda el valor principal del producto y realice la acción clave (ej. hacer su primera compra, crear su primer proyecto). Las métricas principales son de embudo: tasa de finalización de cada paso, abandono por paso, tiempo medio por paso. Pero también métricas cualitativas: una encuesta breve al final (¿Qué tan claro fue el proceso?) y el NPS. A largo plazo, mido la retención a 1, 7 y 30 días, y la adopción de funcionalidades clave (ej. si el onboarding enseñó a usar el carrito, ¿cuántos usuarios agregan un producto en la primera semana?). También es crucial comparar con el flujo anterior mediante un test A/B: aleatoriamente asigno usuarios al flujo nuevo vs. antiguo y comparo las métricas de activación (ej. primera semana con 3 sesiones) y retención mensual. Un error común es enfocarse solo en la tasa de finalización; si el onboarding es muy rápido pero el usuario no retiene el valor, será contraproducente. Por eso también mido el éxito en términos de 'time-to-value' (tiempo hasta la primera acción significativa) y la tasa de error (ayuda solicitada, clics en 'saltar').

• Técnica¿Cómo priorizas entre dos funcionalidades con un impacto similar?
  Lo que cubre una buena respuesta

  • Uso de frameworks de priorización (RICE, ICE, MoSCoW)
  • Consideración de esfuerzo e incertidumbre
  • Alineación con objetivos estratégicos y visión
  • Evaluación de riesgos y dependencias
  • Toma de decisiones basada en datos con experimentos

  Ver respuesta de ejemplo

  Cuando dos funcionalidades tienen un impacto similar en métricas como ingresos o retención, hay que priorizar usando más dimensiones. Primero, aplico un framework como RICE (Reach, Impact, Confidence, Effort). Calculo el alcance (usuarios afectados), impacto (mejora en métrica), confianza (¿tenemos datos sólidos o es estimación?) y esfuerzo (ingeniería, diseño, etc.). Normalmente, la que tenga mayor Score RICE va primero. Si siguen empatadas, considero el coste de oportunidad y la alineación estratégica: ¿cuál apoya mejor los objetivos trimestrales? Por ejemplo, si una funcionalidad permite entrar a un nuevo segmento de mercado, esa es prioritaria. También puedo desglosar el impacto en sub-métricas: una puede tener mayor impacto directo en ingresos pero menor en retención. Otra herramienta es hacer un experimento rápido (test A/B) para medir el verdadero impacto de cada una en un subconjunto de usuarios. El error común es pensar que el impacto es igual solo por una métrica agregada; hay que desglosar. Finalmente, también considero las dependencias: si una funcionalidad es prerrequisito para otra futura, conviene hacerla antes.

• Diseño de sistemas¿Cómo estimarías el tamaño de mercado de una app de carga de vehículos eléctricos?
  Lo que cubre una buena respuesta

  • Definición del mercado: residencial vs. público vs. flotas
  • Enfoque top-down (número de VE, carga por sesión, frecuencia)
  • Enfoque bottom-up (geografías, penetración de VE, hábitos de carga)
  • Supuestos razonables y fuentes de datos
  • Validación con benchmarks y ajuste de TAM/SAM/SOM

  Ver respuesta de ejemplo

  Para estimar el tamaño de mercado de una app de carga para vehículos eléctricos, primero defino qué mercado abordamos: ¿solo carga pública o también residencial? Asumamos que es una app que ayuda a encontrar y pagar cargadores públicos. Usaré un enfoque top-down combinado con bottom-up. Top-down: comienzo con el número total de vehículos eléctricos (VE) en el país/región objetivo (ej. 1 millón en España en 2025). Luego, estimo cuántas sesiones de carga pública realizan por semana (por ejemplo, un usuario promedio carga en público 2 veces por semana). Así, sesiones semanales totales = 1M * 2 = 2M. Supongo que cada sesión implica una tarifa de transacción baja (ej. 0.10€) más posible suscripción mensual (ej. 5€ para el 20% de usuarios). El TAM (mercado total direccionable) sería el valor de todas las transacciones de carga pública en la región. Bottom-up: parto de un número de cargadores públicos (ej. 30,000), ocupación media (30%), y tarifa por sesión (15kWh * 0.30€/kWh = 4.5€). Así, ingresos anuales potenciales = 30,000 cargadores * 30% ocupación * 24h * 365 días * (sesiones/hora?)... más detallado: supongo 4 sesiones por cargador al día de media, cada sesión 4€, da 30k*4*365*4 = 175M€. Luego ajusto por el porcentaje de transacciones que pasan por la app (SAM, mercado accesible) y por nuestra cuota (SOM). Un error común es sobreestimar la penetración de carga pública o no considerar la estacionalidad. Es clave usar fuentes como ANFAC, BloombergNEF y validar con startups similares.

• ConductualCuéntame de una decisión de producto que tomaste con datos limitados.
  Lo que cubre una buena respuesta

  • Contexto de decisión con datos limitados
  • Uso de marco cualitativo (entrevistas, observación)
  • Aplicación de principios y heurísticas (coste-beneficio, velocidad)
  • Método para reducir incertidumbre (quick experiment)
  • Resultados y lecciones aprendidas

  Ver respuesta de ejemplo

  En un producto B2B de análisis de datos, necesitábamos decidir si añadir un nuevo tipo de visualización (diagrama de sankey) o mejorar los filtros existentes, pero teníamos pocos datos de uso porque la funcionalidad de filtros era nueva. Con solo 2 semanas de datos y feedback cualitativo de 5 clientes, opté por los filtros mejorados. Mi razonamiento fue: 1) Los filtros afectaban a todas las visualizaciones, mientras que el sankey solo a flujos; 2) Las entrevistas revelaban frustración con la lentitud de los filtros; 3) Podíamos lanzar los filtros mejorados en 1 semana versus 3 para el sankey. Hicimos un test con 10 clientes beta: implementamos una versión mejorada de filtros (búsqueda por texto, filtros combinados) y medimos el tiempo de tarea. Redujo un 40% el tiempo para encontrar un dato concreto. El feedback fue muy positivo, y los clientes que pidieron sankey posteriormente lo aceptaron como mejora futura. Aprendí que con datos limitados, vale la pena priorizar las mejoras que tienen el mayor impacto en la experiencia central y menor esfuerzo, respaldado por observaciones cualitativas. Es clave documentar los supuestos y validarlos rápido con un experimento pequeño.

• ConductualDescribe una vez que le dijiste que no a un stakeholder de alto perfil.
  Lo que cubre una buena respuesta

  • Contexto del stakeholder y la solicitud
  • Razonamiento basado en datos y estrategia
  • Alternativas y compromisos propuestos
  • Manejo de la relación y comunicación asertiva
  • Resultado positivo a largo plazo

  Ver respuesta de ejemplo

  Un CEO quería añadir una funcionalidad de chat en vivo en la app de e-commerce, argumentando que mejoraría la conversión. Sin embargo, los datos mostraban que las consultas más comunes ya estaban cubiertas por una FAQ optimizada y que el chat tendría un alto coste de operación (agentes) y riesgo de escalabilidad. Le dije que no de forma constructiva, explicando: 1) Nuestros tests A/B mostraban que los usuarios que usan FAQ tienen una tasa de conversión un 5% mayor que la media; 2) Implementar chat requeriría un equipo de soporte 24/7 o un chatbot, lo que desviaría recursos del roadmap actual; 3) Propuse una alternativa: mejorar la búsqueda dentro de la FAQ y añadir un bot con respuestas automáticas a preguntas frecuentes (coste menor). Presenté datos de coste estimado (50k€ vs 5k€) y el impacto esperado en CSAT. El CEO aceptó la alternativa, y al mes vimos una reducción del 20% en tickets de soporte. La clave fue no decir 'no' sin más, sino ofrecer una solución alineada con su objetivo (mejorar conversión) usando datos. También mantuve la relación positiva al reconocer su visión y proponer un paso intermedio.

Qué evalúan los entrevistadores

Cómo prepararte

• Estructura siempre tu respuesta primero: los marcos superan a la lluvia de ideas sin estructura.
• Vincula cada idea con un problema del usuario y una métrica medible.
• Practica en voz alta las preguntas de producto y métricas; la claridad del razonamiento es la puntuación.

Preguntas frecuentes