Scorecard de entrevista para Product Manager
Un scorecard estructurado para entrevistar a un Product Manager: seis competencias con pesos, qué es realmente un 1 y qué es un 5, y preguntas que sacan evidencia en vez de opiniones. Imprimilo o copialo a tu ATS.
El scorecard para Product Manager
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Definición del problema y evidencia de usuarios Si las decisiones de producto se apoyan en evidencia concreta de usuarios y no en opinión interna, y si distingue un pedido explícito del problema que hay detrás. | 20% | Describe a los usuarios por segmentos genéricos y no cita otra fuente que pedidos internos; al insistir sobre el problema original, repite la funcionalidad que le pidieron. | Nombra los clientes o el corte de datos detrás de una decisión, cita qué dijeron o hicieron, y explica en qué se diferenciaba el pedido del problema que terminó atacando. |
| Priorización y razonamiento de trade-offs Cómo decide qué no construir, si los criterios son explícitos y si puede defender un recorte frente al equipo que pedía ese trabajo. | 20% | Enumera lo que se lanzó el año pasado pero no explica qué se dejó afuera para lograrlo ni quién lo decidió; ordena el trabajo por la jerarquía de quien lo pide. | Recorre un trimestre concreto, nombra lo que quedó afuera y con qué criterio, y describe la conversación con la persona cuyo pedido perdió. |
| Métricas de resultado e instrumentación Si define el éxito antes de lanzar, instrumenta el release y sabe qué pasó con los números después, en lugar de reportar solamente qué se lanzó. | 18% | Reporta fechas de lanzamiento y volumen entregado como resultados; al preguntarle qué cambió para el usuario, cita instalaciones o visitas sin una línea base contra la cual comparar. | Indica la métrica elegida antes del lanzamiento, la línea base desde la que se movió y la contra-métrica que vigiló para detectar daño en otra parte del funnel. |
| Discovery y validación Si prueba los supuestos riesgosos de forma barata antes de comprometer tiempo de ingeniería, y si tiene un caso donde esa prueba cambió el plan. | 15% | Describe el discovery como escribir un spec y revisarlo con stakeholders; toda idea validada se construyó y no aparece ningún ejemplo de un plan abandonado. | Describe un prototipo, una fake door o un piloto manual previo al build, explicita el supuesto que estaba probando y qué lo obligó a cambiar el resultado. |
| Influencia sin autoridad formal Si ingeniería y diseño lo siguen por sus argumentos y por el contexto que comparte, y no por presión de fecha o por escalar a un manager. | 15% | Explica la alineación como coordinar reuniones y mandar updates; cuando ingeniería no estuvo de acuerdo, la salida fue una decisión bajada por un director. | Relata un desacuerdo con un tech lead, la restricción que este planteó y cómo cambió el alcance después, con el lead igual respaldando el release. |
| Comunicación escrita y narrativa de producto Si puede comprimir un problema desordenado en un documento que un stakeholder lee una vez y acciona, sin necesitar una reunión para descifrarlo. | 12% | Sus documentos son listas de funcionalidades y criterios de aceptación; el problema, las opciones evaluadas y el motivo de la elección faltan o se escriben después de decidir. | Puede señalar un documento que nombraba el problema, las opciones descartadas y los riesgos abiertos, y describe qué decisión concreta destrabó. |
Los pesos suman 100. Acordalos antes de la primera entrevista, no después: ajustar pesos cuando ya hay puntajes es la forma en que un panel justifica a su favorito.
Preguntas que sacan evidencia
Cada una pide algo que ya pasó, con suficiente detalle como para verificarlo. Las hipotéticas premian el ensayo, no la trayectoria.
- Contame de una funcionalidad que diste de baja después de lanzarla. Qué evidencia te llevó a esa decisión, quién estuvo en contra y qué hiciste con el equipo que la había construido.
- Recorreme el último roadmap que tuviste a cargo. Qué había a principio de año que seis meses después ya no estaba, y qué provocó cada una de esas bajas.
- Describí una decisión que tomaste en contra del stakeholder más insistente. Qué tenías vos que esa persona no tenía, y qué pasó con esa relación después.
- Elegí un lanzamiento donde la métrica que definiste no se movió. Cuál era la línea base, qué te mostró la instrumentación y qué se lanzó después.
- Contame de algo que lanzaste más chico que el alcance original. Quién decidió qué recortar, qué quedó afuera y qué perdieron los usuarios por eso.
Señales de alarma
- Describe todos sus productos anteriores como exitosos; ningún lanzamiento aparece como flojo, demorado o revertido.
- Habla siempre en plural y, al preguntarle de forma directa, no logra separar sus decisiones de las del equipo.
- Justifica un ítem del roadmap por paridad de funcionalidades con otros productos, sin un problema de usuario detrás.
- No puede nombrar una sola métrica que se haya movido, o nombra una sin línea base ni período.
Cómo usar este scorecard
- Acordá los pesos con el panel antes de que alguien entreviste, y dejalos por escrito.
- Cada entrevistador puntúa todas las competencias por separado, con una nota que cite lo que el candidato dijo textualmente.
- Comparen los puntajes antes de discutirlos. Discutir primero ancla al panel en quien habla más fuerte.
Armar un scorecard a medida → · Cadena booleana para buscar Product Manager →
Preguntas frecuentes
¿Qué debe incluir un scorecard de entrevista para un Product Manager?
Entre seis y ocho competencias ponderadas según lo que el rol realmente necesita, cada una con anchors observables para una respuesta débil y una fuerte. El peso importa: un rol centrado en discovery y uno centrado en delivery no deberían tener la misma distribución. Cada puntaje tiene que apoyarse en algo que el candidato dijo, no en una impresión general.
¿Cómo se distingue a un Product Manager de un Jefe de Proyecto en una entrevista?
Preguntá qué decidió no construir y por qué. Un Product Manager responde con evidencia de usuarios y trade-offs; un Jefe de Proyecto suele responder con cronograma y dependencias. Las dos respuestas pueden ser buenas, pero señalan roles distintos.
¿Cuántos entrevistadores deberían puntuar a un Product Manager?
Tres o cuatro suele alcanzar, siempre que cada uno cubra competencias distintas en lugar de repetir el mismo terreno. Conviene que puntúen por separado antes del debrief, para que la primera opinión no ancle al resto. Puntuar cada competencia contra los mismos anchors, citando las palabras del candidato como evidencia, convierte el debrief en una comparación de registros y no de impresiones.
Cuando lo que está en juego es una contratación real, usá evidencia
Estas herramientas son heurísticas rápidas. Verdict lee el CV contra tu descripción de puesto y puntúa seis dimensiones con citas textuales como evidencia — un documento de contratación que podés defender.