Cómo aprovechar una mentalidad de fundador dentro de una empresa establecida (con Brendan Fortune)

Leer la transcripción:

Estamos probando la transcripción de nuestros podcasts mediante un programa de software. Por favor, perdona cualquier errata, ya que el bot no es 100% preciso.

Hannah Clark: Pregunta sincera: ¿Crees que es más difícil ser el fundador de una startup o ser el primer PM de esa startup de un fundador? Creo que se puede argumentar cualquiera de los dos dependiendo de tu experiencia pasada. Así que, aunque esa pregunta pueda ser un poco subjetiva, creo que podemos estar de acuerdo en que ambos roles están profundamente comprometidos con el éxito de un producto. Pero aquí está el problema: el éxito de un PM también está vinculado a su capacidad de ganar y mantener la confianza del liderazgo. Y si quieres que un fundador confíe en ti, quizás debas empezar a pensar como un fundador.

Mi invitado de hoy es Brendan Fortune, Chief of Staff en Customer.io. A lo largo de su carrera, Brendan ha visto de primera mano cómo adoptar una mentalidad de fundador es una gran ventaja para los gerentes de producto, especialmente en contextos de cero a uno. En un momento, lo escucharás compartir grandes ideas sobre gestionar tensiones frente a resolver problemas, fallar rápido (así como sus fracasos favoritos), Y el momento más emocional del trayecto de cero a uno. Vamos a comenzar.

Bienvenidos de nuevo al podcast The CPO Club.

Brendan, gracias por estar hoy con nosotros. ¿Cómo estás?

Brendan Fortune: Estoy muy bien. Gracias Hannah por invitarme.

Hannah Clark: ¿Podrías contarnos un poco sobre tu trayectoria y cómo terminaste en Customer.io?

Brendan Fortune: Siempre me fascina escuchar las historias de la gente porque normalmente se detienen en la parte donde hacen la transición a producto. Así que trataré de detallar la mía.

Empecé en soporte de TI cuando estaba en la universidad en Los Ángeles. Y luego, tras graduarme, tuve suerte. Un reclutador que nunca conocí me buscó para trabajar duro en una startup de 150 personas en el ámbito de voz sobre IP. Muy técnico. Así que hacía soporte técnico allí. Y por las noches componía música para cine porque aún tenía mi gran sueño de Hollywood.

Con el tiempo me di cuenta de que hacer música para cine era mucho más saludable como hobby que como trabajo. Así que dejé eso. Comencé un MBA para empleados, y para quienes no lo hayan oído, yo tampoco lo había hecho. Es algo así como un posgrado a tiempo parcial. Tienes un trabajo a tiempo completo y también vas a la escuela, dura tres años.

Y ahí es donde aprendí sobre la gestión de productos, que es esa combinación de habilidades técnicas, creatividad y liderazgo que me resultaba muy emocionante. Así que utilicé el MBA para conseguir un puesto de gerente de producto junior en la empresa donde ya llevaba cuatro años en soporte técnico y luego en TI.

Eso fue complicado. Fue difícil. No querían dármelo al principio. Probablemente tenían razón, pero acabé haciendo el trabajo de todas formas. Y unos meses después pude conseguirlo. A partir de ahí dejé esa empresa como director de producto. Estuve un tiempo en GoDaddy, en su departamento de hosting.

Después trabajé en Drip, que es una plataforma SaaS de automatización de marketing. Y ahora estoy en Customer.io. Empecé en producto y ahora, como chief of staff, mi trabajo es crear los sistemas organizativos que ayuden a los líderes de ingeniería, producto y diseño a hacer su mejor trabajo, sea lo que sea que eso signifique. Hay muchísimas cosas ahí, así que...

Hannah Clark: Hoy nos centraremos en la mentalidad de fundador y cómo se ve dentro de las limitaciones de una empresa establecida. Es un juego muy diferente que en una startup.

Primero, vamos a enmarcar un poco nuestro tema. ¿Cómo definirías la mentalidad de fundador si tuvieras que resumirla y cómo se ve en acción para ti?

Brendan Fortune: Creo que este tema es muy divertido porque a veces me resulta incluso amenazante escuchar eso de mentalidad de fundador, como si nunca hubiera fundado mi propia empresa. ¿Eso significa que no puedo tener mentalidad de fundador? ¿Hay algo mal conmigo?

