Desarrollo Impulsado por las Personas (con Sam Higham de Glean)

Michael Luchen

Como gestores de producto en activo o aspirantes, estamos constantemente bombardeados con certificaciones y formaciones especializadas que nos dicen que son esenciales para nuestro oficio. Se nos dice que seguir un proceso personalizado para construir productos es la clave del éxito. Sigue escuchando porque hoy vamos a profundizar en este espacio. ¿Son tan necesarias las certificaciones y los procesos adaptados como parecen? ¿O hay algo mejor?

Este es el pódcast de The CPO Club, las voces de una comunidad que está escribiendo el manual de gestión, desarrollo y estrategia de producto. Contamos con el patrocinio de Crema, una agencia digital de productos que ayuda a individuos y empresas a prosperar gracias a la creatividad, la tecnología y la cultura. Obtén más información en crema.us. Continúa escuchando para recibir ideas prácticas y auténticas que te ayuden a triunfar en el mundo de la gestión de productos.

El tema de hoy es algo que me toca muy de cerca y a la gestión de productos también. Y tengo el privilegio de dar la bienvenida a Sam Higham al programa para hablar sobre ello. Sam es un líder de producto enfocado en el usuario con una trayectoria demostrada en transformar productos, procesos y personas para mejor. Se desenvuelve tanto en los detalles como en los aspectos estratégicos de hacer funcionar los productos, desde sus raíces funcionales hasta las expectativas comerciales que entregan.

Sam posee un interés ilimitado en la forma en que la tecnología y la psicología interactúan en los recorridos de los consumidores, apoyando a equipos para identificar maneras de fusionar y perfeccionar ambas para lograr los mejores resultados posibles. Sam es VP de Producto en Glean, una solución de toma de apuntes para el aprendizaje y la productividad.

La solución de Glean graba notas de audio para que puedas captar y aprender información de manera más efectiva. Sam también ejerce a tiempo parcial como coach de producto y formador de gestión de productos en Mind the Product, donde ayuda a guiar a personas a través de la carrera de gestión de producto que desean.

¡Hola, Sam! Bienvenido al programa.

Sam Higham

Hola, gracias por invitarme.

Michael Luchen

Me alegra tenerte aquí. Así que, para empezar, ¿puedes contarnos cómo llegaste hasta donde estás hoy?

Sam Higham

Claro. Supongo que, en resumen, a base de muchos ensayos y errores. Creo que, como muchos de los que trabajamos en producto, llegué a la gestión de producto casi por casualidad en los últimos diez años o así.

Creo que he desempeñado casi todos los roles que podrías tener en el desarrollo de producto, excepto programar. E incluso así, intenté crear algunas APIs bastante malas en el pasado. Así que sí, diría que empecé formalmente a trabajar en el centro de gestión de productos hace unos ocho años, aunque no necesariamente con ese título.

Y durante ese periodo de tiempo, constantemente intenté perfeccionar lo que significa ser una persona de producto y cómo mejorar día a día. Y creo que mucho de eso fue por intentar averiguar qué es realmente la gestión de producto. Y es una pregunta que todavía me hago cada día, siendo honesto.

Michael Luchen

Sí, ¿qué es? Sí, es una pregunta bastante grande.

Sam Higham

Sí. Creo que para mí se reduce a tratar de encontrar la mejor forma de crear valor dada el contexto en el que te encuentres. Dadas las restricciones que tienes y las personas con las que trabajas. Pienso que mucho del enfoque “purista” de la gestión de producto es fantástico, pero no necesariamente tiene en cuenta las circunstancias de, ya sabes, el 95% de las organizaciones que no tienen todo lo necesario para hacerlo como dicta el libro.

Creo que ahí es donde surgen algunos de los retos. Hay mucha información aspiracional que dice: “Así es como podrías desarrollar producto en un laboratorio perfecto”, pero ninguno trabajamos realmente en esas condiciones. Y casi ninguno tiene la financiación necesaria para aplicar todas esas prácticas de principio a fin perfectamente y que así funcionen.

Mucho de esto tiene que ver con el desarrollo iterativo, sí. No solo en el sentido de software, sino también del proceso y de la colaboración. Todo es trabajar continuamente de adelante a atrás.

Michael Luchen

