La Gestión de Productos en la Práctica, 2ª Edición

Capítulo 4. El arte de la sobrecomunicación atroz

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

El título de este capítulo es en muchos sentidos una broma. Pero para los jefes de producto en activo, también es mortalmente serio. Los mayores errores que he cometido como gestor de producto, y los mayores errores que me han contado muchos otros gestores de producto, consisten en no comunicar cosas que parecen demasiado peligrosas políticamente o demasiado intrascendentes para abordarlas abiertamente.

A veces, las cosas pueden parecer a la vez peligrosas e intrascendentes. Por ejemplo, supón que estás en una reunión con tu equipo y un desarrollador suelta un detalle sobre un producto que parece ligeramente diferente de algo que hablaste en una conversación separada con la dirección ejecutiva. Empiezas a moverte en tu asiento. Estás bastante seguro de que el desarrollador de tu equipo se ha expresado mal. Al fin y al cabo, tu equipo ha estado trabajando con la misma especificación de producto que tú estudiaste con el equipo directivo. En cualquier caso, se trata de una diferencia menor. Y lo último que quieres hacer en ese momento es interrumpir la conversación, poner a un desarrollador de tu propio equipo en una situación incómoda y llamar la atención sobre tus posibles errores. Es sólo una minucia. Nadie se dará cuenta. ¡ No tendría sentido que esto se convirtiera en un gran problema! No pasa nada.

Dos semanas después. Tu equipo está presentando una demostración de este producto, y un miembro del equipo directivo empieza a poner mala cara. Arruga la nariz y entrecierra los ojos. Pronuncia las palabras "¿Qué es eso?" con la suficiente claridad como para que tu corazón se detenga por completo. Mueve la cabeza de un lado a otro e interrumpe tu desarrollo en mitad de la frase: "Lo siento, pero esto parece muy diferente de lo que yo firmé. Ahora mismo estoy muy confusa". Tu equipo se para en seco. Todos te miran. Después de que concluya la retahíla de improperios en tu cabeza, te dices a ti mismo: "Temías que esto fuera para tanto, es para tanto y ahora es demasiado tarde".

Para la mayoría de los jefes de producto en activo, este escenario no es hipotético. Ocurre todo el tiempo, y sigue ocurriendo, incluso cuando juras un millón de veces que no dejarás que vuelva a ocurrir. La desventaja potencial de la falta de comunicación es cavernosa y aterradora. La desventaja potencial de la sobrecomunicación es, siendo realistas, unas cuantas miradas de reojo y quizá algún comentario sarcástico. Como nunca puedes estar seguro de cuál es la cantidad exacta de comunicación necesaria en cada situación, siempre es mejor que te decantes por la sobrecomunicación. Al menos en teoría, esto es fácil.

En la práctica, sin embargo, el trabajo cotidiano de la comunicación integral puede resultar muy difícil. Elegir comunicar en el momento es mucho más difícil que elegir comunicar en abstracto. Este capítulo ofrece algunas orientaciones tácticas para conseguir que la sobrecomunicación atroz forme parte de tu práctica de gestión de productos.

Preguntar lo obvio

Si existe algo parecido a los Diez Mandamientos de la gestión de productos, es "Good Product Manager/Bad Product Manager" de Ben Horowitz ( ), un documento que Horowitz redactó como una especie de formación ad hoc para los gestores de productos de Netscape, allá por los días del primer boom de Internet. "Buen gestor de productos/Mal gestor de productos" es un documento breve y sencillo, pero consigue algo muy importante: establece en términos excepcionalmente claros las expectativas cotidianas de los gestores de productos de esa organización concreta en ese momento concreto. "Haz esto, no aquello". Todas las empresas deberían tener un documento como "Buen gestor de productos/Mal gestor de productos", que explique las responsabilidades del puesto en términos claros, instructivos y conductuales, y que mencione explícitamente los comportamientos que deben evitarse.

Mi parte favorita de "Buen gestor de productos/malo gestor de productos" dice sencillamente: "Los buenos gestores de productos pecan de claridad frente a explicar lo obvio. Los malos gestores de productos nunca explican lo obvio".

Cuando empecé a trabajar como gestor de productos, me preguntaba qué significaba esto exactamente: ¿por qué sería importante explicar "lo obvio"? Resulta que la respuesta es que las cosas que te parecen obvias a ti pueden no serlo para nadie más. De hecho, otras personas pueden haber llegado a conclusiones muy distintas que les parezcan igualmente "obvias". Por esa razón, las cosas que parecen obvias suelen ser las que más posibilidades tienen de provocar una desastrosa falta de comunicación.

Ser la primera persona en cuestionar algo que parece obvio o evidente puede resultar muy incómodo. Hace falta valor para intervenir y decir, por ejemplo: "Sólo para asegurarnos de que todos estamos de acuerdo, cuando hablemos de la 'fecha de lanzamiento' la semana que viene, nuestro plan actual es hacer un pequeño lanzamiento beta cerrado a un grupo de unos cincuenta usuarios para que podamos recopilar algunos datos antes de lanzar nada a un grupo más amplio". Aunque la respuesta que obtengas sea un coro unificado de "Sí, claro, todos lo sabíamos", te garantizo que al menos otra persona estará pensando en voz baja: "Menos mal que alguien ha hablado, porque yo no lo sabía".

Cuando nos orientamos hacia los objetivos empresariales y de usuario de nuestro equipo, la ventaja de preguntar lo obvio parece... bueno, obvia. Si resulta que todo el mundo estaba alineado desde el principio, podemos avanzar aún más seguros de nuestro entendimiento compartido. Y si resulta que todo el mundo no estaba alineado, podemos abordar abiertamente cualquier malentendido de antes de que se convierta en un problema mucho mayor.

Llevar información incómoda a una gran reunión

Julia G.

Director de Producto Senior, startup mediana

Hace unos años, me encontraba sentado en una gran reunión con unos 50 de mis colegas orientados al mercado: todo nuestro equipo de liderazgo de ventas, éxito de clientes y marketing. Durante la reunión, surgió una pregunta sobre una funcionalidad concreta que nuestros clientes deseaban. Nuestro director general intervino en el chat de la empresa para decirnos que acabábamos de lanzar exactamente esa función y animarnos a difundirla.

Sólo había un problema: esta funcionalidad se había enviado a algunos de nuestros canales, pero no al que estábamos discutiendo. Fue un gran momento de "oh-oh": ¿debo intervenir en esta gran reunión y señalar que esta funcionalidad -que acababa de ser celebrada por nuestro director general- en realidad no estaba lista para los clientes que la pedían?

Habiendo vivido las consecuencias de no plantear estas cosas en el pasado, tomé la decisión de hablar claro: "En realidad, esa función aún no está disponible en ese canal, pero la tenemos prevista para el cuarto trimestre". Silencio. ¿Estaba a punto de meterme en un lío? Y entonces, un nuevo mensaje de nuestro director general en el chat de la empresa: "Vale, genial, gracias por avisarme".

En ese momento, sentí un grado de seguridad que nunca antes había sentido como jefe de producto. Hacía poco que me había incorporado a esta empresa, después de trabajar en una serie de startups en fase inicial, donde a menudo se esperaban las cosas "para ayer". Había desarrollado una tendencia a escuchar cada pregunta como una acusación. Si alguien me preguntaba: "Oye, ¿apoyamos esto?". yo lo oía como "¿Por qué no apoyamos esto todavía?". Siempre quería ir por delante de las expectativas, así que si alguien me hacía siquiera una pregunta, sentía que ya había fracasado. Informar al director general de que una función no estaba lista en medio de una gran reunión me parecía un gran riesgo. Su respuesta me hizo sentir confianza y poder.