¿Por qué no lo he hecho si quiero construir productos? Pero trabajando con cuatro fundadores a lo largo de los años, empecé a verlo de otra manera. Para mí, mentalidad de fundador significa una inclinación hacia crear algo propio en vez de seguir lo de otros. Y eso puede ser un nuevo producto, una nueva filosofía, una nueva forma de gestión. Puede ser cualquier cosa. Pero el comportamiento definitorio es: cuando tienes un desafío, ¿tu instinto es crear tu camino para salir de él? ¿O es buscar las respuestas fuera de ti? Y creo que la mentalidad de fundador es esa: crear tu propia salida, lo que no significa ignorar todo lo que otros han dicho y hacerlo tú solo, sino ser escéptico por naturaleza con el material ajeno, salvo que lo entiendas profundamente.

Eso es lo que significa para mí mentalidad de fundador, y se me ocurren algunos ejemplos de cómo se puede aplicar. Deja que piense en uno relacionado con producto, ya que este es un podcast para Product Managers. Cuando me contrataron en GoDaddy, el equipo directivo me dijo: oye, necesitamos que construyas un producto de cloud hosting para nosotros.

Eso fue en los primeros días de Amazon Web Services, creo que Google acababa de entrar en ese sector. GoDaddy pensó: oye, podemos hacerlo. Así que me dijeron, eso es lo que tienes que hacer. Y tres meses después, volví y dije: no, esa no es la idea correcta para el negocio.

En vez de eso, deberíamos desarrollar un negocio de servicios gestionados sobre Amazon Web Services, que era un plan bastante polémico en ese momento. Recuerdo hablar con colegas y jefes, y había esa sensación de: espera, pero no se supone que hagas eso. ¿Cuáles son las ramificaciones políticas?

Creo que la mentalidad de fundador ahí es decir lo que realmente piensas, tanto como sea posible, en lugar de lo que crees que es correcto o lo que otros piensan si no lo entiendes del todo. Esto se aplica de varias maneras: uno de mis ejemplos favoritos, un poco friki, es uno de operaciones como chief of staff en Customer.io. Tenemos un proceso en el que nuestros equipos de cara al cliente, como soporte técnico, customer success, ventas, etc., deben hacer preguntas o escalar problemas al departamento de ingeniería, producto y diseño. Bugs, lo que sea.

Durante mucho tiempo, el proceso era: una persona generaba un ticket y un gerente de ingeniería lo revisaba y decidía a qué equipo asignarlo. Era un proceso tedioso. Los tickets a veces tardaban una hora, a veces un día, según lo ocupada que estuviera la gente.

La decisión se enmarcaba como: o lo hace un gerente de ingeniería o lo hace alguien de soporte técnico, pero siempre debía haber una revisión manual. Otro ejemplo de mentalidad de fundador es aplicar nueva tecnología.

En este caso, aplicamos un bot LLM de Zapier muy sencillo, que tomaba el ticket ya creado, lo analizaba y lo asignaba automáticamente al área correspondiente. Ahora, casi todos nuestros tickets se priorizan al instante, mientras que antes tardaba mucho.

Es otro de esos casos donde, si te presentan una falsa dicotomía, como que solo puede funcionar de dos maneras, probablemente haya otra forma. Y eso es lo que la mentalidad de fundador ayuda a descubrir.

Hannah Clark: Sí, supongo que es énfasis en los recursos y en cómo lograr más con menos o ser creativo con las soluciones. Realmente creo en la idea de que la creatividad se alimenta de la restricción. Así que es parecido a esa mentalidad.

Acerquémonos y hablemos de la mentalidad de fundador aplicada a los proyectos de producto cero a uno. ¿Cuál consideras que es un desafío central que enfrenta un PM al intentar crear un producto completamente nuevo?

Brendan Fortune: Me encanta esta pregunta. Voy a darle la vuelta. Creo que uno de los desafíos centrales que un PM enfrenta aquí es superar la mentalidad de fundador, lo cual puede parecer contradictorio porque, claro, si estás creando algo nuevo, necesitas pensar creativamente como lo haría un fundador.

Pero hay un peligro en esa mentalidad, que viene de sentir que como lo creaste tú, realmente te pertenece. ¿Alguna vez has oído a alguien referirse a un proyecto como “su bebé”? Hay una razón. La propiedad puede sentirse tan íntima como si fuera un hijo. A veces la gente lo dice en broma, pero al menos en mi experiencia, no tiene nada de divertido en algunos casos.