Interesante. De lo que estás hablando es que mucha de la documentación, digamos, la educación acerca de gestión de producto está enfocada en decir: “Sé iterativo en el desarrollo”. Pero también dices que hay que ser iterativo en el proceso y las personas, según el entorno en el que trabajes.

Sam Higham

Exactamente. Muchas veces se olvida que, como humanos, somos bastante desordenados.

No somos esos individuos paquetes perfectos que pueden seguir todo al pie de la letra. Y no todos compartimos el mismo conocimiento, así que creo que cuando intentas, como gestor de producto, llegar a ciegas —y a mí me ha pasado. He llegado a un rol y simplemente dije, ok, vamos a practicar gestión de producto, este es el marco que usaremos, y todo funcionará perfecto.

Sin siquiera tener en cuenta si mis compañeros siquiera entienden lo que intentamos lograr aquí. O si ven el valor de este enfoque. ¿Qué tan alineados estamos en ese lenguaje? Creo que si no das ese primer paso para preguntarte, “Bueno, todos los que trabajamos juntos, ¿cómo lo hacemos mejor?”

Tener esa conversación abierta permite aportar experiencias, técnicas que has probado, pero no esperar que funcione solo por sí mismo. Y a veces puede ser engañoso decir “Es que funciona en Google, funciona en Amazon, funciona donde sea”, pero ¿en realidad funcionaría para nosotros?

Michael Luchen

Sí. Sí. Lo realmente fascinante es que cuanto más aprendo sobre el funcionamiento interno de Google o Amazon, en fin, quizá muchos de los relatos que nos decimos son de cuando eran startups y su forma de trabajar.

Pero ahora son grandes empresas con muchos equipos y formas de trabajo distintas, incluso dentro de ellas mismas.

Sam Higham

Totalmente. Es un punto interesante. Mucha gente recuerda sus mejores experiencias en etapa startup porque ahí todos entienden lo que se quiere hacer, y todos tratan de descifrarlo juntos. Hay un lenguaje común y se da la conversación rápidamente sobre qué pueden hacer.

Y no me refiero solo a desarrollo de producto (no solo diseño, producto, ingeniería), hablo de ventas, marketing, operaciones, todos están alineados. Por eso existe un ciclo de retroalimentación muy ajustado en la organización. Creo que el desafío y donde entra el proceso es cuando creces, empiezas a perder eso, porque tienes una manera interna tan desarrollada de comunicarte que reduce la accesibilidad a otras áreas para colaborar, porque tu enfoque está muy avanzado.

Tan lejos de lo que otros entienden, que si no mantienes ese bucle de “aquí está nuestro propósito y la razón del enfoque” pierdes ese ciclo de retroalimentación. Y después ventas deja de interactuar bien con producto, producto deja de interactuar con ingeniería, y cada área habla de lo buena que es, pero no de lo bueno que podría ser el global si trabajan juntos.

Michael Luchen

Suena como mucho trabajo.

Sam Higham

Sí, lo es, totalmente.

Michael Luchen

Sí, y pensaba en los oyentes, muchos probablemente en grandes empresas, no tan startups, ¿cómo los guías para que puedan impulsar el proceso, aunque crean que no hay espacio para ello?

Sam Higham

Creo que hay que empezar, terminar pequeño, como dicen. Muchos fundamentos del manifiesto Ágil siguen siendo válidos. Empieza en pequeño, piensa en el experimento más sencillo que puedas hacer como grupo dentro de tu control. Además de tener claro qué está bajo tu control.

A veces te frustras si intentas cambiar demasiado, demasiado rápido, y nunca lo logras porque simplemente repites, “lo escuché en este podcast, que hay que experimentar y colaborar”, en vez de preguntar “¿qué podríamos probar juntos para ser más efectivos?”. Prueba con un squad, ojalá multifuncional. Vean qué experimentos pueden hacer juntos para ser mejores, luego involucren otras áreas y prueben el enfoque.

Demostrar el método, entender por qué funciona o no, tener esas conversaciones. Es esfuerzo, puede estar lejos del “ideal”. Cuanto más lejos esté, más tiempo llevará, pero lo importante es empezar. El mejor momento es hoy, eso es lo único que puedes controlar.

Michael Luchen