Solía ponerme la zancadilla pensando: "Si le digo a la gente que esto llevará mucho tiempo, o que no es una prioridad, pensarán que estoy haciendo un mal trabajo". Ahora me esfuerzo por adelantarme a estas conversaciones y decir a la gente lo que realmente ocurre, no lo que quieren oír. No sé hasta qué punto se trata de una maduración natural como gestor de productos y hasta qué punto se debe a trabajar en entornos en los que la gente suele ser considerada y comprensiva. Pero creo que, incluso si me encontrara en un lugar que fuera menos considerado y comprensivo, llevaría conmigo esta nueva confianza. Puede ser incómodo, pero al fin y al cabo, me hace más impactante.

No te desvíes, sé directo

Hace varios años, recibí un mensaje de texto inesperado de mi jefe sobre las 9 de la noche de un jueves. Decía: "Oye, ¡sería estupendo que pudiéramos enviar esta noche esa nueva versión de la aplicación para el iPhone a la App Store!".

Estaba confuso. ¿Se trataba de una demanda urgente? ¿Una petición amistosa pero de baja prioridad? ¿Me estaban pidiendo que hiciera algo ahora mismo? ¿O simplemente se me estaba mostrando una ventana de 113 caracteres a la visión de esta persona de un mundo mejor? En la mayoría de las situaciones, probablemente habría arrastrado mi yo de mártir de productos hasta mi ordenador, habría enviado la solicitud de mal humor y habría respondido con un mensaje demasiado entusiasta del tipo "POR SUPUESTO, NO HAY PROBLEMA".

Pero esta vez estaba en un concierto, a una hora de mi ordenador. (Y sí, me avergüenza mirar el móvil durante un concierto.) Incapaz de volver a mi rutina habitual de exceso de trabajo pasivo-agresivo, salí y llamé a mi jefe.

"Oye, lo siento mucho, pero ahora mismo estoy en un concierto. Pero si necesitas que vaya a casa y envíe la aplicación, puedo hacerlo".

La voz al otro lado de la línea era vacilante.

"Oh, umm, sí, quiero decir, ¡sería realmente estupendo llevarlo a la tienda esta noche!". Una pausa. "Pero si estás fuera en un concierto... quiero decir... sabes qué, no te preocupes por eso, podemos hablarlo por la mañana".

Solté un alegre "Me parece bien, gracias", e inmediatamente me invadió una profunda sensación de temor. ¿Había traspasado alguna línea invisible de equilibrio entre la vida laboral y personal? ¿Había hecho algo malo para la empresa con fines egoístas? ¿Era yo, como sospechaba desde hacía tiempo, una persona terrible y egoísta?

A la mañana siguiente, me preparé para recibir mi castigo. Mi jefe, sin embargo, parecía notablemente indiferente. "Ah, sí, anoche me di cuenta de que habría estado bien enviar la aplicación enseguida, pero no pasa nada por enviarla hoy, no es que vaya a cambiar mucho el calendario final".

En un momento de franqueza poco habitual en mí, le dije: "Vale, ¿puedo pedirte un favor? En el futuro, ¿puedes ser muy, muy claro cuando me pidas que haga algo ahora mismo? Cuando recibí tu mensaje, me resultó difícil saber lo urgente que era realmente la situación. Si alguna vez necesitas urgentemente que haga algo, entonces haré todo lo que esté en mi mano para asegurarme de que se haga. Pero si se trata más bien de un "me gustaría tener algo", ¿podrías ser lo más claro posible al respecto?".

Durante unos 10 segundos, me sentí profundamente orgullosa de mí misma por ser tan directa. Entonces me di cuenta de que la mayoría de las peticiones que hacía a mis colegas seguían empezando con alguna versión de "Sería estupendo si..." o "¡Eh! ¿Crees que podrías, tal vez, quizás...?" o "¡HEY BUEN DÍA! ¿CÓMO ESTÁ EL TIEMPO? ¿TE GUSTAN LOS SANDWICHES? de todas formas me preguntaba si tal vez tendrías tiempo para...".

Dado que los jefes de producto rara vez tienen autoridad organizativa directa, puede resultar tentador redactar las peticiones en los términos más "amables" posibles, especialmente las peticiones de cosas como quedarse hasta tarde para lanzar un producto o rehacer un trabajo que ya estaba terminado. Pero ser ambiguo sobre lo que pides (y sobre si lo pides o no) no es agradable. Es un desvío de la responsabilidad, un intento pasivo-agresivo de obtener el resultado que deseas sin ser el "malo".

La atracción hacia todo tipo de evasivas, disculpas exageradas en y autodesprecio general es fuerte para los jefes de producto. Pero también es perjudicial y peligrosa, tanto para ti como para tu equipo. Durante muchos años, utilicé el autodesprecio para escabullirme de situaciones en las que sentía que la gente podía enfadarse conmigo. Cuando llegaba a mi equipo con un plazo difícil o una petición de trabajo nuevo, solía decir algo como "¡Adivina qué, aquí viene el DIRECTOR DE PRODUCTO con otro PLAZO DIVERTIDO PARA TODOS!". Me parecía una buena forma de aliviar la tensión y demostrar que yo era "uno más del equipo". Y la mayoría de las veces, conseguía al menos una risita.

Pero el efecto a largo plazo que tuvo en el equipo no fue ni bueno ni especialmente divertido. Al utilizar el autodesprecio para no herir mis propios sentimientos, no estaba haciendo absolutamente nada para comunicar a mi equipo por qué les pedía que cumplieran un plazo difícil o que revisaran algo que pensaban que ya estaba terminado. Mi objetivo no era alinear al equipo en torno a nuestro propósito, sino terminar la conversación lo antes posible. Estaba comunicando, intencionadamente o no, que el trabajo que pedía no tenía sentido, porque si asumía la responsabilidad de transmitir su significado, yo sería la persona que pedía el trabajo. Y a nadie le gusta la persona que pide trabajo.

Cuando eres director de producto, habrá ocasiones en las que tendrás que pedir a la gente que haga cosas que no quieren hacer. Si estas cosas son fundamentales para el éxito de tu equipo, ayuda a tu equipo a entender por qué y trabaja con ellos para averiguar qué otras tareas pueden despriorizarse. Y si no son fundamentales para el éxito de tu equipo, pregúntate si estás priorizando cuidadosamente el tiempo de tu equipo o si simplemente dices que sí a cualquier cosa que parezca vagamente importante.

No todo es culpa tuya, y los resultados importan más que las intenciones

Los jefes de producto son a menudo aconsejados para que asuman la responsabilidad plena e inequívoca de cualquier cosa que vaya mal en su equipo. "Si algo sale mal", me dijeron al principio de mi carrera, "es culpa tuya, sea o no realmente culpa tuya".

Me tomé este consejo muy a pecho y abracé mi Martirio de Producto. Y, de un modo curioso, sentí un alivio. Si algo iba mal en mi equipo, simplemente podía declarar: "SÍ, MI CULPA, SOY LO PEOR", y seguir con mi día. En realidad, esto era mucho más fácil que iniciar y facilitar una conversación sincera sobre cómo todo el equipo podía haber contribuido a un resultado deficiente y qué medidas podíamos tomar para obtener mejores resultados en el futuro.

Sí, como gestor de producto, eres el responsable último de los resultados obtenidos por tu equipo. Pero no es una responsabilidad que puedas asumir solo. Si consideras que todo lo que va mal es un fracaso personal, estás privando a tu equipo de una oportunidad crucial para aprender y crecer. Nada va más en contra de nuestro principio rector de convertirte en obsoleto que considerarte el único receptáculo personal de todos los errores de tu equipo, en lugar de trabajar con tu equipo para abordar los retos s istémicos que pueden haber contribuido a esos errores.