Lo veo como que, si entras a hacer algo de cero a uno, y quieres aplicar esa mentalidad de fundador construyendo con un equipo –que es la única manera que yo conozco–, entonces debes hacer todo lo posible por compartir ese viaje de crianza, por decirlo de algún modo. No sé si la analogía da para tanto, pero queremos ser co-padres, o lo que sea. Así que lleva a toda la aldea. Ese es uno de los desafíos centrales. Es muy fácil dejarse llevar por la idea de que yo debo tener las ideas, yo debo poseerlo, yo debo tomar todas las decisiones, pero eso lleva a más fracasos que a trabajar en equipo. El reto central es ir solo. Pero si vas a aventurarte en este peligroso viaje de cero a uno, necesitas tener a la gente adecuada desde el principio.

Tomo prestado este concepto del libro Good to Great de James Collins, que me sigue gustando aunque ya es viejo. La idea es que no necesitas saber exactamente a dónde vas ni qué vas a construir antes de saber qué personas necesitas para el viaje, lo cual es contraintuitivo.

¿No deberías poder decir: únete a mí en esto, necesito que hagas este trabajo? ¿No es esa la actitud responsable? Pero el libro y su concepto tratan de lo contrario: tienes que conocer tus fortalezas, tus debilidades y reunir personas cuya fortaleza compense tus debilidades.

Se trata de que las piezas del puzzle encajen bien. Esa es la forma de superar la mentalidad de fundador y el sesgo de propiedad, como decir: “este es mi bebé”.

Hannah Clark: Siguiendo esa analogía parental, quieres encontrar un socio que comparta tus valores, pero también que complemente tus debilidades. Creo que es una muy buena analogía.

Me gustaría profundizar más en la idea de tener a la gente adecuada en el autobús. Porque es fácil imaginar un esquema, pero ¿cómo se hace en la vida real? Basado en tu experiencia, ¿cómo evalúas quién debe estar en el bus? ¿Cómo valoras sus fortalezas y debilidades?

Brendan Fortune: Empiezo por ejemplos simples. Suele suceder lo siguiente: eres un genio técnico o un product manager técnico, pero en cuanto a contar historias y tener carisma para liderar un equipo, no tienes esa habilidad. Es muy común.

Esa sería una habilidad que debes buscar. Esto incluye, especialmente en empresas donde construyes un nuevo producto. El esfuerzo de evangelización no solo es hacia los clientes; también se debe convencer al equipo directivo, pues se destina gente, recursos y dinero a ello. Si sabes que careces de esa habilidad, es algo que debes buscar en alguien más.

Otros ejemplos, algunos por experiencia propia: si te asignan construir un producto que realmente no entiendes –el dominio, el mercado, los clientes–, asegúrate de rodearte de alguien que sí, o pregúntate honestamente si eres la persona indicada para liderar ese producto de cero a uno. Uno de los mayores riesgos es poner a una persona, aunque esté en una posición de liderazgo, que no conoce el sector. Toma tiempo y no es sencillo. Yo mismo pensé que podría aprenderlo rápido y fracasé.

Hannah Clark: Sí, y puedo imaginar lo mucho que uno debe apoyarse en la retroalimentación de los usuarios y en todo el aprendizaje necesario para llegar a un conocimiento básico. Es un gran desafío para quien se encuentra en esa situación.

Quiero hablar sobre fallar rápido. Es casi una frase hecha. Muchas culturas de equipo enuncian la idea, pero casi nunca la definen de verdad. Por ejemplo, ¿cuánto tiempo y esfuerzo le damos realmente a una idea antes de llamarla fracaso?

O ¿cómo definimos el fracaso? ¿O acaso permitimos que los colaboradores digan: “creo que esto no funciona”? ¿Sienten esa seguridad psicológica? ¿Qué sugerencias tienes para adoptar esa cultura de fallar rápido y gestionarla en un equipo?

Brendan Fortune: Me encanta esa pregunta y resuena conmigo en el sentido de que mucha gente lo menciona, pero no siempre lo practica o lo cree. El concepto de fallar rápido tiene valor, pero en mi experiencia, está mal enfocado.

Es fácil pensar que fallar rápido significa fallar todo lo que quieras; o lo contrario: se supone que puedes fallar, pero en cuanto fallas algo cambia enseguida. Pienso en uno de los principios de liderazgo de Amazon: los líderes suelen tener razón. Mi hermano trabajó en Amazon y me decía que ese principio es una tontería. Deberías empoderar a tu equipo, no decidirlo todo tú.