Sí, me encanta enfocarse en empezar pequeño, también lo he visto funcionar, sobre todo con clientes con productos propios. Siempre estamos en entornos que cambian de proceso. Lo que ha sido exitoso es reducir y plantear, “hagamos este experimento de dos semanas”.

No vendes una forma de trabajar de un año, sino pruebas plantando semillas para después plantear otras ideas. ¿Qué pasa con el rol de coaching cotidiano en esto?

Sam Higham

Definitivamente. Para mí el coaching es hacer preguntas más que dar respuestas. Ayudar a encontrar respuestas juntos, preguntando mejor. Eso hago, tanto en equipo como en sesiones de coaching. Pregunto, “¿qué has considerado aquí? ¿Por qué? ¿Qué otras opciones había?”, incitando a que generen el hábito de indagar y cuestionar.

En coaching debes sentirte cómodo con el éxito en la sombra, no en el centro de atención. Debes alegrarte del triunfo ajeno sabiendo que estuviste al margen. No debe saberse que les ayudaste, pues obstaculizaría su autodesarrollo.

Si alguien destaca en una presentación, la victoria debe ser totalmente suya, aunque yo haya ayudado formulando preguntas. Eso es irrelevante.

Michael Luchen

Muy bien dicho. También ocurre al revés: dejar que la gente falle para que aprenda de verdad y esté mejor preparada la próxima vez.

Sam Higham

Sí, a veces tememos fallar y eso supone un reto en algunas culturas organizacionales, donde se señala demasiado el error.

Por ejemplo, por un pequeño error de software, de repente hay correos, ejecutivos muy poderosos preguntando por la solución, diciendo que es un desastre. Eso genera miedo hacia cualquier pequeño error, la gente deja de arriesgarse por no ser señalada. Es como en sesiones de crítica de diseño: si el feedback es demasiado duro, el equipo ya no querrá compartir o mostrarse, y pierdes el poder del aprendizaje y del fallo. Como líder, hay que ser muy consciente y evitar estos comportamientos.

Cuanto más sutiles estos miedos, más dañan la mentalidad positiva de probar y aprender.

Michael Luchen

Totalmente. He notado que los líderes configuran la estructura para fallar de manera segura y aprender de ello, en vez de sólo temer al error y así, no aprender. Eso es muy difícil, porque no queremos que la organización fracase.

Entonces para los líderes, ¿cuál es el valor de permitir que la gente de producto “fracase hacia los resultados”?

Sam Higham

Buena pregunta. Ojalá los resultados sean claros: equipos cómodos, empoderados para compartir experimentos que no hayan dado conclusiones, pero de los que aprenden algo nuevo. Es importante la velocidad: no me refiero a puntos de historia, sino a la capacidad de trabajar con confianza sin miedo a pedir aprobaciones extra o consultar a todos para cada pequeño experimento.

La clave está en acordar niveles de empoderamiento y riesgo. Por ejemplo, si van a hacer un cambio crítico en la base de datos, debe decidirlo el líder. Pero si es por probar un botón con un 10% de usuarios y el peor caso es perder un 0,01% de conversión, el equipo debería decidir y actuar —la mejora iterativa lo compensa.

Michael Luchen

O sea, casi como un acuerdo de trabajo entre el equipo y los líderes.

Sam Higham

Exacto. Incluso se puede afinar a través del coaching, según si el umbral de riesgo es demasiado alto o bajo. Simplemente tener la conversación activa y ajustar.

No tiene por qué ser más complicado.

Michael Luchen

Sí. Hablando de complicado, todo esto es muy complejo y ambiguo, y las perspectivas sobre desarrollo de productos muestran que no hay proceso ni marco único que sirva para todo.

Imagino a una gestora de producto entrando en este mundo: ¿por dónde empiezo? ¿Con el proceso? ¿Hablo con el equipo? ¿con los líderes? ¿Cuál es mi brújula? ¿Cómo navegar?

¿Qué consejo les das?

Sam Higham

Puedo compartir mi camino porque puede que ayude. Personalmente, aprendo en el “último momento responsable”. Significa que cuando empecé, aprendía justo lo que necesitaba hacer en el momento en que tenía que hacerlo.

La primera vez que tuve que presentar, busqué cómo crear roadmaps y qué opciones había. Luego, la segunda vez, pensé “¿Qué aprendí antes?” y busqué priorización del backlog. Así es como aprendo yo. Me saturo si leo mucho y al final olvido si nunca practico.

