Cómo generar confianza dentro de tu equipo de producto y obtener la aceptación de los stakeholders

Lee la transcripción:

Estamos probando transcribir nuestros pódcasts usando un programa de software. Por favor disculpa cualquier error tipográfico ya que el bot no es 100% preciso.

Hannah Clark: Déjame situarte en el contexto: estás en una sala de reuniones con todos tus stakeholders clave. Miras a tu izquierda y ves al Director de Cuentas terminando un correo electrónico. A tu derecha, el Jefe de Ingeniería cruza los brazos y observa con recelo tu presentación. También tienes la sensación de que el Diseñador Líder de Producto está juzgando la disposición de tus diapositivas. De alguna manera, vas a tener que convencer a todas estas personas de avanzar en la misma dirección. Pero antes de poder hacer eso, necesitas que confíen en ti. ¿Cómo puedes ganar esa confianza y lograr la aceptación?

Hoy me acompaña Noa Goldman, Lead Product Manager en DagsHub. La carrera de Noa comenzó en el desarrollo de software, así que ha estado en ambos lados—lo que significa que sabe lo difícil que puede ser ganarse los corazones dentro de equipos multifuncionales y llegar a una solución fuerte para los problemas de los clientes. Noa compartió su receta para ganarse a los stakeholders, construir relaciones y fortalecer el rendimiento del equipo. Vamos allá.

Muchas gracias, Noa, por acompañarnos.

Noa Goldman: Gracias. Estoy feliz de estar aquí. Gracias por invitarme.

Hannah Clark: Sí, encantada de tenerte. Entonces Noa, tienes una experiencia en desarrollo de software, lo que seguro te ha sido útil de muchas formas. Pero me encantaría que nos contaras cómo ha influido en tu enfoque hacia la gestión de producto.

Noa Goldman: Claro. Fui desarrolladora full stack durante ocho años. Parte de eso fue mi servicio militar, parte en startups pequeñas y grandes corporaciones. Luego hice la transición a ser product manager y mi experiencia actualmente se encuentra en el mundo de herramientas para desarrolladores, donde me ha servido ser desarrolladora en esta área.

Y me influyó bastante, obviamente. Primero, desarrollé un hábito muy fuerte de pensar en el usuario y también en el comprador. Sé que esto es algo que la mayoría de los product managers dicen que es muy importante y que siempre piensan en el usuario y el comprador, pero desde mi experiencia, a menudo no es así.

Por haber sido desarrolladora y ahora product manager para herramientas de desarrolladores, siempre pienso en ambos: usuario y comprador. Por ejemplo, si lanzamos una nueva función, o un nuevo producto, siempre pensaré en mí misma probando esa función. ¿Cómo me sentiría? ¿Cómo le parecería a mi colega? ¿Cómo la usaríamos? ¿Bajo qué criterios nos evalúan? Esto es muy importante y siento que muchas veces se olvida. Cuando lanzas una función específica, siempre tienes que considerar cómo está siendo evaluado el usuario y si esa función va a ayudarle a mejorar sus métricas o la percepción de la gestión sobre su resultado en ese caso de uso concreto.

Así que sí, influyó en mi costumbre de pensar en la persona usuaria, pero también me ayudó mucho con el comprador. Porque siento que este comprador a menudo está fuera del proceso de lanzamiento de nuevas funciones y productos.

Y cuando tratamos de lanzar un nuevo producto, siempre pienso: ¿Quiénes están en el flujo de compra? ¿Quién toma la decisión? Por ejemplo, pienso en mí misma como desarrolladora yendo con mi líder de equipo para proponerle una función y diciendo "Esto está genial". Y ese líder de equipo me preguntaría: ¿Por qué esto nos ayuda? ¿Por qué deberíamos pagar a esta empresa? Así que trato de pensar también en esos perfiles. Esta es una parte muy grande de ser product manager, y mi pasado como desarrolladora realmente me ayudó en eso. Creo que también influyó en cómo priorizo.

Porque para cada nueva función, no siempre tengo que preguntar al líder del equipo. Creo que esto puede ser un proceso difícil para los leads o los de I+D si el product manager les está preguntando constantemente cuánto llevará o qué esfuerzo requiere. Así que siento que esto puedo hacerlo casi por mi cuenta, hasta cierto punto.

