Preguntas de entrevista Director de Producto

Empiezo por la estrategia general de la empresa y determino el papel de cada línea de producto: cuáles impulsan el crecimiento, cuáles defienden una base de ingresos existente y cuáles son apuestas que todavía estamos validando. Ese encuadre cambia lo que significa el éxito para cada línea, así que no aplico las mismas expectativas de crecimiento a una línea madura que a otra de dos años. Llevo a cabo un ciclo de planificación estructurado dos veces al año con cada responsable de línea de producto, en el que acordamos una estrategia de una página que cubre el mercado objetivo, la métrica más importante y los compromisos que decidimos explícitamente no asumir. Después contrasto esas estrategias entre sí para detectar conflictos de recursos antes de presentar nada al CEO. En mi anterior empresa, este proceso reveló que dos líneas estaban construyendo en silencio una automatización de flujo de trabajo similar, por lo que consolidamos el esfuerzo en una capacidad de plataforma compartida en lugar de duplicar el gasto de ingeniería, liberando aproximadamente cuatro meses-ingeniero por trimestre.

Dimensiono el equipo en función de la magnitud de los problemas que merece la pena resolver, no de una proporción fija respecto al número de ingenieros, aunque uso esa proporción como verificación de coherencia una vez que el equipo supera cierto tamaño. Agrupo a los product managers en torno a problemas de usuario o de negocio coherentes, no en torno a funcionalidades individuales, porque la propiedad a nivel de funcionalidad se fragmenta demasiado rápido a medida que el producto crece y genera reorganizaciones constantes. Cuando heredé un equipo de nueve product managers organizado por funcionalidades individuales sin un responsable claro por encima, lo reagrupé en tres equipos, cada uno responsable de un recorrido de cliente completo con un product manager líder responsable de los resultados de su equipo, y reportándome directamente a mí. Eso me dio tres personas que podía desarrollar como futuros líderes de producto, en lugar de nueve reportes directos a los que apenas podía acompañar bien. Reviso la estructura aproximadamente una vez al año, ligado al ciclo de planificación estratégica, en lugar de reorganizar de forma reactiva cada vez que aparece una nueva prioridad.

Llevo al consejo un número reducido de elementos en cada ciclo: el avance de las apuestas estratégicas acordadas la vez anterior, las métricas de salud de todo el portafolio de producto, y una petición clara, ya sea presupuesto, una decisión de contratación o un compromiso para el que necesito respaldo visible. Evito detallar al consejo a nivel de funcionalidad, porque no es su nivel de atención y eso oculta la decisión que necesitan tomar. Soy directo sobre lo que no funciona. Cuando un miembro del consejo preguntó por qué una iniciativa importante llevaba seis meses de retraso sobre el plan original, expliqué la decisión de recursos concreta que causó el retraso y qué cambiamos como resultado, en lugar de reformular el retraso como un cambio de alcance después de los hechos. Ese tipo de transparencia es lo que gana la confianza necesaria para que aprueben una inversión importante la próxima vez que la pida.

Empiezo por evaluar cuánto diferencia esa capacidad a nivel comercial, no cuánto interés técnico despierta construirla. Si una capacidad no es un motivo por el que los clientes nos eligen, opto por defecto por comprar o asociarme, salvo que el coste de integración y el riesgo del proveedor a largo plazo superen el coste de construcción, que modelo a tres años y no solo el primer año. Implico pronto a la dirección de ingeniería y a finanzas en esta decisión, porque el coste de construir casi siempre se subestima desde el lado de producto, y el coste real incluye la carga de mantenimiento continua, no solo la estimación del primer sprint. Cuando necesitábamos capacidad de detección de fraude, hice una evaluación estructurada frente a tres proveedores y una estimación de construcción interna, y elegí asociarme a pesar de que un equipo interno quería construirlo, porque el modelo del proveedor estaba entrenado con un conjunto de datos que nunca podríamos replicar internamente, y el coste de cambiar de proveedor si nos equivocábamos era bajo. Dieciocho meses después, esa decisión liberó a todo un equipo para trabajar en una funcionalidad claramente diferenciadora.

Teníamos una línea de producto que había sido la visión original del fundador y aún contaba con un pequeño grupo de defensores internos muy vocales, pero llevaba estancada por debajo del 5 % de los ingresos durante dos años mientras consumía cerca del 20 % de la capacidad de ingeniería. Construí el caso lentamente en lugar de anunciar una decisión: extraje la economía unitaria, entrevisté al puñado de clientes que aún dependían de ella, y modelé lo que esa capacidad de ingeniería podría lograr si se redirigía a nuestras dos líneas de crecimiento. Presenté el análisis al fundador en privado antes de cualquier conversación más amplia, porque quería que escuchara el razonamiento directamente de mí y no a través de un anuncio general. Acordamos detener toda nueva inversión, seguir dando soporte a los clientes existentes hasta el final de sus contratos, y redistribuir el equipo a lo largo de dos trimestres en lugar de de un día para otro. No fue una decisión limpia ni rápida, pero los ingresos de las dos líneas que recibieron la capacidad liberada crecieron un 30 % el año siguiente, y el fundador me dijo más tarde que valoraba que le hubiera presentado el caso antes de que la decisión fuera definitiva, no después.