La línea entre abordar los retos sistémicos y lanzar recriminaciones personales puede ser muy delgada. A lo largo de los últimos años, he oído a menudo la directiva "asume una intención positiva", utilizada para reforzar esta línea y despersonalizar las conversaciones difíciles. Y desde luego, "asume una intención positiva" es sin duda una directiva más saludable que "Asume la culpa personal de cualquier cosa que vaya mal, aunque no creas realmente que es culpa tuya".

Pero a medida que "asumir la intención positiva" ha alcanzado el punto de ubicuidad, también ha revelado algunas limitaciones. En el último año, por desgracia, he oído utilizar la frase como una especie de desafío pasivo-agresivo a las mismas conversaciones que se suponía que debía facilitar: "¿Cómo te atreves a sugerir que algo va mal en mi equipo? ¿No sabes que lo hago lo mejor que puedo? ¿Qué ha pasado con lo de 'asumir una intención positiva'?".

Como sugiere esta pesadillesca máquina de Rube Goldberg emocional de proyecciones y aplazamientos, la mera idea de centrarnos en las "intenciones" puede llevarnos a un territorio emocional extraño y turbio. Para bien o para mal, las personas con buenas intenciones pueden hacer mucho daño, y las personas con malas intenciones aún tropiezan de vez en cuando con acciones positivas. En términos generales, me ha resultado útil centrar estas conversaciones en los resultados, en lugar de en las intenciones.

En la práctica, esto ha significado a menudo mediar en las conversaciones sobre retos interpersonales o a nivel de equipo con la pregunta: "¿Ha dado esta situación el resultado deseado?" Por ejemplo, cuando un director de producto acude a mí molesto porque su homólogo en ingeniería se siente excluido del proceso de toma de decisiones (una dinámica habitual en los equipos de producto interfuncionales), he adquirido el hábito de preguntar: "¿El resultado deseado de esta situación era que el director de ingeniería quedara excluido del proceso de toma de decisiones?". Si la respuesta es "Sí, no tuve tiempo de implicarlos", o incluso "Sí, no confío en que participen en el proceso de toma de decisiones de nuestro equipo", entonces podemos seguir la conversación a partir de ahí. Y si la respuesta es "No, hice todo lo que pude para implicar a todo el mundo, y no estoy seguro de por qué se sienten excluidos", entonces el director de producto puede iniciar una conversación de seguimiento con su homólogo de ingeniería para entender lo que ocurrió y trabajar para obtener un resultado mejor la próxima vez.

Si nos quitamos de en medio como individuos y observamos el sistema en su conjunto, veremos que nuestras intenciones suelen ser en gran medida irrelevantes. Nuestro trabajo consiste en mejorar los sistemas con la esperanza de obtener mejores resultados para nuestra empresa y nuestros usuarios. Cuando me enfrento a las frustraciones o sentimientos heridos de un colega, me resulta útil responder con una frase como "Vale, gracias por compartirlo conmigo. Parece que esto no ha dado el resultado que queríamos. ¿Cómo podemos cambiar las cosas para obtener un resultado mejor? Este cambio de las emociones a los resultados puede ayudar a reconducir conversaciones que, de otro modo, se deteriorarían hasta convertirse en acusaciones pasivo-agresivas (o en un descarado martirio de productos).

Alejarse del autodesprecio

M.L.

Director de Producto, startup de 100 personas

Nunca olvidaré el momento en que me di cuenta de que la autocrítica de ya no era una parte justificable de mi enfoque de la gestión de productos. Llevaba más o menos un mes en un proyecto especialmente difícil que había implicado muchas noches de trabajo nocturno y reajustes de última hora. Me sentía realmente culpable por haber hecho pasar a mi equipo por todo eso e hice todo lo que pude para aliviar la tensión con disculpas exageradas y comentarios dramáticos de autodesprecio como "Lo sé, lo sé, soy lo peor" y "Sí, todo esto es culpa mía, pero sois los mejores por limpiar el desastre que he hecho".

Y entonces, de repente, recibí un correo electrónico de un desarrollador de mi equipo que me sorprendió de verdad. Le preocupaba la forma en que había estado hablando de mi propio trabajo. Quería saber si realmente me sentía tan mal con mi trabajo. ¿Realmente pensaba que no tenía nada que ofrecer? ¿Había hecho algo para hacerme sentir que el equipo no valoraba mis aportaciones?

Cuando empecé a redactar una respuesta, se me ocurrió una cosa: En realidad no pensaba que no tuviera nada que ofrecer, ni que todo lo que estaba ocurriendo fuera culpa mía. Sin darme cuenta conscientemente, había estado desplegando el autodesprecio como una forma pasivo-agresiva y no del todo sincera de decir: "Por favor, no me desafíes en las cosas que te pido que hagas". Sencillamente, no tenía la suficiente confianza o madurez como gestor de producto para mantener una conversación abierta con mi equipo sobre por qué trabajábamos hasta tarde y rehacíamos cosas que ya habíamos hecho. Y, desde luego, no tenía la confianza ni la madurez suficientes como gestor de producto para mantener una conversación abierta con la dirección de la empresa sobre las desventajas y compensaciones que conllevaban esos trasnoches y cambios de última hora. Para mí era más fácil decir simplemente a la dirección de la empresa: "SÍ, LO QUE QUIERAS", y luego decirle a mi propio equipo: "LO SIENTO, SOY UN ASCO".

He aquí un ejercicio de pensamiento que he estado utilizando para ayudarme a entrenarme para abandonar este comportamiento. Si siento el impulso de hacer un comentario autodespreciativo, me pregunto: "Si alguien de mi equipo me interrumpiera para decirme: 'Oye, no hace falta. Estás haciendo un gran trabajo y respetamos tu opinión', ¿me sentiría aliviado o molesto?". Si la respuesta es "aliviado", entonces intento facilitar una retrospectiva abierta con mi equipo para ver si hay otras cuestiones subyacentes que puedan estar provocando que sienta falta de confianza en mi trabajo. Si la respuesta es "molesto", entonces me pregunto qué pregunta o conversación difícil podría estar intentando desviar mediante el autodesprecio, e intento armarme de valor para plantear proactivamente esa pregunta o conversación a mi equipo.

Después de unos años de evitar el autodesprecio, he tenido que mejorar mucho a la hora de facilitar conversaciones abiertas con mi equipo sobre lo que realmente está pasando y lo que podemos hacer al respecto. Ciertamente, me encuentro con preguntas más difíciles sobre por qué hacemos lo que hacemos o cómo tomé una decisión concreta. Pero mi experiencia respondiendo a estas preguntas me ha ayudado a convertirme en un mejor gestor de productos y, espero, también en una persona menos defensiva.

Las dos palabras más peligrosas en la gestión de productos: "Parece que está bien"

Al principio de mi carrera de gestión de productos , creía sinceramente que podía evitarme problemas asegurándome de que cada paso que daba recibía la "aprobación" superficial de alguien con autoridad. Antes de finalizar la hoja de ruta trimestral de mi equipo, me aseguraba de presentarla en una reunión a la dirección de la empresa. Y antes de convertir las maquetas de diseño en software funcional, enviaba esas maquetas a las partes interesadas que creía que podían tener una opinión particular sobre el aspecto y la sensación de nuestro producto. Aunque aparentemente buscaba la opinión de estas partes interesadas, en realidad buscaba un simple gesto de aprobación, una casilla marcada que me cubriera las espaldas en caso de que las cosas se torcieran más adelante.