Es otra conversación, pero a veces la práctica de fallar rápido significa en realidad: aciertas casi siempre y con lo aprendido tras fallar, logras el éxito rápido. Sobre cómo definir el éxito o el fracaso, es típico en una reunión alguien preguntar por los metrics de éxito. Y está bien que los haya. Pero a veces se asume que deben estar claros antes de dar un solo paso, y que serán una especie de binario de sí o no: éxito o fracaso.

Quizá esto ha funcionado en algún sitio, pero en los productos que he construido de cero a uno, nunca. Un ejemplo reciente: en Customer.io, el último producto es Data Pipelines, una plataforma de datos de clientes. Por si alguien no lo sabe: es un punto único de integración de los datos de clientes para toda la empresa, para enviarlos a CRMs, sistemas de automatización, etc.

Al empezar, los metrics principales de éxito eran ganar clientes a la competencia proponiendo un producto más barato, apostando por la comoditización del sector. También generar ingresos mensuales de nuevos clientes que solo usaran ese producto, y pagar el equipo de desarrollo con el dinero nuevo. Seis meses tras la salida... ¿cuántos metrics habíamos cumplido?

Hannah Clark: Diría cero, o quizá uno.

Brendan Fortune: Cero, quizá lo he insinuado mucho. Cero es correcto, pero no cerramos el proyecto. Entonces, ¿por qué no? ¿Acaso es el sesgo de costes hundidos? ¿O pensamos que con más tiempo llegará? No es eso. Aunque no tuvimos éxito en esos metrics, sí encontramos éxito en otros inesperados.

Clientes que nunca habían usado una CDP eran los que más adoptaban. Además, detectamos un nuevo mecanismo económico: el producto se tarifica según número de llamadas API, modelo variable. Cuantos más datos, más valor y más ingresos mensuales recurrentes. Así, quienes adoptan el producto, aumentan el uso mes a mes. Es la clave del flywheel económico de Customer.io. No ganamos a los competidores con precio bajo (los usuarios ya fieles apenas cambian por un simple descuento), y tampoco hubo crecimiento rápido. Debimos perseguir el crecimiento del flywheel económico, no el ingreso inmediato. Y por eso el producto sigue. Así que si trabajas de cero a uno, define métricas, pero espera que evolucionen y a veces el éxito esté en otros sitios. Mientras haya éxito en algún lado, el proyecto debe continuar. El fracaso llega solo si no se encuentra éxito alguno.

Hannah Clark: Muy interesante. Creo que muchos podemos relacionarnos con eso en distintas áreas de la vida: a veces la expectativa no se cumple pero surgen otros valores o hitos. Muy valiosos tus aportes.

Ya que hablamos de fracasos, quiero ponerte en el “hot seat”. Más allá de Customer.io, ¿cuál ha sido tu fracaso favorito y más valioso?

Brendan Fortune: Pregunta interesante. Casi diría que tengo tantos, pero recuerdo haber dicho que los líderes suelen acertar... bueno, lo cierto es que tengo muchos errores favoritos.

El primero que me vino a la mente fue en GoDaddy. Intentábamos crear Enterprise WordPress, un producto de hosting para grandes agencias, como las que construyen los sitios de cadenas como ABC.com.

Queríamos hacer un producto que, con la flexibilidad de WordPress (más accesible para no técnicos), sirviese para el tráfico masivo que buscan esas agencias. Había productos similares exitosos. Teníamos buenas relaciones con clientes, algunos estaban como pilotos. Durante 9-12 meses trabajamos un equipo de 5-6, sobre todo ingenieros, y al mes o dos de lanzarlo, cerramos el proyecto.

Habíamos construido algo que no funcionaba de inicio: no se podía promover fácilmente de entorno de pruebas a producción. Pensábamos que éramos ingeniosos garantizando seguridad, haciendo que no se pudiera cambiar nada directamente en producción, todo era estático y muy seguro...

Pero a los clientes no les interesaba y no validamos la idea, sólo les dijimos lo que pensábamos hacer y nos contestaban (como en “el test de la mamá”) que “sí, sí, suena bien”. Mi aprendizaje: si crees que eres ingenioso, compruébalo. Y si no hay nadie en el equipo con experiencia real en el dominio –ni yo la tenía antes del producto–, cuidado.