Eso me ayudó mucho y me influyó bastante. Pero lo más importante que saqué de ser desarrolladora son las relaciones con otros desarrolladores. Porque sé cómo me sentía sobre el product manager cuando yo era desarrolladora, y cómo lo veían mis colegas. Y no siempre es agradable; no siempre están de acuerdo con ellos.

Lo que aprendí de esto es que quiero que los desarrolladores con los que trabajo se sientan bien conmigo y quieran ayudarme. Sé lo importante que es la relación y sé, o al menos creo que sé, cómo ganarme su confianza. Sé cómo elegir por qué luchar, qué es más importante y qué menos. Creo que darme cuenta de la importancia de la confianza realmente me ha ayudado porque yo empecé como desarrolladora.

Hannah Clark: Me gustaría escuchar un poco más sobre eso; por ejemplo, si un product manager que nos escucha está intentando trabajar lo mejor posible con su equipo de desarrollo, no quiere resentimiento ni tensión. ¿Cuáles son las mejores prácticas que un PM puede tener en cuenta para trabajar eficazmente con el equipo de desarrollo?

Noa Goldman: Sí, claro. Obviamente, a veces hay muchos conflictos y puede ser frustrante para ambas partes. Como he estado en ambos lados, lo conozco muy bien. Creo que una de las cosas más importantes es siempre explicar el porqué, explicar y conectar al equipo con el negocio.

Nosotros, como product managers, estamos en medio de todo; hablamos mucho, constantemente estamos con el equipo de marketing, ventas, la alta dirección. Y los desarrolladores, no tanto. Cuando presentas algo que quieres desarrollar al equipo de desarrollo e I+D, es muy claro para ti como product manager lo que quieres y el porqué, y cómo va a ayudar a la empresa.

Pero los desarrolladores, que lo oyen por primera vez, no necesariamente conectan los puntos. Por lo tanto, es realmente importante explicar el porqué y conectar con el lado del negocio. Para mí, si alguien viene a pedirme algo, no siempre estaré de acuerdo si no sé el motivo. Pero si me explican por qué y cómo va a ayudar a la empresa, probablemente esté de acuerdo, o al menos abierta a conversar. Creo que esto es fundamental. Como product managers, mucho de nuestro trabajo depende de otros.

Casi nunca hacemos el desarrollo o el marketing. Siempre tenemos que explicar lo que queremos a otros. Así que es esencial explicar el porqué y conectar los puntos con el negocio. Y también creo que es muy importante mostrar los datos. Si explicas el porqué y cómo va a ayudar al negocio, necesitas pruebas, respaldarlo con datos.

Seguro que todos los product managers dicen que son guiados por datos, pero cuando los presentas al equipo de desarrollo, es incluso más vital. Porque quieres que confíen en ti, ganarte su confianza y que se incorporen al proyecto. Esto es clave.

Otra cosa que he aprendido con el tiempo —suena extraño— pero simplemente da crédito. Como dije antes, gran parte de nuestro trabajo depende de otros. Y cuando alguien como un desarrollador está comprometido y se esfuerza en desarrollar una función, es importante reconocerlo, agradecerlo y felicitarlo, decir “¡Buen trabajo!”, “Bien hecho”, de forma individual, pero también en un foro más amplio para que todos lo sepan.

Personalmente, cuando alguien aprecia mi trabajo, quiero hacerlo mejor, seguir ayudando. Así que diría que esas son las cosas que más me ayudan para conectar con el equipo de desarrollo.

Hannah Clark: Sí, creo que el reconocimiento es muy importante, en casi cualquier rol, y es de esas cosas simples que la gente pasa por alto y hacen una gran diferencia en la colaboración interfuncional.

Pero en ese tema, cuando piensas en colaborar con equipos multifuncionales más allá del de desarrollo, ¿qué buenas prácticas has encontrado para asegurar que el desarrollo de funciones vaya bien y todos estén alineados, independientemente de su área de competencia?