La mayoría de las veces, este gesto de aprobación adoptaba la forma de un breve y pasivo acuse de recibo como "Entendido" o "Gracias por enviarlo". Y, en realidad, eso era todo lo que necesitaba y, en aquel momento, todo lo que quería. Pensaba que si más adelante alguien tenía algún problema con el trabajo de mi equipo, podría echarle en cara ese "Lo tengo" y salir victoriosa y reivindicada: "OS ENVIÉ ESTO HACE UN MES Y NO ME HABÉIS RECIBIDO NINGÚN RESPUESTO, LO QUE SIGNIFICA QUE AHORA NO PUEDES CAMBIARLO".

Pronto descubrí que "no dar marcha atrás" no es una política corporativa vinculante. Como veremos en el Capítulo 5, las partes interesadas -especialmente las ejecutivas- son personas muy ocupadas, y ese rápido asentimiento en una reunión o ese correo electrónico de "Entendido, gracias" no significan necesariamente que hayan prestado atención a tu punto de vista, y mucho menos que se hayan comprometido de forma significativa con él. En el mundo de la gestión de productos, todo lo que no sea una aceptación afirmativa y específica es increíblemente peligroso. Y no hay dos palabras que encarnen mejor la falta de compromiso, la ambigüedad y la vaguedad de la no aceptación que "Me parece bien".

Los mejores jefes de producto hacen más o menos imposible que la gente reaccione con un "Parece que está bien". Siempre se presentan con preguntas abiertas, aunque sean incómodas y angustiosas. Y, como ya comentamos en el Capítulo 3, ofrecen opciones, no argumentos, exigiendo la participación activa de sus interlocutores en lugar de asentimientos pasivos con los ojos vidriosos o respuestas de dos palabras por correo electrónico.

Me ha resultado útil incluir al menos una opción significativa o una pregunta abierta en cualquier reunión o correo electrónico en el que pidas opiniones o aprobación. Un correo electrónico que diga: "Adjunto nuestra hoja de ruta para el próximo trimestre. Hazme saber si tienes alguna pregunta", puede crear una apariencia externa de transparencia y colaboración, pero no te protege de respuestas del tipo "¿Qué demonios es eso y por qué no lo he visto antes?" cuando empieces a cumplir esa hoja de ruta. En cambio, es mucho más probable que obtengas respuestas comprometidas de un correo electrónico que diga: "Adjunto encontrarás nuestra hoja de ruta para el próximo trimestre. Como verás, estamos considerando dos opciones diferentes para los sprints 6-8. ¿Podrías hacernos saber antes de que acabe el viernes cuál crees que sería más relevante para los objetivos de tu equipo?" (Hablaremos de la importancia de enviar preguntas específicas y con plazos concretos por correo electrónico y chat en el capítulo 13, "Prueba esto en casa: las pruebas y tribulaciones del trabajo a distancia") .

Un Enfoque Táctico para Superar el "Parece Bien": Discrepa y Comprométete

En conversaciones con múltiples partes interesadas, el centro de gravedad en torno al "Parece que está bien" se hace aún más convincente e irresistible. Tan incómodo como es discrepar con una persona en una conversación individual, puede ser exponencialmente más incómodo discrepar con 10 personas en una conversación de 10 personas. "Parece bien" siempre será el camino de menor resistencia, a menos que hagas el difícil trabajo de añadir mucha resistencia a ese mismo camino.

Afortunadamente, la buena gente de Intel ha sido pionera en una técnica llamada "discrepar y comprometerse", diseñada para hacer precisamente esto. La idea que subyace tras "discrepar y comprometerse" es bastante sencilla: cualquier decisión tomada en grupo debe concluir con un compromiso afirmativo de todos los implicados con el camino a seguir. Y el proceso para llegar a ese compromiso debe requerir que se planteen preguntas, preocupaciones y desacuerdos que, de otro modo, no se habrían expresado.

A modo de ejemplo, imaginemos dos reuniones diferentes, cada una de ellas celebrada con el fin de decidir si una nueva función debe incluirse en el nivel gratuito o de pago de un producto freemium. La primera reunión funciona según las reglas tradicionales del consenso implícito: si todo el mundo está de acuerdo (o, al menos, nadie discrepa), se toma la decisión y se avanza. Como jefe de producto del equipo que está creando esta función, se te ha encomendado la tarea de exponer tus argumentos a un grupo de unas 10 partes interesadas de nivel directivo. Tras repasar detenidamente el análisis de la competencia, las proyecciones de uso y los objetivos de ingresos, concluyes con una firme recomendación de que la función se incluya en el nivel gratuito. "¿Alguien tiene alguna pregunta? ¿Os parece un buen planteamiento? Algunos asentimientos tibios, pero silencio general. Respiras aliviado. "¡Vale, estupendo!"

Tu equipo se pone manos a la obra y comienza a implementar una nueva y emocionante función gratuita. Se negocian los detalles técnicos, se redactan los textos de marketing y todo parece ir por buen camino. Entonces, dos semanas después de la reunión, recibes un correo electrónico de uno de los directores que había asentido a tu propuesta de dirección: "Lo siento, tenemos que suspenderlo, hay algunos problemas con la decisión sobre el nivel de precios que tenemos que resolver". Espera, ¿qué? Creías que todo el mundo estaba de acuerdo. Rápidamente respondes un correo electrónico, haciendo todo lo posible por reprimir tu rabia y frustración: "Gracias por la nota. Lo siento, estoy un poco confuso, creía que todos habíamos acordado que sería una función gratuita". Unas horas más tarde, recibes una respuesta: "Sí, nuestro vicepresidente de ingresos está reevaluando la estrategia de precios y no está seguro de que otra función gratuita tenga sentido en este momento. Tendré más información para ti la semana que viene".

Sacudes la cabeza y sueltas un profundo suspiro. Ahora tienes que volver a tu equipo y decirles que toda la estrategia de precios de la empresa está en peligro y que dos semanas de su duro trabajo están ahora en el limbo por ello. Sabes que esto va a ser un duro golpe para la moral y un gran revés para el calendario de tu equipo, pero, en este momento, no estás seguro de lo que realmente puedes hacer al respecto, aparte de esperar y desahogarte.

Ahora, imaginemos una segunda reunión que funcione según las reglas de "desacuerdo y compromiso": cada persona de la reunión debe ofrecer un compromiso específico y afirmativo antes de que se tome una decisión, y cada persona es responsable de plantear cualquier duda o desacuerdo que pudiera impedirle ofrecer ese compromiso. Después de repasar detenidamente el análisis de la competencia, las proyecciones de uso y los objetivos de ingresos, concluyes con una recomendación firme de que la función se incluya en el nivel gratuito. "De acuerdo", dices a las partes interesadas reunidas, "esta vez vamos a intentar hacer algo un poco diferente". Es una gran decisión para el equipo, y quiero asegurarme de que hemos puesto sobre la mesa toda la información que tenéis. Así que voy a ir preguntando a cada uno de vosotros, uno por uno, si os comprometéis a seguir adelante con el planteamiento que hemos esbozado. Y si no podéis comprometeros, decidme por qué, y ya veremos qué hacemos a partir de ahí".

Te diriges al director de marketing de producto. "¿Te comprometes a que avancemos con una función gratuita?". Parecen un poco desconcertados y se apresuran a soltar un "Um, claro, sí, me comprometo". "Vale, estupendo", dices. Haces una pausa y continúas: "Para que quede claro, el objetivo es poner sobre la mesa cualquier duda o preocupación para que podamos tomar la mejor decisión posible. No tienes que decir que sí si no estás segura". Unas risas nerviosas y responden: "¡Ja, no, gracias, sí, me comprometo! Creo que esto tiene mucho sentido".