Hannah Clark: Para quienes no conozcan el test de la mamá, ¿puedes resumirlo?

Brendan Fortune: Es cuando preguntas algo a alguien que realmente te aprecia (una madre, por ejemplo), probablemente obtendrás la respuesta que quieres, no el feedback real o crítico necesario. Hay mucha diferencia entre “te apoyo” y “te pago por eso”. Eso es el test de la mamá.

Hannah Clark: Es curioso. En Norteamérica, la gente tiende mucho a decir sí por educación incluso si no tiene interés real en el producto.

Brendan Fortune: Sí, exactamente. Esto me lleva al debate de la franqueza radical, el marco de Ken Scott sobre empatía perjudicial versus agresividad ofensiva. Cuando hablas de la cultura norteamericana de apoyar, de no ser directos con el feedback crítico, yo pienso en eso. Hay que fomentar la franqueza radical, aunque vaya contra la cultura.

Hannah Clark: No me importa ese desvío porque creo que practicar la franqueza radical es clave, sobre todo en un equipo de producto. Pienso en los millones desperdiciados por no practicarla.

Brendan Fortune: Seguro, miles de millones. No he trabajado nunca en una empresa que lo haya logrado bien. Creo que la cultura es una tensión a gestionar, no un problema a resolver. Nunca termina: nunca “ya lo tenemos”. Es desordenada y no profesional. A veces, para crear confianza, soy vulnerable contando aspiraciones personales (por ejemplo, no sé si veo carrera aquí, etc). Eso es arriesgado y a veces se percibe como política, que es lo opuesto a lo que buscas. Porque necesitas esa confianza para tener franqueza radical, no solo decir lo que piensas.

He trabajado con gente que quiere eliminar esos roces. Oyen conflicto y lo quieren parar (“están peleando, hay que desacelerar la tensión”), pero así matan la franqueza radical. Creen que ayudan, pero la franqueza radical es conflicto. Y solemos ver el conflicto como algo a evitar, pero el conflicto es riesgo y también recompensa.

Hannah Clark: El conflicto es una oportunidad. Tenemos un artículo al respecto.

Bueno, siguiendo, mencionaste tensiones a gestionar y ese marco me parece importante. No siempre se cita en el liderazgo, pero es fundamental en la gestión de personas. ¿Nos puedes explicar esa idea?

Brendan Fortune: Lo pondré desde mi experiencia como product manager. Cuando empecé en producto, te incentivan a lanzar cosas, resolver problemas para clientes. Al lanzar hay una sensación de cierre, de finalización. Aunque después toca escalar y operar, existe ese hito. Trabajamos con tickets, historias de usuario. Se resuelven, ves progreso. Al pasar a roles de mayor impacto (como jefe de personas), es fácil pensar igual: identifica un problema, crea una solución y se acaba. Ese podría ser el formato de la reunión de equipo. Pero con las personas todo cambia: las tensiones nunca dejan de aparecer, jamás resuelves “del todo” nada. Siempre hay cambios en tu equipo. Además, quieres que tu gente crezca, por lo que debes gestionarlas distinto. Las soluciones de antes quizás ya no sirvan. Así que para mí es útil pensar en tensiones a gestionar, asumir que cada vez que resuelvo algo, se desresuelve. Mantenerse creativo puede ser agotador, pero encaja con la mentalidad de fundador: si te gusta crear, las tensiones a gestionar te dan esa oportunidad. Eso pienso sobre el alineamiento, la gestión de personas y demás. No existe un manual que te salve de gestionar tensiones.

Hannah Clark: Me encanta esa idea porque si como jefe de personas no esperas una resolución definitiva, puedes gestionar tu energía mucho mejor al gestionar esas tensiones.

Sobre ese tema, hablemos de alineamiento. Cada quien tiene su idea de lo que significa en un equipo, pero es clave. ¿Qué consejos tienes para lograr alinear a un equipo en un gran entregable, como un producto nuevo?

Brendan Fortune: He pensado mucho en esto este año con Pipelines. He visto que dos cosas funcionan bien y las empecé demasiado tarde. La primera es la retroalimentación uno a uno, y no me refiero solo a feedback crítico. Por ejemplo: si hago un roadmap sobre cómo atacar ese “cero a uno”, con una visión y prototipos, es tentador hacer una reunión grupal para presentarlo, preguntas y listo, todos alineados.