La dirección comercial quería que nos comprometiéramos con un conjunto de funcionalidades a medida para un gran cliente potencial, argumentando que eso cerraría un contrato que representaba una parte significativa del objetivo del trimestre. Me opuse porque esas funcionalidades no servían a ningún otro segmento de clientes y habrían consumido un trimestre entero de la capacidad de nuestro equipo de plataforma. En lugar de simplemente decir que no, pedí a comercial que me trajera el valor real del contrato y la probabilidad de cierre, y modelé lo que nos costaría decir que sí frente a la hoja de ruta comprometida para el resto de la base de clientes. Acordamos un subconjunto más pequeño de la petición que también tenía una aplicabilidad más amplia, y comercial aceptó un ciclo de venta más largo en esa cuenta en lugar del desarrollo a medida completo. El contrato se cerró cuatro meses más tarde de lo que comercial quería inicialmente, pero las funcionalidades del compromiso se lanzaron a toda la base de clientes y fueron adoptadas por el 40 % de las cuentas en dos trimestres, algo que comercial citó después como ayuda para cerrar otros dos contratos que no había anticipado.

Tenía una product manager analíticamente sólida pero que constantemente tenía dificultades para llevar consigo a ingeniería y diseño; sus especificaciones eran técnicamente correctas, pero tomaba decisiones unilaterales que dejaban a ambos equipos sintiéndose ignorados, y la adopción de sus funcionalidades se resentía como consecuencia. Le di feedback directo y concreto, basado en incidentes reales y no en una impresión general, y acordamos un plan de 90 días con comportamientos concretos a cambiar, incluyendo coescribir las dos siguientes especificaciones con su ingeniero líder en lugar de hacerlo sola. Hice seguimiento cada dos semanas en lugar de esperar al final del plan, porque quería detectar cualquier desviación pronto. Hizo progresos claros en el proceso colaborativo, pero el patrón subyacente de decisiones unilaterales en asuntos de alto riesgo persistió, así que al final de los 90 días decidí moverla a una vía de contribuidora individual en un área de producto más pequeña y de menor riesgo en lugar de seguir liderando un equipo, algo que al principio le costó aceptar pero que después me dijo que había sido la decisión correcta para su carrera.

Trato la capacidad de ingeniería como un único fondo compartido que asigno al portafolio completo, no como equipos fijos que cada responsable de línea de producto pueda reclamar como propios. Cada trimestre llevo a cabo un ejercicio de priorización forzada entre los responsables de línea de producto, en el que cada uno presenta sus principales peticiones con una estimación explícita de las semanas de ingeniería necesarias y el resultado esperado si se financian. Después tomo yo mismo la decisión de asignación en lugar de dejar que recaiga por defecto en quien argumenta más fuerte, porque ese es el verdadero trabajo del puesto. Protejo un porcentaje fijo, normalmente alrededor del 15 %, para trabajo de plataforma y deuda técnica, sea cual sea la presión de producto en un trimestre dado, porque he visto lo que ocurre dos años después cuando eso se despriorriza en cada ciclo. Cuando dos líneas necesitaron el mismo conjunto de habilidades de ingeniería especializadas el año pasado, reuní a ambos responsables y al director de ingeniería en una misma sala para negociar una secuencia escalonada en lugar de que cada uno me presentara un caso aislado, lo que reveló una dependencia que ninguno había señalado por su cuenta.

Mantengo ambos presupuestos visiblemente separados en lugar de dejar que el trabajo de plataforma se absorba silenciosamente en los plazos de las funcionalidades, porque si no se nombra como una partida propia, siempre pierde cuando se aprieta un plazo. Normalmente busco una división aproximada, ajustada según la madurez de cada línea de producto, y presento esa división explícitamente al CEO para que la inversión en plataforma sea una decisión tomada a plena luz y no un valor por defecto que tenga que defender después. Cuando necesitábamos migrar un componente central de infraestructura que consumiría capacidad real sin producir funcionalidades visibles durante dos trimestres, lo planteé al comité ejecutivo no como un lujo técnico sino como una restricción directa a nuestra capacidad de cumplir los compromisos de la hoja de ruta del año siguiente, con una lista concreta de funcionalidades que serían notablemente más lentas o imposibles sin ello. Ese planteamiento consiguió financiación sin resistencia, porque conecté la inversión con resultados comerciales en lugar de pedir a la empresa que confiara únicamente en el criterio de ingeniería.

Sigo un cuadro de mando reducido a nivel de portafolio, junto con las métricas individuales que posee cada equipo: la previsibilidad general de la hoja de ruta, es decir, el porcentaje de iniciativas comprometidas que se lanzaron en el trimestre previsto, la retención de product managers y la tasa de promoción interna, la fricción por dependencias entre equipos recogida mediante una encuesta trimestral con ingeniería y diseño, y la división entre trabajo reactivo y trabajo estratégico en cada equipo. Las métricas de un solo producto pueden parecer saludables mientras la organización subyacente se deteriora, por ejemplo un equipo que cumple sus cifras trabajando a un ritmo insostenible o saltándose la fase de discovery, y el cuadro de mando está diseñado para detectar eso antes de que se traduzca en rotación de personal o en un product manager líder agotado. Cuando la previsibilidad de la hoja de ruta cayó fuertemente durante dos trimestres seguidos, investigué y descubrí que subestimábamos sistemáticamente el trabajo de dependencias entre equipos, lo que me llevó a añadir un paso de mapeo de dependencias a la planificación, que corrigió el patrón en dos ciclos.