Michael Luchen conversa con Sam Higham, vicepresidente de producto en Glean. Escucha mientras profundizan en si seguir un proceso personalizado que nos dicen para construir productos es la clave del éxito. ¿O hay algo mejor?
Momentos Destacados de la Entrevista
- Como muchas personas en producto, Sam llegó a la gestión de productos casi por casualidad en los últimos 10 años. Ha realizado casi todos los roles en el desarrollo de productos excepto programar. Formalmente empezó a trabajar en el área de producto hace unos 8 años. [1:50]
- Para Sam, ser una persona de producto se resume en buscar la mejor forma de crear valor según el contexto donde te encuentras. Tener en cuenta cualquier limitación que tengas y las personas con las que trabajas. [2:39]
- Una de las prácticas de Sam es mantener esa conversación abierta para que la gente pueda aportar sus propias experiencias. Pueden traer técnicas que han probado y funcionado anteriormente e intentar aplicarlas. Pero no esperes que simplemente suceda y funcione. [4:45]
Ser coach, para mí, es asegurarte de que haces más preguntas que dar respuestas.
Sam Higham
- Muchas de las cosas que hace Sam día a día, ya sea trabajando con personas dentro de un equipo o de manera individual en una conversación de coaching, tienen que ver con hacer mejores preguntas. [9:27]
Alégrate cuando otros ganan porque tú has estado apoyándolos desde el banquillo.
Sam Higham
- A veces hay desafíos en las organizaciones donde existe casi una cultura invisible en la que el fracaso se señala demasiado. [11:26]
- Cuando la gente habla de velocidad, se refieren a puntos de historia. Para Sam, significa la capacidad de las personas para trabajar cómodamente, con confianza y rapidez. [13:54]
- Personalmente, Sam aprende las cosas en el último momento posible. Es decir, cuando comenzó en producto, iba aprendiendo lo que tenía que hacer justo en el momento en que le tocaba hacerlo. [16:17]
La autoevaluación como equipo es, para mí, mucho más saludable que algunas métricas arbitrarias que sacas de un sistema de tickets o que son evaluadas por otros.
Sam Higham
- Sam también dirige actividades como evaluar la salud del equipo, retrospectivas o talleres. Una retro normal se enfoca más en el presente, el aquí y ahora. Mientras que la salud del equipo es una retro con un tema más general que puedes usar para tener una visión más amplia de hacia dónde te estás dirigiendo. [20:18]
- La gestión de productos empezó siendo muy general, por lo que significa muchas cosas diferentes para distintas personas. De alguna forma, ahora se está dividiendo en aún más especialidades, en tipos de perfiles de producto más particulares. [27:53]
- Los hábitos personales que más han aportado al éxito de Sam son la resiliencia, adaptabilidad y humildad. [29:07]
- La herramienta favorita de Sam que usa con frecuencia es Miro. [30:07]
- El consejo de Sam para alguien que empieza su camino en producto es ‘pide ayuda’. [30:51]
Algunas de las mejores personas que conozco en gestión de productos son aquellas que de manera activa y constante están pidiendo ayuda, porque saben que eso les ayuda a mejorar.
Sam Higham
Conoce a Nuestro Invitado
Sam Higham es un líder de producto enfocado en el usuario, con una carrera demostrada en transformar producto, procesos y personas para mejor. Se desenvuelve tanto en los detalles como en los aspectos estratégicos de conseguir que un producto funcione, desde lo funcional hasta el cumplimiento de las expectativas comerciales que debe entregar.
Sam tiene un interés ilimitado en la forma en que la tecnología y la psicología interactúan en los recorridos del consumidor, ayudando a los equipos a identificar formas de fusionar y perfeccionar ambas para lograr los mejores resultados posibles.
Sam es el vicepresidente de producto en Glean, una solución de toma de notas para el aprendizaje y la productividad. La herramienta de Glean graba notas de audio que puedes capturar y aprovechar para aprender la información de manera más efectiva.
Sam también trabaja a tiempo parcial como coach de producto y formador en gestión de productos en Mind the Product, donde ayuda a guiar a las personas a lo largo de la carrera en producto que desean.
Veo al equipo de producto como una pequeña comunidad.
Sam Higham
Recursos de este episodio:
- Suscríbete al boletín de The CPO Club
- Conecta con Sam en LinkedIn
- Sigue a Sam en Twitter
- Conoce más sobre Glean
- Conoce más sobre Mind the Product
Artículos y pódcast relacionados:
- Sobre el pódcast de The CPO Club
- El papel de la estrategia de marketing en el desarrollo de nuevos productos
- Guía de la hoja de ruta del producto: por qué es importante y tipos que deberías conocer
- Gestión de productos en el sector público
Lee la transcripción:
Estamos probando la transcripción de nuestros pódcast con un programa de software. Por favor, disculpa cualquier error tipográfico, ya que el bot no es 100% preciso.
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!
