La caza del unicornio

Cómo montar tu proceso para contratar Product Managers

Existen un montón de recursos destinados a como pasar las entrevistas de Product Manager en una Big Tech. De hecho, algunos Youtubers están haciendo un buen dinero vendiendo formaciones y cursos sobre este tema. Ahora bien, ¿cómo se contrata un PM? Muchas empresas se ven con este problema en el momento en el que su organización empieza a necesitar profesionalizar este rol y desde luego que no es un problema fácil de resolver.

En este Desde el barro, os voy a compartir lo que he aprendido después de 10 años entrevistando y siendo entrevistado para posiciones de product manager, incluyendo muchos de los errores que he cometido al diseñar procesos de entrevistas.

¿Qué tipo de Product Manager se necesita?

El primer paso es saber lo que quieres fichar. El dominio y el negocio se aprenden en un periodo de tiempo razonable, sin embargo las capacidades de un buen product manager tardan años en adquirirse y no se aprenden en 6 meses o un año. Salvo que tengas claro qué fichas un perfil junior al que le vas a dedicar tiempo suficiente y un programa de formación bien diseñado como hace Google con su Associate Product Management Program, no fiches perfiles sin experiencia previa en product management si no quieres que tu equipo termine dejando de hacer producto y se convierta en una mezcla rara entre gestión ágil de proyectos y negocio.

El proceso de entrevistas

Una vez tenemos claro qué tipo de profesional debemos fichar veamos cómo articular el proceso de entrevistas y qué aspectos debemos tener en cuenta a la hora de seleccionar al candidato perfecto.

No mandes deberes

Las entrevistas suelen articularse en dos fases, una fase de llamadas telefónicas para filtrar candidatos y una fase presencial para conocerlos en profundidad. Algo importante que he aprendido con el tiempo es que es una mala idea mandar ejercicios para casa, son de poca utilidad ya que son muy dependientes del tiempo que el candidato le quiera o pueda dedicar. Yo como candidato siempre que me han pedido un ejercicio he pasado de hacerlo y como entrevistador he podido comprobar que si tu candidato circunstancialmente tiene conocimientos previos del dominio lo hará mejor, lo que supone un sesgo que va justo en dirección contraria de anteponer el conocimiento en product management por encima del conocimiento del dominio.

Problem Solving 

Uno de los clásicos en estos procesos son las entrevistas de resolución de problemas o problem solving, las cuales, desde mi punto de vista, tampoco sirven de mucho. Hay gente que se pone nerviosa, y a otras personas directamente se les da mal pensar rápido. Por otro lado, ser bueno haciendo este tipo de pruebas no implica que vaya a hacer bien su trabajo. Si ya las pruebas de CI generan muchas dudas, un ejercicio diseñado para exprimir el cerebro de alguien solo sirve para hacer pasar un mal rato a la mayoría de la gente y que los entrevistadores alimenten su ego poniendo al candidato en una situación de inferioridad, lo cual es una de las cosas más importantes que se deben evitar si de verdad quieres conocer bien a una persona. Así pues yo destacaría los siguientes puntos:

• No a los brain teaser.

• Haz que el candidato se sienta cómodo.

• Pregúntale por algo de lo que el candidato sepa mucho, no por algo de lo que tu sabes mucho. 

Aún recuerdo mi entrevista para entrar a Tuenti con Iván Izaguirre, Engineering Manager en aquel momento de la ya difunta red social, donde me pidió que hablara de aquello de lo que más sabía. Si el candidato sabe mucho de una cosa y te muestra sus procesos de pensamiento vas a entender cómo piensa esa persona y si será capaz de resolver los problemas que le vayan surgiendo en el día a día de la empresa. Si hablándote de lo que más sabe no eres capaz de entender cómo piensa esa persona mejor dejala pasar. Esta es sin duda la mejor forma de entender cómo piensa alguien sin ponerle en una situación comprometida y evitando cualquier sesgo.

La analítica y los datos

La analítica no puede faltar en una entrevista para PM pero de nuevo esto no se debe convertir en un examen. Analizar datos sin conocimiento suficiente del contexto es lo mismo que tirar un dado, lo mismo sale el número que quieres y lo mismo no. Por este motivo no tiene sentido poner problemas de analítica sino más bien tener una conversación sobre cómo afronta el candidato el análisis de datos. La mejor forma de hacer esto es que el candidato te cuente un análisis de datos que haya hecho en el pasado y no ponerle un problema que te hayas descargado de Internet o que esté sacado de algún análisis interno simplificado. Pregunta a tu candidato por alguno de los últimos análisis que haya hecho y discute sobre la solución. Así, de nuevo, se evita poner al candidato en inferioridad de condiciones y el entrevistador consigue que el candidato esté cómodo y sea lo más transparente posible, empatizando con él y haciendo el entrevistador el esfuerzo de entender el contexto del candidato y no al revés.

En cuanto a la discusión de si un candidato a product manager debe o no saber SQL la respuesta es clara. Si, tiene que saber SQL, para mi un PM que no sabe SQL es una de las red flags más importantes ya que es alguien que ha mantenido pocas conversaciones con los datos, como a mi me gusta llamarlo y eso siempre es mala señal. De nuevo, no le pongamos un examen de SQL, sino que te explique, aunque sea en una pizarra como ha resuelto en el pasado alguna query especialmente compleja.