Si puedes leer 20 libros y usar todo ese conocimiento, genial. Pero yo necesito practicarlo y ver si funciona para mí. Y así lo sigo haciendo hoy con cada cosa nueva.

También vale hacer formación intensiva, mientras no te apegues rígidamente a lo aprendido durante uno o dos días. Eso no garantiza saber aplicarlo, porque la realidad es más compleja y humana de lo que cualquier curso puede plantear.

Michael Luchen

Exacto. Lo he visto en mi propio trayecto y otros colegas. Es mejor aprender haciendo. Hay tantas herramientas y formas de crear un roadmap, por ejemplo, que lo mejor es buscar, probar con tu equipo y ver qué funciona.

Sam Higham

Totalmente. No creo que haya una sola forma correcta de hacer un roadmap. Puede haber mejores, pero no necesariamente funcionarán en tu contexto. Yo podría decirte que hagas un roadmap de ahora, después, más tarde, sin fechas o funcionalidades, solo por resultados. Pero no quiero ser responsable de que tu jefe te grite porque nunca lo vio así y está fuera de sus esquemas.

Así que hay que encontrar el cambio incremental: ¿qué sería lo ideal, qué funciona ahora y cómo puenteas la brecha?

Michael Luchen

Mucho de esto, al tratarse de personas, es pensar en el largo plazo. No solo los resultados del producto o las métricas, sino también en el desarrollo del equipo. ¿Cómo debe tenerlo presente la persona de producto día a día?

Sam Higham

Algunas formas sencillas (bueno, nada es sencillo) son las retrospectivas. Autoevaluarse como equipo es mucho más sano que cifras arbitrarias de un gestor de tickets. Es lo mejor que hay.

He dirigido ejercicios de salud de equipo, donde acuerdan 10 focos y los revisan trimestralmente a ver si han mejorado o no, y cómo cambiarlo.

Un retro normal es sobre el hoy; el de salud del equipo es como una macro retrospectiva sobre grandes temas para ver tendencias.

También hay que tener habilidades blandas: notar cambios en el comportamiento del equipo, menos interacción, menor discusión sobre la visión… debes pensar “¿qué pasó aquí?” y preguntarles. A veces uno supone y no indaga; en vez de eso, hay que preguntar.

Puede que alguien haya recibido un feedback duro, tenga problemas, esté bajo presión… Somos humanos, comunicarnos es esencial. Así sobrevivimos y formamos comunidades. Para mí, un equipo de producto es una comunidad pequeña y, a mayor escala, en la organización.

Michael Luchen

Eso está genial.

Un equipo de producto es una pequeña comunidad. Realmente impactante. Y como toda esta charla, gira en torno a las personas. ¿Y si el gestor quiere proponer retros o ejercicios de salud, pero la dirección lo ve como pérdida de tiempo? ¿Cómo gestionarlo?

Porque sabemos que no lo es. ¿Cómo afrontarlo?

Sam Higham

Es cuestión de hacerlo en abierto: ¿por qué queremos esto? ¿Qué indicadores demostrarán éxito o no?

En temas de salud del equipo, puedes medir la retención, incluso la felicidad autopercibida, hay muchas herramientas para eso. Puedes ver el desempeño, los desafíos; por ejemplo, si el trabajo se bloquea porque no contactamos con otros departamentos a tiempo, el experimento es involucrarlos desde el inicio en la planificación y en las demos, para evitar esos bloqueos de última hora.

En general, comunicar todo abiertamente es sano. Otra forma es preguntar a la dirección qué les gustaría ver o cómo medirlo, y abrir el diálogo.

Puede ser que pidan aumentar la velocidad y puntos de historia y, si es así, tal vez debas “salir corriendo”. Pero si hay confianza, puedes acercarles al problema y, a través de preguntas, entender qué temen o qué desean evitar que pase, y así calmar su ansiedad con argumentos claros.

Michael Luchen

Exacto. Es muy interesante eso del “coaching hacia arriba”: preguntar, abrir diálogo. Incluso si piden medir velocidad, ver el porqué. Muchas veces se debe solo a un malentendido y, aclarando, logras diálogo. Si aún así insisten, pues ahí sí sería momento de replantear.