Pero la alineación grupal no funciona bien. Incluso en grupos pequeños ocurre que, más adelante, descubres que una persona no entendió nada, o no le importaba o no participó. Y si no te han escuchado, no pueden ni siquiera discrepar y comprometerse. Por eso, antes de compartir algo en grupo, valídalo uno a uno con los interesados clave y asegúrate de entenderlos y repetir lo que te dicen, usando herramientas como Miro, si estás en remoto. No escatimar aquí, sobre todo con el equipo núcleo. Con el liderazgo cuesta más, pero con tu equipo, tómate el tiempo necesario, varias reuniones si hace falta.

Otra idea: para el alineamiento directivo, existe el concepto de el “roadmap de aprendizaje”. Los ejecutivos suelen buscar progreso: ¿qué se está lanzando? ¿dónde está el retorno? En proyectos cero a uno, gran parte del tiempo no tienes dinero que mostrar, aunque conceptualmente lo entiendan, suelen presionar. Si no han construido producto antes (o incluso si sí), pueden verse tentados a exigir velocidad, temiendo verse ridículos, y eso mata el alineamiento.

El “roadmap de aprendizaje” te permite mostrar progreso sin ingresos. No dices solo “lanzaremos esta función”, sino “estas son las incógnitas que resolveremos esta semana”: por ejemplo, ¿será un producto independiente o integrado? Reúnes datos, analizas y comunicas la respuesta, tu evidencia y avanzas. También cuestiones de pricing, o cuántos clientes firmarían. Contrario al test de la mamá: ¿puedes lograr que alguien se comprometa a pagar aunque no tengas el producto? Si identificas los supuestos a desafiar y los planteas en ese roadmap, mostrando así progreso además de features, generas alineamiento a nivel ejecutivo. Les permites involucrarse y opinar, lo que ayuda al alineamiento.

Hannah Clark: Excelente consejo para gestionar esa tensión, como decías.

Antes de terminar, quiero hablar brevemente sobre la transición tras llevar un producto de cero a uno: tu “bebé” debe crecer. ¿Cómo es ese proceso? ¿Por qué cuesta tanto, y cómo gestionarlo cuando sentimos esa propiedad?

Brendan Fortune: Como ya hablamos, lo ideal es que nunca se convierta en tu “bebé”, aunque es difícil, especialmente porque para sacar adelante un cero a uno hay que creer en ello más que nadie. Eres el evangelizador, pones parte de tu alma y se vuelve parte de tu identidad, así que cuesta. Mi consejo: define tú mismo el fin, toma el control de la entrega para que no parezca algo que “te pasa”, sino algo que tú haces acontecer. Busca el momento adecuado: así lo hice con Data Pipelines. Tras el lanzamiento, cuando la empresa necesitó que fuera chief of staff, busqué el momento, planteé quién hacía falta para el rol, los contraté y los formé. Elegir el momento adecuado lo hace más llevadero. Y otra cosa: hay una frase de Yoda, en una de las nuevas de Star Wars (no haré la voz de Yoda, sería horrible), dice algo como: “Transmite lo que has aprendido, la fuerza y el dominio sí, pero también la debilidad y el fracaso. Somos lo que ellos exceden; esa es la verdadera carga de todo maestro.” Tal vez es raro verse como maestro del producto, pero es similar: lo has creado y poseído, pero el verdadero éxito es cuando alguien puede hacerlo mejor que tú. También es cierto en la gestión de personas; si puedes creer eso, entusiasma el traspaso.

Hannah Clark: Precioso. Te perdono que no hagas la voz de Yoda.

Bueno, fue una gran conversación, Brendan. Mil gracias por venir y por todos los increíbles aportes.

¿Dónde puede la gente seguirte o ver tu trabajo online?

Brendan Fortune: Encantado de conectar en LinkedIn. Si alguien tiene preguntas o si han probado estos enfoques y no les han funcionado, me encantará que me lo cuenten. También estoy en Twitter como @mnproductmgr o product MGR, es algo confusa. Vivo en Minnesota, por eso lo de MN.

Hannah Clark: Estado infravalorado. Hemos hablado de eso.

Bien, muchas gracias, Brendan. Espero hablar de nuevo pronto.

Brendan Fortune: Gracias, Hannah.

Hannah Clark: Gracias por escucharnos. Para más ideas, guías prácticas y análisis de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The CPO Club allí donde escuches tus podcasts.