La sensibilidad de producto

Otra de las áreas que se suelen evaluar es el famoso Product Sense o sensibilidad de producto. Para evaluar esta parte mi favorito siempre ha sido preguntar al candidato cuál es su producto favorito, o el que más usa y que me diga los motivos por los cuales lo usa y cómo se podría mejorar. Con esa conversación sacas oro sobre cómo entiende el candidato un producto ya que si no es capaz de desarrollar un discurso desde la perspectiva de producto a partir de un producto que el candidato usa habitualmente teniendo en cuenta aspectos de usabilidad y sobretodo de los problemas que resuelve ese producto, difícilmente podrá aplicar esa sensibilidad de producto a los productos sobre los que trabajará en su día a día. Desde mi experiencia no hay mejor forma de que no se te cuelen project managers en roles de producto.

Conocimientos técnicos

Una de las grandes incógnitas es la entrevista técnica ¿es necesaria?. En mi opinión es MUY necesaria. Es un error fichar a PMs sin conocimientos técnicos, ya que pueden ser grandes profesionales en otras áreas pero sin los conocimientos suficientes para poder mantener una conversación con un equipo de desarrolladores en igualdad de condiciones va a ser muy complicado que haga su trabajo de manera competente. Un buen PM debe tener bases de programación, saber que es un API, que es REST, saber como funciona una arquitectura cliente servidor, conocer los principios de las bases de datos y estar familiarizado con buenas prácticas de programación y con metodologías de desarrollo de software como XP programming, TDD o DDD. Sin estos conocimientos la relación con el equipo de desarrollo será más parecida a la que tiene un stakeholder que un product manager que de verdad trabaja de la mano del equipo. Por supuesto esta entrevista la debería hacer un Tech Lead o similar para entender también cómo interacciona el candidato con perfiles técnicos. De nuevo, huye de los exámenes y centrate en situaciones que haya vivido el candidato en el pasado para ver de qué manera ha estado expuesto a estos problemas.

Al final todo gira en torno a predecir comportamientos

Con esto llevamos ya unas cuantas áreas que se deben evaluar a la hora de contratar a un product manager que pase el periodo de prueba o mejor aún que no desvirtúe la cultura de producto de la compañía, pero sin duda la parte más importante es aquella relacionada con soft-skill o behavioral ya que esta debería estar presente en todas las entrevistas. 

Desde mi punto de vista, esta es para mi la parte más importante a la hora de diseñar un proceso de entrevistas para product managers, ya que todas las compañías tienen un marco cultural y organizativo al que es necesario adaptarse. Unas lo tienen de forma muy explícita como por ejemplo Amazon con los Leadership Principles o Mercadona con su modelo de Calidad Total y otras de manera más implícita, pero siempre está ahí y constituye las bases de cómo se articula el trabajo en una compañía. La capacidad de un candidato para adaptarse a la forma de trabajar de una compañía es el principal factor que va a separar a un hiring exitoso de uno que termine fracasando.

La mejor forma de evaluar esta parte es basarse en situaciones pasadas del candidato para entender cómo se comporta ante una situación dada y si ese comportamiento se ajusta a la forma de comportarse que esperamos de ese candidato en el futuro. El método STAR (Situación, Tarea, Acción y Resultado) utilizado por ejemplo en las entrevistas en Amazon, es una excelente forma de estructurar la conversación para tener claridad, durante el tiempo de duración de la entrevista, sobre cómo se comporta el candidato en una situación dada.

Estructurar las entrevistas desde una perspectiva basada en comportamiento y análisis de situaciones pasadas permite evaluar todos los puntos vistos anteriormente en este texto y además aporta una validación constante sobre el encaje cultural del candidato con la compañía.

De todas formas, y más allá de los esquemas culturales de cada empresa cuando hablamos de Product Managers existen tres valores que son los más importantes y para mencionarlos citaré a mi amigo Luis Cappa, Senior Software Development Manager en Amazon, para quien los valores más importante cuando haces producto son:

• Obsesión por el cliente (o el Jefe como lo llamamos en Mercadona). Customer Obsession en términos de Amazon

• Ownership, lo que implica no decir jamás “este no es mi trabajo”

• Delivery Results, lo que implica hacer entrega siempre de resultados que aporten valor al negocio a través de la resolución de los problemas de los usuarios, o al menos intentarlo.

Si un candidato a product manager cumple estos tres valores difícilmente tendrá problemas para encajar en la cultura de cualquier compañía de producto y esto solo es posible evaluarlo añadiendo un fuerte sesgo hacia el análisis del comportamiento en los procesos de entrevistas.

Conclusiones 

Contratar buenos candidatos es muy difícil, y ningún proceso de contratación nos garantiza acertar. Además, cuando fichamos product managers la cosa se complica, ya que las habilidades más importantes a tener en cuenta son a su vez las más difíciles de evaluar pues ningún proceso de entrevistas es capaz de replicar el comportamiento de una persona, pero sin duda un proceso como el descrito aquí te puede ayudar a disminuir la probabilidad de fichar al candidato equivocado.