Noa Goldman: Sí, recuerdo una función específica que me ayudó a crear mi propia receta para lidiar con funciones a largo plazo que requieren mucho esfuerzo y tiempo. Fue una función específica: mejoramos el onboarding en una empresa donde trabajaba como product manager y logramos aumentar la tasa de conversión del 15% al 90%.

Fue increíble, pero un proceso muy largo. Yo era una PM junior, así que trabajar con equipos multifuncionales, marketing, ventas y alta dirección era realmente complicado para mí. Ahí creé mi propia guía sobre cómo hacerlo. El primer paso para mí, antes de presentar la nueva función al equipo, es asegurarme de que la motivación es la correcta y que es lo que hay que hacer ahora internamente.

Así que antes de presentarlo a otros, quiero estar segura y sentir que hago lo correcto. Para funciones de gran esfuerzo, siempre trato de interpretar bien el contexto: escuchar las necesidades del negocio, mantener una lista de funciones y solicitudes de los usuarios, ver cómo usan el producto.

Siempre intento tener una visión clara de cómo están las cosas y qué es importante. Cuando surge una gran función, primero verifico conmigo misma que es el paso correcto, lo comparo con mi “mapa” y me aseguro de que tiene sentido hacerlo ahora.

Luego, me vuelvo a chequear con los datos. Aseguro que los números tienen sentido, los reviso meticulosamente y constato que implementar la función va a mejorar la métrica deseada. Así confirmo que no es solo que me enamoré de una función, sino que los datos me convencen que es el paso correcto.

Después de convencerme, busco la forma más clara de presentarlo: trato de crear una o dos frases breves sobre el problema y por qué es importante abordarlo ahora.

Estas frases deben explicar el problema tanto al integrante más técnico como al menos técnico del equipo. Dado que es un esfuerzo multifuncional, quiero que todos, marketing, ventas, dirección, I+D, comprendan a la perfección el porqué y cómo solucionarlo ayudará al negocio.

Así que lo expongo con frases claras y luego los datos ya preparados los presento de forma sencilla: verde significa bien, rojo significa mal, usar el gráfico adecuado… Son cosas simples, pero frecuentemente se presentan mal. Por eso, el problema y los datos que lo respaldan deben mostrarse de manera clara y comprensible para todos.

El tercer paso suena raro, pero yo lo llamo Dividir y Conquistar (Divide and Conquer), aunque puede sonar negativo, no lo es.

Esto significa que antes de presentar la función a todo el equipo multifuncional, trato de tener reuniones individuales con cada líder de área. Esto lleva más tiempo, pero vale la pena. Me reúno con responsable de marketing, ventas, I+D y cualquier otra persona involucrada o a la que necesito convencer.

Al hacer esto, primero hago que se sientan escuchados. Porque, como dije, si quieres que alguien se sume, tienes que hacerle sentir que cuenta y es importante.

Reunirse de uno a uno, aunque tome más tiempo, vale la pena. Además, me prepara para el siguiente paso: la reunión grupal.

Así ya conozco las opiniones de todos, puedo anticipar objeciones y tengo respuestas preparadas. Estas reuniones también aportan ideas útiles para integrar en la función. Eso hará que todos se sientan parte, y a menudo aportan sugerencias que enriquecen el resultado. Tener esas conversaciones individuales significa que la mayoría ya estará a bordo cuando llegue la reunión grupal.

Luego viene la reunión grupal: todos juntos. Puede ser intimidante, pero estarás preparada gracias al trabajo previo. Ahí simplemente presentas lo mismo que en las reuniones individuales: las frases claras y los datos. Para este momento, la mayoría estará a favor, o al menos abierto a conversar.

En esta reunión, lo importante es que todos sean escuchados frente al resto y logres el acuerdo de la mayoría.

Nunca conseguirás el acuerdo de absolutamente todos, pero si se sienten escuchados, al menos estarán abiertos a la idea. Así la mayoría se suma. Después, llega lo que llamo tomar la tarima: una vez que todos están desarrollando la función y el proceso avanza, toca mantenerlos informados, ya sea semanal o mensualmente, o en alguna reunión regular; dedico unos minutos a actualizar al equipo. Me gusta mostrar cambios visuales, dividir una función grande en pequeños logros visibles. Eso mantiene a la gente comprometida. También es buena oportunidad para mostrar los resultados, tanto los éxitos como los fracasos.