Pasas al director de operaciones de ingresos. De entrada, no parecen muy seguros. "En realidad", dicen, "no estoy seguro de poder comprometerme a esto ahora mismo. Nuestro vicepresidente de ingresos está reevaluando nuestra estrategia de precios, y no me gustaría darte un sí definitivo antes de que lo tengamos todo resuelto". Haces una pausa. "Vale, estupendo, gracias por eso. ¿Cuándo crees que podríamos tener más claridad al respecto?". Responden: "Uh, déjame que me ponga en contacto contigo la semana que viene".

En la semana siguiente, puedes mantener varias conversaciones de seguimiento con el equipo de ingresos y comprender mejor cómo y por qué está cambiando la estrategia de precios de la empresa. Mientras tanto, tu equipo avanza con un trabajo que no requiere un compromiso firme con ninguno de los dos enfoques de fijación de precios. Pronto podrás volver a convocar a las partes interesadas de la reunión original y, con el pleno apoyo del director de operaciones de ingresos, explicar cómo ha cambiado la estrategia de precios de la empresa para incluir más funciones en el nivel de pago. Las idas y venidas son frustrantes, pero te sientes profundamente aliviado de haber podido gestionar este cambio a la vista de tu equipo y de las partes interesadas.

Como ilustra este ejemplo, discrepar y comprometerse no resuelve todas las desconexiones y faltas de comunicación que pueden producirse en una organización, pero puede ayudar a sacar a la luz esas desconexiones y faltas de comunicación de forma más oportuna y productiva.

Como ocurre con cualquier buena práctica, la forma de aplicar el desacuerdo y el compromiso cambiará en función de tu equipo y tu organización. Aquí tienes algunos consejos para probarlo:

Introduce el desacuerdo y comprométete antes de utilizarlo.

Dado que "discrepar y comprometerse" es una buena práctica formalizada -y respaldada por empresas de la talla de Intel y Amazon-, puedes introducirla como un experimento de procedimiento acordado. Esto es importante porque ayudará a evitar cualquier situación en la que la gente pueda sentir que estás aplicando "discrepar y comprometerse" como una especie de crítica personal pasivo-agresiva dirigida a cualquier miembro de tu equipo que no se comprometa.

Interpreta el silencio como desacuerdo.

En la mayoría de las reuniones, el silencio se interpreta como un acuerdo implícito. Alguien sugiere un camino a seguir, concluye su discurso con "¿Alguna pregunta?" y si nadie responde, es más o menos un trato hecho. Con no estar de acuerdo y comprometerse, no se acepta nada que no sea un compromiso afirmativo, lo que significa que el silencio equivale a desacuerdo. Sé muy claro con los participantes: "Si te callas, voy a suponer que no estás de acuerdo conmigo. Vamos a repasar y a hacer que cada persona comparta sus pensamientos y preocupaciones". La primera vez que pruebes esto, puede que sea uno de los momentos más incómodos de tu carrera de gestión de productos, pero te sorprenderán las ideas que pueden surgir de las personas más calladas de la sala.

En reuniones grandes, intenta tomar el pulso rápidamente.

En reuniones grandes -especialmente en las que se celebran por videoconferencia-, a menudo me ha parecido útil avanzar hacia la conclusión de una reunión con un rápido "¿Pueden todos los que están comprometidos con este enfoque darme el visto bueno?". Incluso si sólo una o dos personas responden tímidamente, esto te da la oportunidad de profundizar y demostrar rápidamente que las opiniones discrepantes serán bienvenidas y se tomarán en serio.

Fija objetivos, prueba y aprende.

Entonces, ¿qué pasa si la gente simplemente no se compromete a seguir un camino? Esto es, lo creas o no, una gran señal. Significa que las personas de la sala están lo suficientemente comprometidas como para no comprometerse con algo que consideran erróneo. Una forma de hacer avanzar esta conversación es establecer criterios de éxito y planificar volver a examinar la decisión más adelante. Entonces podrás validar si el enfoque elegido funciona y hacer los ajustes necesarios.

Por ejemplo, supongamos que estás en una reunión con tu equipo de ingenieros y hay un desacuerdo sobre si el ciclo de desarrollo de vuestro producto debe ser de dos semanas o de seis. En lugar de intentar que todos lleguen a un consenso, podrías decir: "¿Y si nos comprometemos a probar ciclos de desarrollo de dos semanas y luego nos ponemos en contacto dentro de un mes para ver si esta decisión nos está ayudando a cumplir los objetivos de nuestro equipo o queremos probar otra cosa?". Esto garantiza que se tome una decisión, y crea un sentido compartido de responsabilidad para medir su éxito y ajustar el rumbo en el futuro.

No malinterpretes por completo el sentido de todo esto y digas: "Bueno, no importa si estás de acuerdo, ¡porque estamos en desacuerdo y nos comprometemos!".

Casi no me puedo creer que tenga que escribir esto, pero en algunos casos, la gente ha llevado la idea de discrepar y comprometerse hasta el ridículo extremo de ladrar a sus colegas: "NO IMPORTA QUE ESTÉIS DE ACUERDO CONMIGO: ESTAMOS DESACORDANDO Y COMPROMETIÉNDONOS". Recuerda que el propósito de discrepar y comprometerse es sacar a la luz dudas, preocupaciones y preguntas que, de otro modo, no se plantearían. Si al poner en práctica el desacuerdo y el compromiso reprendes a los posibles disidentes para que se sometan, lo estás haciendo mal.

Utilizar el desacuerdo y el compromiso para descubrir mejores soluciones

J.A.

Consultor de Gestión de Productos

Trabajaba con una pequeña consultora de California que crea productos para conglomerados de medios de comunicación. Teníamos una reunión para discutir los procesos internos, y surgió la cuestión de cómo gestionar los correos electrónicos de los clientes que llegan fuera del horario laboral. Esto había sido claramente una fuente de tensión entre el equipo, y la mayoría se calló cuando se planteó la cuestión directamente.

Finalmente, uno de los más veteranos de la empresa intervino diciendo: "Bueno, es importante que respondamos a nuestros clientes a tiempo. Así que si por casualidad ves el correo electrónico, supongo que deberías responderlo". Otra persona preguntó: "¿Pero qué pasa si hay dos personas en el hilo?". Una tercera persona se ofreció voluntaria: "Quizá lo que podamos hacer es, si ves que llega un correo electrónico fuera de horario y piensas responder a él, enviar primero un mensaje de Slack a las otras personas con copia en el mensaje, decirles que lo has recibido, y LUEGO enviar una respuesta al cliente". Hubo algunos asentimientos en la mesa. Se había alcanzado una solución colaborativa y teníamos un camino a seguir.

Pero las caras alrededor de la mesa seguían tensas y algunas personas seguían sospechosamente calladas. Acababa de aprender lo que es estar en desacuerdo y comprometerse, y me pareció un buen momento para probarlo. Les dije a todos los presentes en la reunión que tendrían que comprometerse afirmativamente con este planteamiento, y que si permanecían en silencio, yo asumiría que no estaban de acuerdo con él. A medida que avanzábamos por la mesa, la mayoría de la gente se comprometió en los siguientes términos: "Sí, estoy dispuesto a probarlo durante un tiempo y ver qué pasa". Pero una persona -la que había estado más callada durante la mayor parte de la reunión- se ofreció voluntaria: "Sí, este plan me parece bien... pero no veo por qué tenemos que enviarles un correo electrónico esa noche. Cuando un cliente me envía un correo electrónico por la noche, le respondo a la mañana siguiente. Y con el tiempo, a esos clientes se les va quitando ese comportamiento. Me envían un correo al principio de la jornada laboral en lugar de por la noche, y todo suele salir mejor porque no tengo prisa por contestarles".

