Preguntas de entrevista de Product Manager — 35 con respuestas reales
Si estás buscando trabajo como PM en una empresa tech, la entrevista de producto es el filtro más duro. No alcanza con saber de agile o haber lanzado features — te van a pedir que pienses en voz alta, que estructures problemas ambiguos, que justifiques decisiones con datos.
Esta guía tiene 35 preguntas reales organizadas por categoría, con respuestas estructuradas, errores comunes y lo que el entrevistador realmente está evaluando. Todo en español rioplatense, sin vueltas.
Cómo prepararte antes de la entrevista
Antes de entrar en las preguntas, tres reglas que se aplican a todas las categorías:
1. Pensá en voz alta siempre. El entrevistador quiere escuchar tu proceso, no solo tu respuesta final. Si llegás a la respuesta correcta en silencio, no sirve.
2. Clarificá antes de responder. Preguntar "¿qué querés optimizar?" o "¿en qué etapa está el producto?" no es una señal de debilidad — es exactamente lo que hace un buen PM.
3. Usá estructuras, no checklists. El framework es un scaffold para pensar. Si lo recitás de memoria sin aplicarlo al caso, el entrevistador lo nota.
Parte 1: Estimación de mercado (Market Sizing)
Las preguntas de market sizing evalúan si podés descomponer un problema grande en partes manejables y llegar a un número razonable. No importa tanto el número exacto — importa la lógica.
Pregunta 1: ¿Cuántas peluquerías hay en Argentina?
Lo que evalúan: Tu capacidad de hacer estimaciones bottom-up con supuestos explícitos.
Respuesta modelo:
Primero, ¿qué necesito saber? Argentina tiene aproximadamente 46 millones de habitantes. Asumo que la mitad van a peluquería con cierta regularidad — digamos 23 millones de personas.
>
¿Con qué frecuencia? Hombres, cada 3-4 semanas (unas 15 veces al año). Mujeres, cada 6-8 semanas (unas 7 veces al año). Mezclando géneros, asumo un promedio de 10 visitas por persona por año.
>
Eso da 230 millones de visitas al año. ¿Cuántas puede atender una peluquería? Un local con 2 sillones trabajando 8 horas, 6 días a semana, puede atender unas 4 personas por sillón por día = 8 por día = 48 por semana = 2.400 al año.
>
230.000.000 / 2.400 ≈ 95.000 peluquerías. Redondeo a ~100.000.
>
Sanity check: en Buenos Aires, 3 millones de personas y peluquerías en cada esquina → si hay 100 personas por cuadra y una peluquería cada 3-4 cuadras, en la ciudad habría unas 15.000. Extrapolando a todo el país, 100.000 parece razonable.
Error común: Ir directo al número sin explicar los pasos. O usar datos que "recordás" sin decir de dónde vienen.
Tip: Siempre hacé un sanity check al final con un enfoque distinto. Si los dos métodos dan órdenes de magnitud distintos, hay un error en alguno de los supuestos.
Pregunta 2: Estimá el mercado total de delivery de comida en México
Lo que evalúan: Market sizing con enfoque TAM/SAM/SOM y razonamiento por valor, no solo volumen.
Respuesta modelo:
Voy a usar un enfoque top-down y después valido bottom-up.
>
México tiene 130 millones de habitantes, ~40 millones de hogares. Asumo que el 25% usa delivery de comida al menos una vez por semana — unos 10 millones de hogares activos. Gasto promedio por pedido: $250 MXN. Frecuencia: 1.5 veces por semana.
>
10M hogares × 1.5 pedidos/semana × $250 × 52 semanas = ~195 mil millones de pesos al año ≈ USD 10 mil millones.
>
Bottom-up: Rappi + DiDi Food + Uber Eats manejan ~5M pedidos diarios en México (dato de industria reportado en prensa). Ticket promedio: $250 MXN. 5M × $250 × 365 = 456 mil millones MXN ≈ USD 23 mil millones.
>
Hay una discrepancia. Reviso mis supuestos — probablemente subestimé la frecuencia de uso o el porcentaje de hogares activos. Los números reales de las plataformas sugieren que el mercado es más grande. Ajustaría mi estimación a ~USD 15-20 mil millones.
Lo que diferencia una respuesta buena de una excelente: Reconocer las discrepancias y razonar sobre por qué existen, en vez de ignorarlas.
Pregunta 3: ¿Cuántos iPhones se venden en Argentina por año?
Respuesta modelo:
Argentina tiene 46M de habitantes, ~15M de smartphones vendidos por año (reposición cada 3 años en promedio). El mercado premium (iPhone + Samsung flagship) representa aproximadamente el 15-20% del total. iPhone captura quizás la mitad de ese segmento.
>
15M × 18% × 50% ≈ 1,35 millones de iPhones.
>
Validación: si el iPhone más barato cuesta $800 USD en Argentina, y el ingreso medio es ~$500/mes, es un producto de lujo. El 3% de la población comprando uno cada año es plausible dado el contexto de aspiracionalidad de la marca.
Parte 2: Diseño de producto
Estas preguntas evalúan si podés identificar el problema real del usuario (no la feature que te pidieron), si estructurás soluciones antes de proponer, y si entendés las trade-offs.
Pregunta 4: ¿Cómo mejorarías Spotify?
Lo que evalúan: Si empezás por usuarios y problemas, no por features.
Estructura recomendada:
- 1Clarificá el objetivo (¿mejorar retención, monetización, nuevos usuarios?)
- 2Segmentá usuarios
- 3Identificá pain points con evidencia
- 4Priorizá un problema
- 5Generá soluciones
- 6Priorizá la solución
- 7Definí métricas de éxito
Respuesta modelo:
Antes de proponer, ¿qué objetivo priorizamos? Asumo que el foco es retención de usuarios free (que es donde está la mayoría del volumen).
>
Segmentando usuarios de Spotify free: tenemos casual listeners (playlists para trabajar, pocas búsquedas activas), music explorers (buscan artistas nuevos, siguen playlists editoriales) y social listeners (comparten canciones, reaccionan a lo que escuchan amigos).
>
El pain point más frecuente en el segmento free: la experiencia de descubrimiento de música nueva es frustrante porque las recomendaciones en Discover Weekly llegan una vez por semana y son un blob de 30 canciones sin contexto (¿por qué me recomiendan esta canción?).
>
Propuesta: "Discovery Cards" — en vez de una playlist de 30 canciones, un feed de tarjetas diarias donde cada recomendación incluye por qué te la están mostrando ("Porque escuchaste X artista" / "Popular en tu ciudad" / "Tu amigo @nico la guardó"). Límite de 5 tarjetas por día en el tier free para crear hábito sin abrumar.
>
Métricas de éxito: % de usuarios que reproducen al menos una canción de Discovery Cards por semana (engagement), saves desde Discovery Cards (calidad de recomendación), retención a 30 días del segmento free.
Error común: Proponer features genéricas ("un modo oscuro", "mejor UI") sin conectarlas a un problema real del usuario.
Pregunta 5: Diseñá un producto para ayudar a adultos mayores a aprender tecnología
Respuesta modelo:
Empiezo por entender el usuario. Adultos mayores no son un bloque homogéneo — hay diferencia enorme entre alguien de 65 años que trabajó con computadoras y alguien de 80 que nunca tuvo smartphone.
>
Me enfoco en 65-75 años, usuarios con un smartphone Android o iPhone dado por un familiar, que quieren ser independientes pero se frustran y terminan llamando a los hijos.
>
El problema real no es "no saben tecnología" — es que cada vez que algo falla o cambia, no tienen a quién preguntar sin sentirse una carga.
>
Solución: una app de "Acompañante Digital" que usa screen sharing pasivo. El familiar joven instala una app en su teléfono y el adulto mayor puede "compartir pantalla" con un toque para mostrar exactamente qué está viendo. El joven puede anotar sobre la pantalla del mayor ("tocá acá") sin necesitar estar presente físicamente.
>
Diferencial vs FaceTime/WhatsApp video: no requieren que el mayor enfoque la cámara ni explique qué ve — el familiar ya ve su pantalla.
>
Métricas de éxito: número de "ayudas" enviadas por semana, tiempo promedio de resolución del problema, NPS del segmento adulto mayor, reducción de llamadas de voz para soporte técnico.
Pregunta 6: ¿Cómo diseñarías el onboarding de una app de finanzas personales?
Respuesta modelo:
El onboarding de finanzas personales tiene un problema único: requiere conectar cuentas bancarias (alta fricción, alta desconfianza) antes de entregar valor.
>
Principio que aplico: "deliver value before asking for commitment."
>
Flujo propuesto:
1. Pantalla de bienvenida con promesa específica: "En 2 minutos sabés exactamente en qué gastás tu plata"
2. Onboarding manual: ingresás tus 3 últimas compras a mano (no requiere login bancario). La app ya te muestra una categorización y un insight básico.
3. Recién en el paso 3, la app propone: "Para hacerlo automático, conectá tu cuenta" — y el usuario ya vio el valor.
>
Métrica crítica: % de usuarios que completan la conexión bancaria. Si es menor al 40%, el onboarding manual no está entregando suficiente valor percibido en los pasos anteriores.
Parte 3: Definición de métricas
Esta es la categoría donde más PM juniors fallan. Saber nombrar una North Star Metric no alcanza — tenés que demostrar que entendés la jerarquía entre métricas y cómo se conectan al negocio.
Pregunta 7: ¿Cuál sería la North Star Metric de Netflix?
Lo que evalúan: Que entiendas qué es una NSM (única, accionable, predictora de valor a largo plazo) y que no confundas con métricas de vanidad.
Respuesta modelo:
La tentación es decir "número de suscriptores" o "ingresos", pero esas son métricas de negocio, no de valor del usuario.
>
Netflix está en el negocio de entretenimiento. El valor que entrega es tiempo bien invertido en contenido. Una buena NSM sería: "horas de contenido consumido por suscriptor activo por semana".
>
¿Por qué esta? Porque correlaciona directamente con retención (quien consume más, cancela menos), está bajo control del equipo de producto (pueden mejorar recomendaciones, autoplay, interfaz) y es un predictor adelantado de churn.
>
Input metrics que la mueven:
- % de usuarios que terminan el primer episodio de una serie nueva
- Tiempo hasta el primer play luego de abrir la app
- Relevancia de recomendaciones (CTR en el homepage)
>
Guardrail metrics: tiempo promedio de sesión no debería exceder un umbral que indique binge-watching compulsivo (riesgo de brand safety / regulatory).
Pregunta 8: Definí las métricas para un feature de "modo estudio" en Duolingo
Respuesta modelo:
Primero defino el objetivo del feature: ayudar a usuarios a completar más lecciones en sesiones largas sin perder el hilo.
>
North Star del feature: Lecciones completadas por sesión de modo estudio.
>
Input metrics:
- Tiempo promedio por sesión de modo estudio
- % de usuarios que activan modo estudio al menos 2 veces por semana
- Tasa de completación de lección dentro del modo vs fuera
>
Guardrail metrics:
- Tasa de errores por lección (si el modo estudio reduce fricción tanto que los usuarios no aprenden, hay un problema)
- Retención a 7 días (el modo no debería "quemar" a los usuarios)
>
Métricas de negocio asociadas:
- Conversión a Duolingo Plus entre usuarios de modo estudio (hipótesis: usuarios más comprometidos pagan más)
Pregunta 9: ¿Cómo medirías el éxito de una feature de búsqueda?
Respuesta modelo:
La búsqueda es un feature de intención — el usuario ya sabe lo que quiere. El éxito es que lo encuentre rápido.
>
Métricas primarias:
- Zero-results rate: % de búsquedas que no devuelven resultados (si es >10%, hay un problema grave en el índice o en entender queries)
- Click-through rate del primer resultado: ¿qué tan seguido el usuario toca el primer resultado? Debe ser >50% en una búsqueda bien rankeada
- Query reformulation rate: cuántas veces el usuario modifica su búsqueda sin hacer click — indica que los resultados no satisfacen la intención
>
Métricas secundarias:
- Time to first click: velocidad a la que el usuario encuentra lo que busca
- % de sesiones que incluyen búsqueda vs total de sesiones
>
Guardrail:
- Latencia de respuesta de búsqueda (si optimizás relevancia pero la búsqueda tarda 3 segundos, es peor que antes)
Pregunta 10: El DAU/MAU de tu producto bajó un 15% en las últimas 2 semanas. ¿Qué hacés?
Lo que evalúan: Si tenés un proceso sistemático de diagnóstico, no si "reaccionás rápido".
Respuesta modelo:
Antes de sacar conclusiones, verifico que el dato sea correcto. ¿Hay un problema de tracking? ¿Cambió la definición de "usuario activo"? Si el dato está limpio, empiezo a descomponer.
>
Paso 1 — Segmentar: ¿La caída es uniforme o afecta a un segmento específico? Plataforma (iOS vs Android), geografía, plan (free vs paid), cohorte de registro, canal de adquisición.
>
Paso 2 — Correlacionar con eventos: ¿Hubo un deploy reciente? ¿Un cambio en el onboarding? ¿Un competidor lanzó algo? ¿Cambió algo en la distribución (App Store ranking, cambios en algoritmo de notificaciones del OS)?
>
Paso 3 — Mirar el funnel: ¿La caída está en nuevos usuarios que no activan, en usuarios existentes que dejan de volver, o en ambos? Si es retención, ¿cuándo se van (día 1, día 7, día 30)?
>
Paso 4 — Hipótesis y validación rápida: Con la segmentación del paso 1, tengo 2-3 hipótesis. Antes de arreglar nada, confirmo cuál es la causa raíz.
>
Error a evitar: Hacer un hotfix inmediato sin saber la causa. Si la caída es por un bug específico en Android, parcharlo. Pero si es por una caída en la calidad de las recomendaciones, el hotfix de notificaciones push no va a resolver nada.
Parte 4: Frameworks de priorización
Pregunta 11: Tenés un backlog de 40 features. ¿Cómo priorizás?
Respuesta modelo:
Ningún framework de priorización reemplaza el juicio, pero los frameworks sí fuerzan a hacer explícitos los supuestos.
>
Primero, limpio el backlog: saco duplicados, junto las features que atacan el mismo problema y elimino las que claramente no están alineadas con la estrategia del trimestre.
>
Después aplico RICE para los ítems que quedan:
>
```
RICE Score = (Reach × Impact × Confidence) / Effort
>
Reach: cuántos usuarios afecta en un período (ej: usuarios por mes)
Impact: cuánto mueve la North Star (escala: 0.25 / 0.5 / 1 / 2 / 3)
Confidence: qué tan seguros estamos del Reach e Impact (100% / 80% / 50%)
Effort: semanas-persona de desarrollo
```
>
Ejemplo concreto:
```
Feature A: Notificaciones push
Reach: 50.000 usuarios/mes
Impact: 1 (mueve moderado la NSM)
Confidence: 80%
Effort: 2 semanas
RICE = (50.000 × 1 × 0.8) / 2 = 20.000
>
Feature B: Modo offline
Reach: 10.000 usuarios/mes (solo los que tienen mala conexión)
Impact: 3 (para esos usuarios, es crítico)
Confidence: 50%
Effort: 8 semanas
RICE = (10.000 × 3 × 0.5) / 8 = 1.875
```
>
El RICE Score no es una sentencia — es el inicio de una conversación. Si Feature B es un must-have para expandir a mercados con mala conectividad (objetivo estratégico del año), ese contexto overridea el score.
Pregunta 12: Explicá la diferencia entre RICE, MoSCoW e ICE. ¿Cuándo usás cada uno?
Respuesta modelo:
Los tres son frameworks de priorización, pero sirven para contextos distintos.
>
MoSCoW (Must have / Should have / Could have / Won't have) es útil cuando necesitás alinear con stakeholders no técnicos en poco tiempo. Es cualitativo y fuerza a separar lo innegociable de lo deseable. Ideal para planificación de un sprint o una release con deadline fijo.
>
ICE (Impact / Confidence / Ease) es la versión simplificada de RICE, sin el componente de Reach. Es más rápido de calcular y funciona bien cuando todas las features afectan a la misma base de usuarios (no hay diferencias de reach). Ideal para equipos pequeños o etapas tempranas donde la velocidad de decisión importa más que la precisión.
>
RICE agrega el componente de Reach, lo que lo hace más preciso cuando tenés features con alcances muy distintos (ej: una feature para todos vs. una para un segmento). Es el más riguroso de los tres pero requiere más datos de entrada. Ideal cuando tenés datos confiables de uso.
>
Cuándo uso cada uno:
- Reunión de planning con el CEO: MoSCoW (rápido, visual, conversacional)
- Decisión interna del equipo de producto: ICE o RICE según disponibilidad de datos
- Presentación a inversores sobre roadmap: RICE (muestra que hay rigor cuantitativo)
Pregunta 13: ¿Cómo priorizarías entre deuda técnica y nuevas features?
Lo que evalúan: Que entiendas que la deuda técnica es una decisión de negocio, no solo técnica.
Respuesta modelo:
Primero, rechazo la premisa de que es una dicotomía. La deuda técnica afecta la velocidad de delivery de features futuras — entonces es una inversión en capacidad futura, no un gasto.
>
Mi framework:
>
Deuda crítica (resolver ya): Si está causando bugs en producción, degradando performance perceptible por usuarios, o bloqueando features que están en el roadmap próximo. Esto es P0 — pausa features.
>
Deuda estructural (planificar): Si está aumentando el tiempo de desarrollo de todas las features nuevas en un 20-30%, hay que cuantificarlo. "Esta deuda nos cuesta 1 sprint por cada 4 sprints." Con ese dato, es fácil justificar dedicar un sprint entero a refactoring.
>
Deuda cosmética (backlog): Si es feo pero no duele, va al backlog con un RICE score bajo.
>
Regla práctica: Nunca menos del 15% de la capacidad del equipo en deuda técnica por defecto. Si ese porcentaje no es suficiente para mantener la deuda estable, se negocia con liderazgo mostrando el impacto en velocidad de entrega.
Parte 5: Manejo de stakeholders
Pregunta 14: Un ejecutivo senior te pide que agregues una feature que pensás que está mal. ¿Qué hacés?
Respuesta modelo:
Lo primero es entender qué problema están tratando de resolver, no debatir la feature en sí. "Contame más sobre qué problema viste que te llevó a esta idea" — muchas veces la solución que proponen es válida pero hay otras formas de llegar al mismo lugar.
>
Si después de escuchar sigo pensando que es la decisión equivocada, presento los datos: ¿qué métrica debería mejorar esta feature? ¿Tenemos evidencia de que es un pain point para los usuarios? ¿Cuál es el costo de oportunidad (qué no vamos a poder hacer si hacemos esto)?
>
Si el ejecutivo igual decide avanzar después de ver los datos, lo acepto pero lo dejo documentado: "Vamos a construir X, esperamos que impacte en Y, vamos a medir Z en 4 semanas." Así, si la feature no funciona, hay un aprendizaje claro. Si funciona, me alegro de haber estado equivocado.
>
Lo que no hago: construirla sin registrar las métricas de éxito, o resistirla pasivamente (diciéndole que sí pero depriorizándola indefinidamente). Ambas son formas de perder confianza con el stakeholder.
Pregunta 15: ¿Cómo manejás cuando el equipo de ingeniería dice que una feature va a tardar el doble de lo estimado?
Respuesta modelo:
Antes de cualquier reacción, entiendo el porqué. Las razones más comunes son: la complejidad técnica fue subestimada en el planning (falta de discovery técnico previo), surgieron dependencias no previstas, o la estimación original fue dada con presión de tiempo.
>
Dependiendo de la causa, las respuestas son distintas:
>
Si fue una subestimación por falta de discovery: Me hago cargo como PM — debería haber habido más tiempo de téchnical spike antes de comprometer la fecha. Para el futuro, incorporo un paso de spike de 1-2 días antes de estimar features complejas.
>
Si surgieron dependencias nuevas: Evalúo si se puede hacer una versión reducida (MVP) que entregue el valor core sin la parte que se complejizó. Muchas veces sí.
>
Si la estimación original fue bajo presión: Es una conversación de proceso, no de esta feature puntual. Necesito proteger al equipo de dar estimaciones sin análisis.
>
Lo que comunico al stakeholder: "Tenemos un cambio en el timeline. Les cuento por qué y les traigo 2 opciones: hacer el 80% del valor en la fecha original, o hacer el 100% con 2 semanas más."
Pregunta 16: ¿Cómo alineás a equipos distintos (marketing, ventas, ingeniería) en torno a un roadmap?
Respuesta modelo:
El problema de alineación casi siempre es un problema de información asimétrica. Marketing no sabe qué limitaciones técnicas tiene el equipo. Ingeniería no sabe qué le prometió ventas a los clientes. El PM es el nodo que conecta esa información.
>
Mi proceso:
>
1. Discovery compartido: Antes de presentar el roadmap, tengo conversaciones 1:1 con los leads de cada área para entender qué necesitan y por qué. Nada de sorpresas en la reunión grande.
>
2. Roadmap con "por qué", no solo "qué": Cada ítem del roadmap incluye el objetivo de negocio que ataca y la métrica que debería mover. Así cada área puede ver cómo su trabajo se conecta con el objetivo general.
>
3. Desacuerdos en privado, acuerdos en público: Si ventas quiere que una feature sea para el Q1 y ingeniería dice Q2, esa negociación la hago antes de la reunión de presentación, no durante.
>
4. Updates frecuentes y cortos: Un update semanal de 5 minutos por Slack con el estado del roadmap es más efectivo que una reunión mensual de 1 hora.
Parte 6: Producto que no crece
Pregunta 17: Tu producto tiene 0% de crecimiento en usuarios los últimos 3 meses. ¿Qué hacés?
Respuesta modelo:
Primero, descompongo el problema. 0% de crecimiento neto puede ser:
- Mucha adquisición + mucha pérdida (alta churn que cancela la adquisición)
- Poca adquisición + poca pérdida (producto estancado)
- Mercado saturado (ya llegamos a todos los que querían el producto)
>
Cada escenario tiene una respuesta distinta.
>
Diagnóstico:
```
Usuarios nuevos este mes - Usuarios perdidos este mes = Crecimiento neto
>
Si nuevos >> perdidos pero el neto es 0: hay un bug en el tracking
Si nuevos ≈ perdidos: problema de retención
Si nuevos son pocos: problema de adquisición o awareness
```
>
Si es un problema de retención:
- Mapeo dónde se van los usuarios (día 1, 7, 30)
- Entrevisto usuarios que cancelaron (exit interviews)
- Busco el "aha moment" — el momento en que los usuarios que se quedan entendieron el valor. ¿Los usuarios que se van están llegando a ese momento?
>
Si es un problema de adquisición:
- Analizo los canales actuales: ¿alguno está deteriorándose? (SEO perdió posiciones, el CPC subió, el referral orgánico bajó)
- Pregunta clave: ¿los usuarios que sí adquirimos son los correctos? A veces el problema no es el volumen sino el fit del usuario.
>
Si es mercado saturado:
- Expansión a nuevos segmentos o geografías
- Nuevo producto para el mismo usuario (upsell / expansión de suite)
Pregunta 18: El NPS de tu producto bajó de 45 a 20 en un trimestre. ¿Cómo lo investigás?
Respuesta modelo:
El NPS agregado no me dice nada útil solo. Lo primero es segmentarlo.
>
¿La caída está en los detractores (bajaron de categoría a promotores → ahora son detractores) o en los pasivos que se convirtieron en detractores? La respuesta cambia el diagnóstico.
>
Pasos:
>
1. Segmentar por cohorte de registro: ¿Los usuarios viejos cambiaron su percepción o el NPS bajo viene de usuarios nuevos que nunca estuvieron satisfechos?
>
2. Revisar comentarios cualitativos: El NPS tiene un campo de texto libre. Con 100 respuestas de detractores, emergen temas claros. Uso clustering simple para agrupar:
>
```python
# Ejemplo: clustering de comentarios NPS con Python
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import KMeans
>
comments = [...] # lista de comentarios de detractores
>
vectorizer = TfidfVectorizer(max_features=100, stop_words='spanish')
X = vectorizer.fit_transform(comments)
>
kmeans = KMeans(n_clusters=5, random_state=42)
kmeans.fit(X)
>
# Top words por cluster
order_centroids = kmeans.cluster_centers_.argsort()[:, ::-1]
terms = vectorizer.get_feature_names_out()
for i in range(5):
top_terms = [terms[ind] for ind in order_centroids[i, :5]]
print(f"Cluster {i}: {', '.join(top_terms)}")
```
>
3. Correlacionar con cambios de producto: ¿Qué cambió en el trimestre? Un redesign, un cambio de precios, una feature removida — todo es candidato.
>
4. Entrevistas de seguimiento: Llamar a 10 usuarios que bajaron de promotores a detractores es más valioso que 500 encuestas adicionales.
Parte 7: A/B Testing y análisis de datos
Pregunta 19: ¿Cómo diseñarías un A/B test para un cambio en el checkout?
Respuesta modelo:
Antes de diseñar el test, me aseguro de que sea necesario. Si el cambio es un bug fix obvio o una mejora de accesibilidad sin trade-off, no necesito un test — lo hago directamente.
>
Para cambios con impacto incierto en conversión, el proceso es:
>
1. Definir la hipótesis:
"Al reducir los pasos del checkout de 4 a 2, la tasa de completación de compra va a aumentar porque estamos eliminando fricción en el punto de mayor abandono."
>
2. Definir la métrica primaria y el mínimo efecto detectable:
>
```python
# Cálculo de tamaño de muestra para A/B test
from scipy import stats
import numpy as np
>
baseline_rate = 0.035 # 3.5% conversión actual
min_detectable_effect = 0.005 # queremos detectar +0.5pp
alpha = 0.05 # nivel de significancia
power = 0.80 # potencia del test
>
# Usando fórmula de dos proporciones
p1 = baseline_rate
p2 = baseline_rate + min_detectable_effect
p_avg = (p1 + p2) / 2
>
z_alpha = stats.norm.ppf(1 - alpha/2)
z_beta = stats.norm.ppf(power)
>
n = (2 * p_avg * (1 - p_avg) * (z_alpha + z_beta)2) / (p2 - p1)2
print(f"Usuarios necesarios por variante: {int(n):,}")
# Output: Usuarios necesarios por variante: 12,458
```
>
3. Definir duración:
Con 25.000 usuarios en checkout por semana y necesitando 12.458 por variante, necesito aproximadamente 1 semana para alcanzar el tamaño de muestra. Pero siempre corro el test al menos 2 semanas para capturar efectos de día de la semana.
>
4. Guardrail metrics:
Además de la tasa de completación, monitoreo el ticket promedio (no quiero que la simplificación del checkout lleve a compras más pequeñas) y la tasa de devoluciones (no quiero que la menor fricción aumente compras impulsivas que después se devuelven).
>
5. Criterio de parada:
Solo detengo el test antes si hay una degradación severa en la variante B (>20% de caída en conversión). No lo paro porque "parece que va perdiendo" — eso es el sesgo del observador.
Pregunta 20: Un A/B test mostró que la variante B tiene 8% más de conversión pero el equipo de ingeniería dice que es muy costosa de mantener. ¿Qué hacés?
Respuesta modelo:
Esta es una trade-off clásica de valor vs. costo. Para resolverla, necesito cuantificar ambos lados.
>
El valor del 8% de mejora en conversión:
Si el checkout procesa $100.000 por mes y la mejora es del 8%, el uplift es $8.000 por mes = $96.000 anuales.
>
El costo de mantenimiento:
Le pregunto a ingeniería: "¿Cuánto tiempo adicional requiere mantener esta solución vs la original?" Si la respuesta es 2 horas por semana, son 8 horas/mes × $100/hora (costo aproximado de un dev senior) = $800/mes en tiempo de ingeniería. La ecuación favorece claramente a la variante B.
>
Si la respuesta es "requiere un refactor de toda la capa de pagos", el número cambia. Ese refactor puede costar 3 semanas de ingeniería = decenas de miles de dólares upfront + ongoing.
>
En ese caso, la conversación se transforma: ¿podemos implementar una versión de la variante B que capture el 60% del beneficio con el 20% de la complejidad técnica? Generalmente sí.
>
La respuesta que no acepto: "Es muy caro, descartamos el cambio" sin cuantificar el costo de oportunidad de no hacerlo.
Pregunta 21: ¿Qué hacés si el A/B test no llega a significancia estadística?
Respuesta modelo:
Antes de concluir que "no hubo efecto", evalúo:
>
¿El test corrió suficiente tiempo? Si calculé que necesitaba 4 semanas y lo paré a las 2, el resultado es inválido — no puedo concluir nada.
>
¿El tamaño de muestra fue suficiente? Si el tráfico fue menor al esperado, el test estaba underpowered. El resultado no es "no hay efecto" sino "no pudimos detectar el efecto con la muestra que tuvimos."
>
¿Hubo contaminación? ¿Algún usuario fue asignado a las dos variantes? ¿Hubo un cambio de producto durante el test que afectó a ambos grupos de forma diferente?
>
Si todo lo anterior está bien y el test no llegó a significancia, las conclusiones posibles son:
1. El efecto real es menor al mínimo detectable que calculé (posible que exista pero sea pequeño)
2. Realmente no hay efecto
>
En ambos casos, no lanzo la variante B a producción porque no tengo evidencia de que mejore nada. Tampoco "lanzo porque no hace daño" — puede haber efectos negativos que el test no detectó por falta de potencia.
Parte 8: Go-to-market
Pregunta 22: ¿Cómo haría el go-to-market de un nuevo producto de IA para equipos de ventas?
Respuesta modelo:
Un GTM de IA para ventas tiene una dificultad específica: los usuarios finales (vendedores) a menudo no son los compradores (VP de Ventas, CFO). Hay que hacer dos trabajos en paralelo.
>
Estrategia de entrada:
>
*Segmento inicial:* No intento convencer a toda empresa. Elijo un perfil de empresa donde el dolor sea más agudo: equipos de ventas B2B de 10-50 personas, en empresas de software, donde el ciclo de venta es complejo (>30 días) y cada deal requiere personalización.
>
*Canal:* Ventas directas + community-led. Los VP de Ventas se juntan en comunidades específicas (Revenue Collective, Pavilion). Voy ahí antes de gastar en ads.
>
*Modelo de pricing para tracción:* Freemium o trial de 14 días con tarjeta de crédito required. El objetivo no es volumen en la primera etapa sino aprender qué uso genera retención.
>
*Lanzamiento interno primero:* Antes de la fecha pública, hago un closed beta con 5-10 equipos. El feedback de beta reduce el riesgo de lanzar algo que no funciona y crea los primeros casos de éxito que son la base del marketing.
>
Métricas de éxito del GTM (90 días):
- 50 cuentas pagantes (no free)
- NPS > 40 en los primeros usuarios
- Al menos 3 casos de éxito documentados
- Tiempo hasta el primer "aha moment" < 1 semana desde el registro
Pregunta 23: ¿Cómo priorizarías los canales de adquisición para una startup B2C en LATAM con presupuesto limitado?
Respuesta modelo:
Con presupuesto limitado, el orden de prioridad tiene que ser: canales orgánicos/virales primero, canales pagos después.
>
Orden de exploración:
>
1. Referidos/Word-of-mouth: Si el producto tiene valor real, la palanca más barata es que los usuarios existentes traigan otros. Antes de gastar en ads, pregunto: ¿hay algo en el producto que haga natural compartirlo? ¿Un resultado que se quiera mostrar, un beneficio que crece con más usuarios?
>
2. SEO + contenido: Para una app B2C en LATAM, el contenido en español tiene mucha menos competencia que en inglés. 20-30 artículos bien escritos pueden traer tráfico orgánico significativo en 3-6 meses.
>
3. Redes sociales orgánicas: TikTok e Instagram tienen alcance orgánico en LATAM que en mercados como EEUU ya no existe. Una cuenta bien ejecutada puede traer usuarios a costo casi cero.
>
4. Influencers pequeños (micro-influencers): En LATAM, un microinfluencer de 10-50K seguidores en el nicho correcto puede costar $200-500 por post y tener mejor conversión que ads directos.
>
5. Paid ads (último): Solo cuando tengo evidencia de que el producto convierte bien y sé cuál es mi LTV/CAC sostenible. Escalar con ads un producto que no retiene es prender fuego al presupuesto.
Parte 9: Liderazgo y visión
Pregunta 24: ¿Cuál fue el producto del que estás más orgulloso/a que construiste?
Lo que evalúan: Tu capacidad de articular el impacto en términos de negocio y de usuario, no de features.
Cómo estructurarlo:
Esta respuesta no tiene una respuesta "modelo" única porque es tuya, pero la estructura sí importa:
>
1. Contexto: ¿Qué problema existía? ¿Qué métricas estaban mal?
2. Tu rol: ¿Qué decidiste vos específicamente? No el equipo — vos.
3. El proceso: ¿Cómo llegaste a la solución? Discovery, iteraciones, pivots.
4. El resultado: Números concretos. "Mejoró la retención" no alcanza. "La retención a 30 días subió de 22% a 38% en 3 meses" sí.
5. El aprendizaje: ¿Qué harías diferente? Esto muestra madurez.
>
Red flag en esta respuesta: Contar un proyecto donde todo salió bien sin ningún obstáculo ni aprendizaje. No existe.
Pregunta 25: ¿Cómo ves el producto dentro de 3 años?
Lo que evalúan: Tu capacidad de pensar estratégicamente, no solo tácticamente. Que tengas una opinión y puedas defenderla.
Framework para responder:
1. Define el problema que el producto resuelve en su forma más esencial (no "una app de notas" sino "ayudamos a personas a pensar mejor")
2. Identifica las tendencias del mercado y tecnológicas que van a cambiar el contexto (IA, cambios de comportamiento del usuario, regulación, competencia)
3. Describe cómo el producto evoluciona para seguir siendo relevante en ese contexto
4. Identifica 1-2 apuestas que podrían ser transformadoras si aciertan
>
No hay respuesta correcta — hay respuestas con pensamiento y respuestas sin él.
Pregunta 26: ¿Qué harías en tu primer mes como PM en una empresa nueva?
Respuesta modelo:
El primer mes es de escucha, no de acción. Cualquier PM que llega con un plan de cambios en su primer semana sin haber entendido el contexto está cometiendo un error clásico.
>
Semana 1: Entender el producto desde la perspectiva del usuario. Usar el producto como usuario, leer todas las reseñas recientes en el App Store / Play Store / G2, leer el backlog completo de soporte.
>
Semana 2: Entender el negocio. Reuniones con el CEO/founder para entender la estrategia. Reuniones con ventas para entender por qué los clientes compran y por qué se van. Reunión con el equipo de datos para entender qué métricas se miran actualmente.
>
Semana 3: Entender el equipo. 1:1 con cada ingeniero y diseñador. ¿Qué les genera fricción? ¿Qué no se les escucha? ¿Qué están orgullosos de haber construido?
>
Semana 4: Síntesis y primeras hipótesis. Presento al equipo mi lectura del estado del producto: qué está funcionando, qué no, qué preguntas tengo todavía, y 2-3 hipótesis sobre dónde podría estar la mayor palanca de mejora.
>
El valor de este proceso: genero confianza con el equipo antes de proponer cambios. Las propuestas que hago después tienen contexto y son más difíciles de rechazar porque muestro que entendí el problema.
Pregunta 27: Describí una decisión difícil que tuviste que tomar con datos incompletos
Respuesta modelo (estructura):
Esta pregunta evalúa si podés hacer decisiones bajo incertidumbre de forma estructurada, no paralizada.
>
La respuesta modelo tiene esta forma:
>
1. El contexto: Qué decisión era, por qué importaba, por qué los datos eran incompletos
2. Lo que sí sabías: Qué datos tenías, aunque fueran parciales
3. El razonamiento: Cómo llenaste los huecos (analogías, benchmarks de industria, intuición experta, conversaciones con usuarios)
4. La decisión: Qué decidiste y por qué esa era la mejor opción dadas las condiciones
5. El resultado: Qué pasó, qué aprendiste
>
Tip: La parte más importante es el razonamiento — mostrar que tomaste la decisión con un proceso, no al azar. Y que definiste cómo ibas a saber si estuvo bien o mal.
Parte 10: Preguntas de cultura y self-awareness
Pregunta 28: ¿Cuál es tu mayor debilidad como PM?
Lo que evalúan: Auto-conocimiento real + si hacés algo concreto para mejorar.
Red flags:
- "Trabajo demasiado" o "Soy perfeccionista" — son respuestas evasivas que el entrevistador ya escuchó mil veces
- No tener una debilidad real
- Mencionar una debilidad pero no qué hacés al respecto
Estructura de respuesta honesta:
"Cuando tengo mucha información, tiendo a buscar más datos antes de decidir en vez de hacer la decisión con lo que tengo. Me cuesta bien lo que llaman 'decidir bajo incertidumbre.' Lo que hice para trabajarlo: pongo deadlines explícitos para mis propias decisiones — si no tengo suficientes datos para decidir para el viernes, igual decido el viernes con lo que hay y lo trato como una hipótesis que voy a validar, no como una conclusión definitiva."
Pregunta 29: ¿Cómo manejás el conflicto entre lo que los usuarios piden y lo que el negocio necesita?
Respuesta modelo:
Primero, trato de entender si es un conflicto real o aparente. Los usuarios a menudo piden soluciones específicas ("quiero un botón de exportar a Excel") cuando en realidad tienen un problema más general ("necesito compartir mis datos con mi jefe"). A veces hay soluciones que sirven a ambos.
>
Cuando el conflicto es real — el usuario quiere X y el negocio quiere Y y son genuinamente incompatibles — tengo un principio: el negocio sano a largo plazo depende de usuarios satisfechos. Una decisión que daña sistemáticamente a los usuarios para capturar valor a corto plazo destruye el producto.
>
Dicho esto, no todas las decisiones de negocio son contrarias al usuario. Monetizar una feature que antes era gratis puede molestar al usuario a corto plazo pero permite que la empresa siga invirtiendo en el producto. El arte es encontrar cómo monetizar de una manera que el usuario perciba como justa.
>
Mi posición default: si hay que elegir entre métricas de corto plazo y satisfacción del usuario a largo plazo, elijo lo segundo. Y lo argumento con datos de churn, referidos y LTV.
Pregunta 30: ¿Cómo aprendiste lo que sabés de producto?
Por qué la preguntan:
No tanto para saber tu historia — sino para entender si seguís aprendiendo y si tenés curiosidad genuina.
Elementos que muestran un buen perfil:
- Mencionás fuentes concretas, no genéricas ("leo newsletters de producto" sin saber cuáles es rojo)
- Mostrás que aprendés de tus propios errores, no solo de teoría
- Hacés algo activo para aprender, no solo consumir contenido pasivamente (side projects, análisis de productos, contribuciones a comunidades)
Preguntas adicionales con estructura de respuesta
Pregunta 31: ¿Cómo medirías el éxito de las notificaciones push?
Métricas primarias: CTR (click-through rate) por notificación, opt-out rate después de recibir una notificación, conversión a la acción deseada (no solo el clic).
>
La métrica que suele ignorarse: el impacto de las notificaciones en la sesión siguiente. Una buena notificación no solo trae al usuario en ese momento — crea un hábito que aumenta las sesiones espontáneas también.
>
Guardrail crítica: opt-out rate acumulado. Si el 30% de los usuarios con notificaciones activas las desactiva en las primeras 2 semanas, hay un problema de frecuencia o relevancia — no de copy.
Pregunta 32: ¿Qué harías si dos features del backlog tienen exactamente el mismo RICE score?
Primero, verifico los supuestos de cada una. Dos features con RICE idéntico casi siempre tienen diferencias en los inputs que no fueron bien estimados.
>
Si tras la revisión siguen empatadas, uso criterios secundarios:
- ¿Cuál genera más aprendizaje? (La que nos enseña más sobre el usuario, especialmente si es early en la vida del producto)
- ¿Cuál tiene menor riesgo de ejecución?
- ¿Cuál tiene más dependencias futuras? (Si para construir la Feature C en Q3 necesito la Feature A, construyo A aunque tenga el mismo score)
>
Si después de todo esto siguen empatadas, lo decido yo como PM y lo documento. La parálisis de decisión es peor que cualquier criterio razonable.
Pregunta 33: Describí cómo presentarías una propuesta de roadmap al board
El board no quiere saber qué features vas a construir — quiere saber cómo el roadmap mueve los números del negocio.
>
Estructura de una presentación de roadmap al board:
>
1. Contexto de mercado (2 minutos): ¿Qué está pasando en el mercado que hace urgente este roadmap?
2. Estado actual del producto (3 minutos): Las 2-3 métricas más importantes y cómo están. Sin adornos.
3. La apuesta del trimestre (5 minutos): Un objetivo de negocio principal, con la hipótesis de cómo el roadmap lo va a lograr
4. Las iniciativas (5 minutos): No más de 3-5 iniciativas, cada una conectada al objetivo del punto anterior
5. Los riesgos (2 minutos): Qué podría salir mal y cómo lo vamos a mitigar
6. Lo que necesitamos de ellos (1 minuto): Si necesitás decisiones o recursos del board, pedílos explícitamente
Pregunta 34: ¿Cómo sabés si un usuario llegó al "aha moment" de tu producto?
El "aha moment" es el instante en que el usuario entiende el valor central del producto. Encontrarlo es un ejercicio de análisis de cohortes.
>
Proceso:
>
```python
# Pseudocódigo para encontrar el aha moment
# Comparar comportamiento de usuarios retenidos vs churned en los primeros N días
>
retained_users = df[df['retention_30d'] == True]
churned_users = df[df['retention_30d'] == False]
>
# ¿Qué eventos hicieron los retenidos que los churned no hicieron?
for event in all_events:
retained_rate = retained_users[event].mean()
churned_rate = churned_users[event].mean()
lift = retained_rate / churned_rate
print(f"{event}: {lift:.2f}x más frecuente en retenidos")
>
# El evento con mayor lift en los primeros 3 días es candidato a aha moment
```
>
Una vez identificado el evento (ej: "el usuario creó su primer proyecto", "completó su primera sesión de práctica"), el objetivo del onboarding es llevar a todos los usuarios a ese evento lo antes posible.
>
Validación cualitativa: entrevistá a 10 usuarios retenidos y preguntales "¿cuándo sentiste que la app te estaba siendo útil realmente?" Las respuestas deberían converger.
Pregunta 35: ¿Qué preguntas tenés para nosotros?
Por qué importa: Los entrevistadores juzgan la calidad de tus preguntas tanto como tus respuestas.
Preguntas que demuestran pensamiento estratégico:
- "¿Cuál es la principal razón por la que los usuarios se van actualmente?"
- "¿Cuál es el debate estratégico más importante que tiene el equipo de producto hoy?"
- "¿Qué tendría que pasar en los primeros 6 meses para que este hire sea un éxito rotundo?"
- "¿Cuál fue la decisión de producto más difícil que tomaron el año pasado y por qué?"
- "¿Dónde está la mayor fricción entre producto e ingeniería actualmente?"
Preguntas que no hacés:
- "¿Qué beneficios tienen?" (hasta que no tengas la oferta)
- "¿Cómo es el horario?" (misma razón)
- Preguntas que están en el sitio web de la empresa (muestra que no investigaste)
Errores más frecuentes en entrevistas de PM
Error 1: Ir directo a la solución. Las mejores respuestas empiezan por el problema. Si te piden que mejores un producto, la primera pregunta es "¿qué problema del usuario queremos resolver?"
Error 2: Frameworks sin aplicación. Nombrar RICE, AARRR y Jobs-to-be-done sin aplicarlos al caso que te dieron suena a que aprendiste los conceptos de memoria.
Error 3: No definir métricas de éxito. Toda propuesta de diseño de producto debe terminar con "¿cómo sabemos si funcionó?" Si no definís métricas, el entrevistador asume que no sabés cómo medir.
Error 4: Ignorar las trade-offs. Toda decisión de producto tiene costos. Si proponés una solución sin mencionar qué se sacrifica, suena naif.
Error 5: No clarificar el contexto. "¿Para qué segmento?" "¿En qué etapa está el producto?" "¿Cuál es el objetivo principal?" Son preguntas obligatorias antes de responder cualquier pregunta de diseño o métricas.
Cómo practicar estas preguntas
La diferencia entre saber la teoría y performar bien en la entrevista es práctica deliberada. Algunas formas concretas:
1. Mock interviews: Practicá con alguien que te dé feedback real. Leer las respuestas no activa el mismo proceso cognitivo que tener que articularlo en voz alta bajo presión.
2. Análisis de productos reales: Elegí un producto que uses todos los días y hacé el ejercicio completo: ¿cuál es la North Star? ¿Qué features priorizarías? ¿Cómo medirías el éxito? Escribilo como si fuera una respuesta de entrevista.
3. Grabate: Respondé en voz alta y escuchate. Los tics verbales, las pausas largas y el pensamiento circular son invisibles cuando pensamos pero muy visibles cuando escuchamos la grabación.
4. Practicá la estructura primero: Antes de practicar respuestas completas, practicá solo el inicio de cada tipo de pregunta. El primer minuto es el más importante — si arrancás bien estructurado, el resto fluye mejor.
InterviewHack.ai tiene práctica de entrevistas de producto con feedback en tiempo real — podés simular estas mismas preguntas con un entrevistador de IA que te dice exactamente qué faltó en tu respuesta y cómo mejorar antes de la entrevista real.