Lo importante es ser honesta y clara durante todo el proceso para que todos estén alineados. Y aprovechar para escuchar sugerencias y opiniones. Haciendo esto durante el desarrollo, consigues que los equipos multifuncionales apoyen constantemente y quieran colaborar.

Hannah Clark: Es un proceso excelente y muy claro. Me da curiosidad: ¿qué haces si tienes un equipo dividido, si no hay consenso suficiente para avanzar con una función? ¿Cómo lo manejas?

Noa Goldman: Si estoy segura de que es lo correcto para la empresa, siempre pienso que, al final, todos estamos en el mismo equipo y queremos que la empresa tenga éxito. Así que intento de nuevo dividir y conquistar, explicar el porqué del negocio y convencerles que tenemos los mismos objetivos.

Y normalmente eso funciona. Si aún así no funciona, intento escoger mis batallas. Por ejemplo, si alguien no está de acuerdo, decido cómo convencerle: a veces dejo que tengan otras funciones a cambio, en otras los ayudo a impulsar alguna iniciativa propia…

En el fondo, todo trata de relaciones. Si ayudas a alguien, normalmente querrá devolverte el favor. Es cuestión de negociar y procurar que todos obtengan lo que quieren al final.

Hannah Clark: Tiene sentido. Cambiando un poco de tema hacia la priorización, como siempre digo, cuando se gestionan funciones, la priorización es clave. ¿Cuál es tu secreto para priorizar?

Noa Goldman: Yo tengo mi métrica guía, que es el negocio. Todo lo que la empresa necesite para crecer es mi métrica estrella. Eso es lo que comparo en cada decisión; al final, mi función es hacer crecer la empresa.

No se trata de mis funciones favoritas ni de lo que mi equipo quiera desarrollar, sino de apoyar a la empresa. Como mencioné antes, siempre llevo un registro de lo que piden los usuarios y el negocio, marketing y el mercado.

Pienso siempre en el negocio y, ante cada función, me pregunto: ¿Es esto lo que más hará crecer a la empresa ahora? Si la respuesta es sí, la siguiente pregunta es: ¿Hay una manera más fácil de desarrollar esto?

En la priorización, siempre escojo lo que aporta más al negocio y lo que se puede desarrollar más fácil, con menos esfuerzo. Esas son las dos preguntas que me hago. Y si puedes contestar a esas dos, puedes priorizar cualquier cosa.

Hannah Clark: Casi terminamos, pero quiero finalizar con algo divertido. Les estoy preguntando últimamente a nuestros invitados por la música, aunque sea un poco salido de tema. Pero cuando trabajas o fuera del trabajo, ¿hay algún artista, álbum o género de música que te guste mucho ahora mismo?

Noa Goldman: ¡Qué buena pregunta! Me alegro mucho de que la hagas. No sé ni por qué me alegro tanto. Sí, escucho música todo el tiempo, trato de hacerlo cuando trabajo en tareas que no requieren tanta concentración porque, si no, me distraigo. Mi artista principal ahora es Paulo Nutini.

No sé si lo han escuchado, pero es genial. Acaba de sacar un nuevo álbum que me encanta y mi sueño es verlo en concierto, aunque probablemente no ocurra, pero lo voy a intentar, ya veremos.

Hannah Clark: Qué bien. No lo conocía, pero espero que podamos armar una lista de reproducción de Product Manager con sugerencias de todos los invitados.

Noa Goldman: Me encantaría eso.

Hannah Clark: Sí, así que lo escucharé. Bueno, muchas gracias por acompañarnos hoy, Noa. Realmente aprecio tu tiempo y me encanta que nos hayas dado una receta tan clara y fácil de seguir para ganar conocimiento práctico. Muchas gracias por estar aquí.

Noa Goldman: Gracias. Lo he disfrutado mucho, de verdad. Muchas gracias.

Hannah Clark: Gracias por escucharnos. Para más ideas, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The Product Manager donde prefieras escuchar pódcasts.