Debemos recordar que como product managers somos generalistas de muchos procesos y herramientas, pero no podemos asumir que todos los stakeholders las conocen igual.

Sam Higham

Por supuesto. Esa diferencia de lenguaje y entendimiento es enorme, hasta en el término “product-led”. Pueden pensar que significa dar todo el poder al área de producto, y ahí surgen rivalidades. Por eso el lenguaje es poderoso; si no aclaras los términos, cada uno interpreta lo suyo y aparecen los malentendidos.

Personalmente, soy muy consciente de qué términos uso y si todos los entienden, o si debo simplificarlos. Hay que hacerlo explícito, porque la gente prefiere callar antes que admitir que no entendió un término en una reunión.

Michael Luchen

Sí, debemos asumir el rol de guía paciente con todos.

Sam Higham

Sí.

Michael Luchen

Una última pregunta antes de cerrar. Estás en un rol prestigioso, tienes una gran carrera, y enseñas/coacheas. Así que tienes mucho conocimiento del sector. ¿A dónde ves que va la gestión de productos para tener éxito en los próximos, digamos, tres años?

Sam Higham

Creo que empezará a fragmentarse en más especializaciones. La gestión de productos empezó siendo muy general y significa cosas muy distintas para diferentes personas. En el futuro, se segmentará más, como en ingeniería de software, donde hay múltiples especializaciones.

Puedes ser especialista en crecimiento, B2B, B2C; se usan esos términos, pero aún no se ha traducido en perfiles especialistas reconocidos. Pero la educación y contenido ya apunta hacia ahí, y lo veremos formalizado porque la comunidad es muy amplia y lo natural es especializarse.

Michael Luchen

Genial.

Antes de concluir, me gustaría hacerte unas preguntas rápidas personales. ¿Cuál de tus hábitos personales más ha contribuido a tu éxito?

Sam Higham

La resiliencia. Mucho de lo que hablamos hoy es sobre el fracaso. A veces la gente no acepta bien los errores y el entorno no es seguro, así que eso es clave. La adaptabilidad también, porque aprendo adaptándome constantemente. Y la humildad: confieso abiertamente que no sé ni la mitad de lo que necesito saber y dependo mucho de personas brillantes para salir adelante. Nunca pretendo ser el experto en todo, porque no es cierto y probablemente nunca lo será.

Michael Luchen

Me identifico con esos valores.

¿Cuál es tu herramienta favorita que usas regularmente?

Sam Higham

Miro o Myra, no recuerdo cómo se pronuncia. Es la más flexible. No sabría vivir sin ella.

La uso todo el día, todos los días, para todo. En mi antigua compañía, la usamos para lanzar un negocio de mil millones en seis meses, solo con Miro, nada más. Es impresionantemente útil. Uso la herramienta para todo mi contenido. Es excelente.

Michael Luchen

Sí, lo confirmo. Mi equipo y yo la adoptamos cuando aún era “real-time board”, y rápidamente se convirtió en la herramienta más usada en la empresa, muy valiosa.

Por último, ¿qué consejo le das a alguien que empieza su camino en producto?

Sam Higham

Pide ayuda. Como persona de producto parece que tienes que saber de todo, pero cuesta mucho pedir ayuda cuando no sabes algo. Ya sea a otros PM, ingenieros, diseñadores o cualquier persona de la organización. Los mejores que conozco en gestión de productos son los que siempre piden ayuda porque saben que así mejoran.

La comunidad de producto en Twitter es genial, mucha gente quiere ayudar a que otros aprendan. Así que sí, pedir ayuda es mi consejo número uno. Pero en realidad, no solo para producto, sino para cualquier ámbito. Punto.

Michael Luchen

Fantástico, totalmente de acuerdo. Incluso si crees saber, pedir ayuda sirve para obtener una segunda opinión.

Bien, Sam, muchas gracias por estar hoy en el programa.

Sam Higham

Gracias a ti por invitarme.

Michael Luchen

Puedes saber más sobre el trabajo de Sam en Twitter o LinkedIn. De nuevo, muchas gracias Sam por unirte. Gracias a todos por escuchar y por dejar vuestra reseña en el pódcast. Por favor, seguidnos y uníos a la comunidad en theproductmanager.com si no lo habéis hecho todavía.

De nuevo, gracias por estar, ¡nos encontramos en el próximo episodio! ¡Cuídense!