La energía de la sala cambió radicalmente en ese momento: fue como si se abriera una ventana o algo así. Las personas que habían estado dispuestas a comprometerse tibiamente con el enfoque anterior empezaron a compartir historias de correos electrónicos nocturnos que habían salido mal, malas decisiones tomadas con prisas y planes de cena arruinados por unas expectativas de gestión del cliente poco claras. Todo el equipo se comprometió -con entusiasmo- a seguir un nuevo camino, y ese camino nunca habría surgido si no hubiéramos adoptado un enfoque de "desacuerdo y compromiso".

Tener en cuenta los diferentes estilos de comunicación

Para muchos gestores de productos de , el exceso de comunicación es algo natural: es parte de lo que les atrajo a la gestión de productos en primer lugar. Desde esta perspectiva, las personas menos inclinadas a hacer muchas preguntas, hablar en las reuniones o dar respuestas detalladas por escrito pueden parecer a menudo "malos" comunicadores.

En mi carrera como gestor de productos, a menudo me he sentido frustrado con personas que no comparten mi afición por la comunicación escrita extensa y el "riffing" espontáneo en las reuniones. (Para los que estéis leyendo esta última frase y penséis: "Ambas cosas suenan fatal", os entiendo y os aprecio). He tardado mucho tiempo en darme cuenta de que no se trata de una cuestión de "buena comunicación" frente a "mala comunicación", sino más bien de un reflejo de los muchos estilos de comunicación diferentes con los que probablemente te encuentres en tu carrera.

Como gestor de productos, es fundamental que recuerdes que no todo el mundo va a compartir tu estilo de comunicación. Muéstrate abierto y curioso con aquellos que inicialmente puedan parecerte malos comunicadores. He aquí algunos estilos generales de comunicación con los que me he encontrado a menudo, para ayudarte a partir de un lugar de comprensión y empatía:

Comunicadores visuales

Algunas personas no pueden captar un concepto hasta que lo han visto visualizado. Como persona que utiliza principalmente palabras para comunicarse, tardé mucho tiempo en aceptarlo. A menudo me frustraba y me encontraba utilizando más palabras cuando mis mensajes meticulosamente compuestos se encontraban con miradas vacías. Si no eres un comunicador visual, los comunicadores visuales de tu equipo pueden ofrecerte una gran oportunidad de refinar y centrar tu propio pensamiento esbozando rápidamente o creando prototipos visuales de tus ideas.

Comunicadores offline

En numerosas ocasiones , alguien se ha enfrentado a mí después de una reunión porque cree que le he puesto en un aprieto cuando simplemente intentaba implicarle en la conversación. Al principio, lo consideré una especie de actitud defensiva juvenil. Pero he llegado a aceptar que algunas personas necesitan pensar las cosas antes de hablarlas. Siempre que sea posible, avisa a los comunicadores offline de tu equipo y permíteles que reflexionen sobre una pregunta o un reto concreto antes de compartir sus ideas. Asegúrate también de que sepan de antemano si se les va a pedir que hablen o expongan en una reunión.

Comunicadores reacios a la confrontación

En el trabajo diario de la gestión de productos, recibir un "Sí" o un "Me parece bien" sin complicaciones puede parecer un momento raro y precioso de pura positividad y ánimo. Pero estas alentadoras respuestas afirmativas no siempre están motivadas por una evaluación exhaustiva y matizada de la cuestión que se plantea. Como gestor de producto, anteponer la claridad a la comodidad forma parte de tu trabajo, pero no es el trabajo de los demás, ni es su inclinación. Si necesitas la opinión de alguien cuya primera reacción parece ser siempre afirmativa, pídela de un modo que no permita una respuesta de sí o no. Acepta el reto implícito de esa persona de ser más preciso y más abierto a la hora de pedir opiniones, y probablemente te ayudará a obtener mejores opiniones de todos los miembros de tu organización.

Cuanto más puedas aprender sobre las personas concretas de tu equipo y apreciar sus estilos de comunicación individuales, mejor podrás facilitar la comunicación para tu equipo y tu organización. He descubierto que la forma más fácil de conocer el estilo de comunicación de alguien suele ser ver cómo te comunica las cosas. Por lo general, las personas transmiten la información de la forma en que la asimilan más fácilmente, y puedes crear mucha buena voluntad conociendo a las personas allí donde están.

La comunicación es tu trabajo: no te disculpes por hacer tu trabajo

Una gestión eficaz del producto requiere pedir mucho tiempo a muchas personas diferentes, lo que puede hacer que los gestores de producto se sientan como los capullos molestos que apartan a todo el mundo de su trabajo "real" y les obligan a asistir a reunión tras reunión tras reunión o a responder correo electrónico tras correo electrónico tras correo electrónico. Al principio de mi carrera como jefe de producto, hice todo lo que pude para desactivar esta situación insistiendo a mis colegas en que haría todo lo que estuviera en mi mano para asegurarme de que tuvieran que asistir al menor número (ugh) posible de reuniones. Cuando tenía que programar una reunión, la trataba como un inconveniente necesario, en lugar de como una emocionante oportunidad para que el equipo resolviera problemas importantes conjuntamente.

No me di cuenta hasta mucho después de que había creado una profecía autocumplida: cada una de las reuniones de mi equipo se trataría como una pérdida de tiempo y, a su vez, se convertiría en una pérdida de tiempo. En su libro Death by Meeting (Muerte por reunión ) (Jossey-Bass), Patrick Lencioni hace una gran observación sobre las reuniones: si la gente las aborda con una mala actitud, es probable que ningún retoque de los procedimientos las mejore. Lo mismo ocurre con el correo electrónico y otras formas de comunicación asíncrona. Si entrenas a tus colegas para que consideren tus correos electrónicos una molestia, tratarán tus correos electrónicos como una molestia. Si te quejas de estar "abrumado" con los mensajes entrantes, probablemente tus colegas se lo pensarán dos veces antes de meterte en una conversación que puede resultar crítica para el éxito de tu equipo.

Si tu equipo tiene la sensación de perder el tiempo en las reuniones, pregúntales por las mejores y más productivas reuniones a las que hayan asistido recientemente. Después, trabajad juntos para elaborar una visión clara y alcanzable de lo que es una "buena" reunión. Si tu equipo está abrumado con el correo electrónico o los mensajes de chat, trabaja con ellos para establecer expectativas más claras en torno a los canales de comunicación que utilizáis. (Hablaremos más de esto en el Capítulo 13.) No restes importancia al valor del tiempo que tu equipo dedica a comunicarse entre sí en ; en lugar de ello, asegúrate de que ese tiempo se emplea bien.

Comprender los objetivos y las motivaciones más allá de tu equipo inmediato

A.G.

Director de Producto, editorial de 500 empleados

Cuando era más joven, a menudo me frustraba cuando sentía que la gente -generalmente en otras partes de la empresa- no hacía lo correcto. Pensaba que eran imbéciles o gilipollas, que ejercían el poder para divertirse y jugar. Si hay un consejo que pueda dar a la gente que lucha con la política en el trabajo, es éste: dar por sentado que la gente es inteligente y suponer que tiene las mejores intenciones. No se trata de un mantra kumbaya cálido y difuso, sino de un consejo táctico y práctico que te ayudará a sobrevivir y prosperar como gestor de productos.

