Tecnología Informal:
Trabajando con producto

Escuchá el Podcast en Spotify

Episode Transcript

13 - Trabajando con producto - Tecnología Informal Los programadores somos unos vagos. Siempre entender las partes da mejor resultado que ignorarlas. Bienvenidos a Tecnología Informal, un espacio para hablar de carrera, de inversión, de producto, de cultura y de todo lo relacionado con startups. Yo soy Gabriel Benmergui, y soy programador con más de una década de experiencia viviendo y trabajando en California, Estados Unidos. En las empresas de tecnología existe un rol muy deseado. En el episodio de hoy, vamos a hablar en qué consiste este rol, cómo se diferencia de otras posiciones de liderazgo y también en cómo tener una buena relación de trabajo con los product managers. Empecemos con una definición. El product manager, o PM, es una persona encargada de entender las necesidades de los clientes y articular una propuesta de negocios para la organización y ejecutarla. Ya en la definición vemos que dependiendo de los clientes, la empresa y lo que se produce, el rol de producto puede ser muy distinto y por eso los PM tienen perfiles tan variados. No confundir con Project Manager, que es un encargado de organizar y planear tareas. El rol de producto es algo inventado por las startups y es un trabajo más joven aún que los programadores. La personificación máxima de producto es Steve Jobs, alguien sin conocimientos técnicos, pero capaz de formular una idea de punta a punta y mandarla al mercado. ¿Qué hacen los PM? Bueno, la unidad de trabajo del PM es la generación de requerimientos de producto. A veces en un documento llamado PRD, Product Requirements Document. El product manager es una persona encargada de entender las necesidades de los clientes y articular una propuesta de negocios para la organización y ejecutarla. El rol de producto es algo inventado por las startups y la personificación máxima es Steve Jobs, alguien sin conocimientos técnicos, pero capaz de formular una idea de punta a punta y mandarla al mercado. El PM pone objetivos de negocios, analiza el mercado, los riesgos, la gente involucrada en la ejecución del proyecto, estimados de tiempo y más. Para producir esta información, el PM está principalmente hablando con clientes. Pueden ser consumidores finales, otras empresas o hasta personas dentro de la empresa si el producto es interno. Luego tiene que ir generando consensos con todos los que construirían este producto dentro de la empresa. Finalmente, la propuesta en sí se prioriza con otras iniciativas y se elige cómo y cuándo hacer qué cosa. Una vez en producción, producto es responsable parcial de que se haga a tiempo. Aunque no puede controlar a los equipos que lo producen, puede ayudar en la priorización y dirección. Y finalmente, es responsable de todos los resultados. Estrategia, negocios, plata, o simplemente la pasión de armar productos. Por otro lado, es un rol muy bien pago, cobrando apenas por debajo de los programadores en Silicon Valley. Aunque a veces mucho mejor remunerados cuando manejan productos de mucha importancia. Un product manager puede hacer millones de dólares en bonos y beneficios, aún sin ser gerencia, justamente por la escala de su impacto en el producto. Y por último, como este rol es tan dependiente del contexto de negocios y de la empresa, frecuentemente no es necesario ser un ingeniero de software para ser PM, por lo que es una forma muy atractiva de subir tus ingresos si sos de marketing, operaciones u otros roles comúnmente peores pagos. Pero también hay razones por las que este rol es más difícil de lo que parece. El rol de producto, como responsable máximo, cualquier obstáculo que aparezca es responsabilidad tuya, lo que puede incluir mover muebles, limpiar autos, pelearte por teléfono, hacer ventas, cualquier cosa. Hay que arremangarse para cualquier problema que aparezca. Pero tal vez lo más importante es que el rol de PM no es un puesto de autoridad. Los trabajadores de startups ven a una persona que dice qué es lo que hay que hacer, y esperan firmeza y autoridad. Pero toda esa supuesta autoridad se choca con el iceberg del cliente, que si no compra lo que el PM vende, nada funciona. El auténtico jefe del PM es el cliente, y el PM necesita arreglárselas para crear una proposición que sortee los obstáculos técnicos, legales, contables y operacionales para que salga. El PM consulta a todos los expertos de la empresa que, teniendo sus propias prioridades y preocupaciones, contestan con un conjunto de opciones para que el PM las vaya coordinando e ideando un plan de acción. Son un generador de puentes entre las distintas secciones para que interactúen de la mejor manera posible y enfocarlos en agregar valor al producto. Como el PM no es experto en casi ninguna área, aunque suele ser experto en al menos una, está siempre recibiendo restricciones. El PM le puede decir al legal que no sabe de leyes, al técnico que no sabe de sistemas, al de marketing que no conoce a los clientes. Pero sí puede persuadir e intentar empujar a cada experto y responsable a hacer un poquito más, a comprometerse a construir algo nuevo, asumir un riesgo calculado. Esa diferencia entre dar una orden y persuadir es la diferencia entre autoridad e influencia. Hay que arremangarse para cualquier problema que aparezca. El auténtico jefe del PM es el cliente, y el PM necesita arreglárselas para crear una proposición que sortee los obstáculos técnicos, legales, contables y operacionales para que salga. Y el PM es por excelencia un rol de influencia, de soft skills y de relaciones interpersonales. Las relaciones del PM con todos los expertos son ligeramente confrontacionales. El PM quiere hacer más, prometer más, para subir la calidad y el valor del producto, mientras que todos los otros expertos tienen intereses más variados, como reducir el riesgo o los costos operativos. Esto es particularmente pronunciado con los técnicos. Los programadores somos unos vagos. La vara con la que se mide el éxito de un técnico es si hace lo que le dicen que hay que hacer, y que los sistemas que hace no se rompan y anden bien. No hay sistema que ande mejor que el que no existe, así que nuestros incentivos son hacer lo menos posible. Este conflicto de intereses con los técnicos es tan fuerte que es la razón principal por la que una gran parte de los PM son técnicos. Los PMs técnicos pueden entender la minucia y empujar a los programadores a hacer mucho más. Alguien que no sepa de programación va a tener más problemas para evitar un "no se puede hacer" o "no existe esa tecnología". Aun así, el error más común que cometen todos los PM con los técnicos es preguntar si esto se puede hacer o si sería mucho trabajo hacer esto. Es como preguntarle al peluquero si necesitás un corte de pelo, la respuesta la tienen los incentivos. Tip para los PM: es mejor preguntar cuánto tiempo les tomaría construirlo, apelando al orgullo y optimismo de los programadores, que van a crear estimados que uno puede utilizar como argumento después. Los programadores somos unos vagos. El error más común que cometen todos los PM con los técnicos es preguntar si esto se puede hacer o si sería mucho trabajo hacer esto. Es como preguntarle al peluquero si necesitás un corte de pelo, la respuesta la tienen los incentivos. Es mejor preguntar cuánto tiempo les tomaría construirlo, apelando al orgullo y optimismo de los programadores, que van a crear estimados que uno puede utilizar como argumento después. Una especie de darles la soga para que se cuelguen solos. En realidad, el problema general que tienen los PM y los técnicos es que mezclan sus roles, en vez de entenderse entre sí. El PM decide lo que se debe hacer, el técnico lo que se puede hacer. El PM tiene que priorizar todas las opciones existentes para lograr el producto de mayor valor. El técnico tiene que proveer un set de opciones para que el PM elija. El peligro de pasarse del rol es que uno tendría que asumir los riesgos del otro rol. Si uno es técnico y exige un cambio de producto, tendría que hacerse responsable personal si fracasa, lo que pasa rara vez. Y el PM, que exista un producto que no se puede hacer, no va a poder entregarle nada al cliente. En esta relación, el técnico también puede persuadir al PM. Para eso hay que entender los objetivos del PM y puede servir leer sus requerimientos, sus documentos, presentaciones o simplemente hacer muchas preguntas. La manera más exitosa de un técnico para escaparse de hacer algo que no quiere hacer es ofrecer algo mejor para el PM. Nada mejor que escaparse de hacer un sistema complejo de dos meses de trabajo que ofrecer algo del mismo valor, pero que toma dos días. Para sacarle provecho a esta relación adversarial, es muy bueno ser flexible, creativo y empático, para generar nuevas opciones que no se crearían si la relación fuese autoritaria, donde una parte decide unilateralmente todo. Los programadores tenemos un poco de arrogancia, de creer que podemos hacer cualquier cosa, y muchos aspiramos o terminamos haciendo algo de producto, pero generalmente la pasamos mal. Yo tuve varios procesos de trabajar en rol de producto y es auténticamente cruel. La manera más exitosa de un técnico para escaparse de hacer algo que no quiere hacer es ofrecer algo mejor para el PM. Nada mejor que escaparse de hacer un sistema complejo de dos meses de trabajo que ofrecer algo del mismo valor, pero que toma dos días. Los programadores tenemos un poco de arrogancia, de creer que podemos hacer cualquier cosa, y muchos aspiramos o terminamos haciendo algo de producto, pero generalmente la pasamos mal. Yo tuve varios procesos de trabajar en rol de producto y es auténticamente cruel. Creé dos productos, uno con un éxito parcial y otro un fracaso rotundo. En Circle Medical entré como ingeniero y tomé las riendas del producto principal de la empresa, el sistema de registro médico para pacientes. En esa experiencia, asumí rol de producto y de ingeniero a la vez, lo que fue una experiencia brutal. Casi todos los días tenía una entrevista de veinte o treinta minutos con un médico, para anotar pain points, entender al usuario, operaciones y buscar oportunidades para la empresa. Con esa información armaba métricas y dashboards para ver la salud de los sistemas, de la plata, de la felicidad de los empleados. Prioritizaba lo que había que arreglar y ponía propuestas bien documentadas esperando el sign off del CEO o el CTO. Y después me ponía el sombrero de programador y tenía que implementar los caprichos del Gabriel de producto. Fue una tensión constante que, mientras descubría lo que era importante, me daba cuenta del enorme inconveniente que era implementarlo, y tenía que luchar mi propia psiquis para no mezclar los roles. Una de mis historias favoritas es la de un amigo programador que quería tener más mano en el producto. Y para lanzar un feature se tuvo que ir a la página del PAMI a leer términos y condiciones para ver si era legal hacerlo. Qué depresión. De todas maneras, en todas las disciplinas de una startup, entender cómo piensa y trabaja producto es una ventaja importante. Desde el vamos, nada enamora más en una entrevista que poder tener una conversación de producto. ¿De qué depende el éxito de la empresa? ¿Cuáles son los features más importantes que le faltan? ¿Cuáles son los desafíos y cómo se posiciona frente a la empresa? Además, entender cuáles son las partes importantes de una empresa son clave cuando uno elige en qué área trabajar. Para bien o para mal, los premios del éxito siempre están asociados a las unidades de negocio que son importantes para la empresa. Es una forma de darle palanca a tu rol y a tu carrera muy fácilmente. Finalmente, cuando uno es senior en cualquier disciplina de la empresa, quiere también poder influenciar el famoso roadmap. El plan de qué es lo que se va a construir en los próximos tres meses, un año o más, y para identificar oportunidades de hacer impacto. Eso se puede hacer presentando oportunidades y colaborando con producto para priorizar y generar los consensos necesarios para ejecutar el proyecto. Producto es un rol muy malentendido, pero vital para el éxito de las startups. Siempre entender a las partes da mejor resultado que ignorarlas. Ojo con pensar que los PM la tienen fácil. Es un trabajo difícil, con mucho fracaso y es mejor colaborar que tratar de pasarlos por arriba. Si les gustó el podcast de hoy, se vienen muchos más. Suscribite al podcast en Spotify o seguime en Twitter, en @Conanbatt, para estar al tanto de todo el contenido. Hasta la próxima.