Cuando trabajaba en una editorial, me encargaron que construyera un producto que dependía de un gran volumen de contenido. Mientras tanto, el vicepresidente del área de contenidos hacía todo lo posible por restringir el contenido que podíamos utilizar. Estaba furiosa. "Es un asqueroso juego de poder, y debería avergonzarse". Mi muy sabio jefe me aconsejó que hablara con el vicepresidente. Lo hice (con calma, sorprendentemente), y él me complació con una explicación de cómo funciona realmente la adquisición de contenidos. Si me daba lo que quería, era muy probable que enfadara a nuestro socio de contenidos. De hecho, podría dejarles sin negocio. Estaba protegiendo su relación y la viabilidad a largo plazo de esa fuente. Pues bien.

No era un imbécil. Ni siquiera un imbécil. Seguía sin estar de acuerdo con la decisión, pero entendía por qué la había tomado y definitivamente no tenía por qué enfadarme por ello. Sus objetivos y, lo que es más importante, sus clientes, eran distintos de los míos. Fue una experiencia muy humilde.

Desde entonces, he trabajado en muchos otros sectores -comercio minorista, redes sociales, alimentación y bebidas- y esta dinámica se repite una y otra vez. Otras partes de la empresa suelen optimizar para cosas distintas: objetivos distintos y clientes distintos. Sé que a menudo se dice a los jefes de producto que trabajen estrechamente con su equipo inmediato, pero en cierto modo, es aún más importante conocer a la gente de otras partes de la empresa. Con tu equipo, sigues teniendo el mismo conjunto de objetivos y preocupaciones cotidianas. Pero puedes estar totalmente en desacuerdo con otra parte de la empresa y ni siquiera saberlo. Puedes estar pensando en las necesidades de tu usuario final, pero desconocer las relaciones con proveedores y socios que en realidad son fundamentales para mantener el negocio en marcha.

Y aquí está la cosa: como gestor de producto, es tu trabajo resolver todo esto. Tu función es interfuncional por definición, pero la de los demás no lo es. A ti te contrataron para ser un comunicador, mientras que a otra persona pueden haberla contratado porque se le dan muy bien las matemáticas o tiene grandes relaciones con los proveedores. La comunicación es tu trabajo, y no puedes esperar que los demás sean buenos en ello. Mis dos preguntas favoritas de son "¿Cuáles son tus objetivos?" y "¿Para qué estás optimizando?". Las utilizo a menudo y con gran sinceridad, y mi vida de gestor de productos (¡y de no gestor de productos!) es mucho mejor gracias a ello.

La sobrecomunicación atroz en la práctica: Tres escenarios comunes de comunicación para los jefes de producto

Aunque los gestores de productos pueden encontrarse comunicándose con mucha gente distinta en muchos contextos diferentes, hay algunos escenarios que tienden a presentarse una y otra vez. En esta sección, examinamos tres escenarios de comunicación habituales para los jefes de producto y cómo podrías abordar cada uno de ellos. Después de leer la configuración de cada escenario, tómate un momento para pensar cómo te inclinarías a manejarlo. Esto te ayudará a cuadrar estas sugerencias con los ritmos, personalidades y cuestiones en juego en tu contexto organizativo específico.

Escenario 1

Director de cuentas: Tenemos que construir esta función en dos semanas, o perderemos a nuestro mayor cliente.

Desarrollador: Esa función tardará al menos seis meses en construirse si queremos hacer algo que sea remotamente estable y eficaz.(Figura 4-1)

Figura 4-1. Una petición de "emergencia" se topa con un rechazo técnico

Lo que realmente ocurre

Éste es un caso clásico y habitual de incentivos mal alineados en . El trabajo del gestor de cuentas es retener a los clientes. El trabajo del desarrollador es crear un software que no sea vergonzoso, que no tenga errores y que se mantenga unido con cinta adhesiva y cuerdas. El gestor de cuentas no está directamente incentivado para preocuparse por cosas como si el software es eficaz. El desarrollador, por otra parte, (normalmente) no está directamente incentivado para preocuparse de si se mantiene al cliente; en todo caso, un cliente menos irrazonable es un conjunto menos de demandas de última hora. Tanto el gestor de cuentas como el desarrollador defienden sus respectivos objetivos a corto plazo.

Qué puedes hacer

Hay múltiples suposiciones en juego, tanto en la posición del gestor de cuentas como en la del desarrollador. ¿Necesita realmente este cliente exactamente esta función? ¿Perderemos realmente al cliente si no la construimos? ¿Comprende plenamente el desarrollador la necesidad del cliente, o está utilizando el plazo de seis meses como una forma más defendible de decir que no? En lugar de debatir la función concreta que pide tu gestor de cuentas, profundiza en el problema fundamental que tiene el cliente. Involucra al gestor de cuentas como socio para comprender mejor las necesidades del cliente y al desarrollador como socio para explorar posibles soluciones. Puede que descubras que no hace falta ninguna función nueva, sino una conversación rápida con el cliente para ayudarle a comprender mejor una función existente.

Patrones y trampas a evitar

Bien, decidamos si estamos ante dos semanas o seis meses.

Tanto dos semanas como seis meses pueden ser plazos totalmente arbitrarios. El gestor de cuentas podría haber dicho "dos semanas" como abreviatura de "muy pronto", y el desarrollador podría haber contraatacado con "seis meses" como forma de decir: "Diablos, no, no quiero trabajar en eso". Evita la falsa elección y ve al meollo de la cuestión.

Sí, estoy de acuerdo en que tenemos que resolver esto en dos semanas. Y estoy de acuerdo en que el software debe ser eficaz y estable.

¡No intentes jugar a dos bandas! Esto sencillamente no funcionará. Es probable que haya oportunidades de pasar a una conversación más orientada a los objetivos, y es tu trabajo como gestor de producto facilitar esa conversación. En el mejor de los casos, descubrirás una solución que lleve menos de dos semanas y que suscite mínimas preocupaciones sobre el rendimiento y la estabilidad. Mantén la conversación abierta y exploratoria, pero no intentes ganar puntos rápidamente diciéndole a la gente lo que quiere oír.

Nuestro proceso de planificación tiene lugar cada dos semanas, y estamos a tope. Vuelve más tarde.

Si trabajas en un mundo de iteraciones fijas verdaderamente, a menudo se evitan a toda costa adiciones de última hora como ésta, y hay buenas razones para mantener estos guardarraíles. Pero las buenas razones a menudo no impiden que lleguen estas peticiones, y he encontrado generalmente más útil tener un proceso para evaluarlas y priorizarlas, en lugar de rechazarlas por completo. (Hablaremos más de esto en el Capítulo 12, "Priorización: Donde todo confluye").

Escenario 2

Diseñador: He hecho cuatro versiones distintas de este diseño, ¿cuál te gusta más?(Figura 4-2)

Figura 4-2. Un diseñador presentando múltiples opciones

Lo que realmente ocurre

El diseñador podría haber creado cuatro versiones que considera igualmente adecuadas para los objetivos del proyecto, pero con diferencias subjetivas (como la elección del color) en las que no tiene un punto de vista firme. O puede que el diseñador no tenga claros los objetivos del proyecto e intente aplazar la responsabilidad obligándote a elegir. O puede que el diseñador tenga un enfoque que realmente espera que elijas y haya creado unas cuantas opciones "ficticias" para crear la ilusión de elección.

Qué puedes hacer

Esta es una oportunidad para que demuestres tu confianza en el diseñador preguntándole qué opción cree que se ajusta mejor a los objetivos del proyecto. Si cree que una opción es claramente superior, esto le incita a pensar en esa opción en el contexto de los objetivos y no de las preferencias. Y, si no tiene una preferencia clara, puede que os obligue a ambos a mantener una conversación sobre si los objetivos del proyecto están suficientemente claros. Si hay varias opciones que parecen igualmente viables, podrías discutir con tu diseñador cómo podríais probar esas opciones para ver cuál cumple mejor los objetivos del proyecto. Al fin y al cabo, tu equipo puede tener opiniones diferentes, pero siempre debéis tener los mismos objetivos.

Patrones y trampas a evitar

Me gusta la opción B, ¡vamos con ella!

Es una respuesta fácil y tentadora. Al fin y al cabo, el diseñador te ha preguntado qué piensas. En algunos casos, la pregunta es realmente así de sencilla: al diseñador no le importa y sólo quiere que elijas entre unas cuantas variaciones subjetivas. Pero es mejor que profundices un poco más que precipitarte a tomar una decisión sin un conjunto claro de razones más allá de tu preferencia personal.

Presentemos las cuatro a todo el grupo y ¡a ver qué opinan!

Durante mucho tiempo, ésta fue mi estrategia, hasta que un reflexivo diseñador de UX me informó de que estaba llevando a nuestro diseñador visual hasta el punto de renunciar con el "diseño por comité". No hay nada peor que tener a un montón de gente soltándote sus opiniones sobre el trabajo para el que te contrataron.

Me da igual. El que tú quieras está bien.

Es muy raro que alguien se esfuerce en hacer algo cuatro veces distintas, a menos que haya un motivo. No descartes ese esfuerzo -y los problemas más profundos que puedan subyacer a él- negándote a participar.

...Y una pregunta extra

¿Y si el diseñador sólo me diera una opción?

Evita la tentación de lanzarte inmediatamente a una crítica, aunque te parezca una crítica generosa. En lugar de eso, pide al diseñador que te explique cómo ha llegado al diseño. Esto te dará la oportunidad de aprender más sobre cómo entiende el diseñador los objetivos generales del proyecto, y podría revelar uno o dos sutiles fallos de comunicación que podéis solucionar.

Escenario 3

Desarrollador: Lo siento, es que no entiendo por qué intentas obligarnos a seguir todo este proceso innecesario. ¿Puedes dejarme hacer mi trabajo?(Figura 4-3)

Figura 4-3. Un promotor protestando por un "proceso innecesario"

Lo que realmente ocurre

Aunque frases como "Este proceso es demasiado pesado para nosotros", "No quiero seguir todos estos pasos innecesarios" o "Esto es una gilipollez corporativa de gran empresa" puedan parecer refunfuños genéricos de los reacios al proceso (hablaremos más de ello en el Capítulo 7), son señales importantes y valiosas de que tienes trabajo por hacer. Si tu equipo no se siente implicado en tu proceso de desarrollo, y/o si considera que ese proceso es un impedimento para realizar su trabajo, es posible que hayas fracasado fundamentalmente en tu papel de comunicador y facilitador, aunque hayas conseguido que tu equipo adopte formalmente un determinado marco o proceso de desarrollo.

Qué puedes hacer

Ante todo, tómate en serio los comentarios de tu desarrollador. Agradécele su franqueza y deja claro que tu equipo sólo puede tener éxito si la gente comparte abiertamente sus preocupaciones. En lugar de intentar resolver sus preocupaciones en una conversación individual, pregúntale si puede repetir sus comentarios en la próxima reunión del equipo. Esto ayudará a establecer que no pretendes ser el ejecutor brutal de los procesos de tu equipo, sino más bien un facilitador que ayuda al equipo a identificar y adoptar los procesos que mejor se ajusten a sus objetivos.

Patrones y trampas a evitar

Pruébalo durante un tiempo: ¡te prometo que te hará la vida más fácil!

Hay una distinción sutil pero crítica entre "Te prometo que esto funcionará" y "Colaboremos para que esto funcione". Pedir a cualquier miembro de tu equipo que acepte acríticamente los cambios del proceso es un gesto fundamentalmente despectivo, no un gesto conectivo y de apoyo. Si tu equipo no se siente implicado en su proceso, es probable que éste fracase.

Tienes razón. Olvídate de estas cosas del proceso: ¿en qué quieres trabajar?

Aunque dar rienda suelta a los ingenieros para que trabajen en lo que quieran puede parecer un gesto de empoderamiento o, al menos, de deferencia adecuada, en última instancia les deja profundamente desconectados del impacto de su trabajo de cara al usuario y a la empresa. Al final, alguien va a pedir cuentas a tu equipo por los resultados reales de lo que construyen. Y cuanto más tiempo pase tu equipo sin ningún tipo de proceso que conecte el trabajo que están haciendo con los objetivos de tu organización, peor será ese día de rendición de cuentas.

Lo sé, lo sé, soy lo peor, pero mi jefe dijo que debíamos poner en marcha algún proceso más. Te prometo que intentaré que sea lo menos doloroso posible.

Como ya hemos dicho, el autodesprecio es un mecanismo de supervivencia habitual de los jefes de producto. Pero si te consideras un peón involuntario en el empeño de otra persona por inculcar procesos sin sentido, estás garantizando que el proceso carezca de sentido. Si no crees que el proceso que estás utilizando sea el correcto, pero, oye, tu jefe de te pidió algún proceso, es hora de que tengas una conversación incómoda con tu jefe.

Resumen: ¡En caso de duda, comunica!

El trabajo diario de la comunicación requiere atención, adaptabilidad y matices. Pero las decisiones más importantes que tomes como director de producto a menudo se reducirán a esta sencilla pregunta: ¿estás dispuesto a plantear algo que puede parecer obvio, incómodo o ambas cosas? Cuanto más valiente seas a la hora de iniciar estas conversaciones -y cuanto más espacio crees dentro de tu equipo y organización para que estas conversaciones se desarrollen- más éxito tendréis tú y tu equipo.

Tu lista de control

• Peca de exceso de comunicación. Cuando no estés seguro de si merece la pena mencionar algo, menciónalo.

• No tengas miedo de preguntar "lo obvio". De hecho, cuanto más obvio parezca algo, más insistente debes ser para asegurarte de que todo el mundo está de acuerdo.

• Crea un documento como "Buen gestor de productos/Mal gestor de productos" que establezca claramente las expectativas de comportamiento de los gestores de productos de tu organización.

• Evita empezar las frases con expresiones como "Sería estupendo si..." o "¿Crees que sería posible...?", que desvían la responsabilidad. Si pides algo, pídelo, y explica claramente por qué lo pides.

• Intenta volver a centrar las conversaciones sobre las emociones y las intenciones en torno a los resultados, haciendo preguntas como "¿Esta situación produjo el resultado deseado?"

• No olvides nunca que "parece que está bien" a menudo significa "no estoy prestando atención", y busca siempre un feedback y una aceptación comprometidos, afirmativos y específicos.

• Asegúrate de que se da a la gente la oportunidad de expresar sus opiniones en las reuniones utilizando "discrepa y comprométete" o cualquier otro enfoque que consiga objetivos similares en tu organización.

• Recuerda que las personas tienen estilos de comunicación diferentes. No taches a nadie de "mal comunicador" ni asumas que tiene malas intenciones si su estilo es distinto del tuyo.

• Evita la tentación de ser un "odiador de reuniones" o un "odiador de correos electrónicos". No te disculpes cuando pidas tiempo a alguien, pero asegúrate de que su tiempo está bien empleado.

• Pregunta a tus compañeros de equipo por las reuniones más valiosas y bien gestionadas a las que hayan asistido. Luego trabaja con ellos para establecer una visión clara de lo que es para ti una "buena" reunión.

• Eleva el nivel de las conversaciones tácticas sobre cosas como las opciones de diseño o los plazos de desarrollo a conversaciones estratégicas sobre los objetivos empresariales y las necesidades de los usuarios.