Cuando empecé a trabajar como Product Manager, la comunicación con los desarrolladores se hacía un poco cuesta arriba.
Seamos sinceros: cuando somos Product Managers o Product Owners formados en una escuela de negocios o algo similar y no tenemos conocimientos técnicos, es fácil que nos perdamos —incluso que nos asustemos— al escuchar el lenguaje de los desarrolladores, ese extraño espanglish lleno de de siglas de todo tipo.
¡Ojo! Con este artículo no te estamos diciendo que formes en código, pero sí te enseñaremos a comunicarte con eficacia para mejorar la productividad y la creatividad de tu equipo ágil. ¿Cómo hacerse entender? ¿Cómo dominar la jerga técnica para cazar esas valiosas ideas de los desarrolladores?
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Como todo buen Product Manager, yo mismo cometí varios errores en mis inicios. Estos son los puntos en los creo que deberías fijarte:
Hablar tu propio idioma, o hablar para ti mismo
El primer error es no saber comunicarse con un lenguaje común entre la empresa y la parte técnica. Yo solía ser ese tipo de responsable de producto que se ceñía demasiado a las expresiones de moda, y que nunca hacía un discurso claro para el público más técnico.
Por ejemplo:
«Necesitamos una aplicación que se ocupe de los rechazos de las delegaciones en Santé Collective»
frente a
«Necesitamos una aplicación que pueda comprobar si un determinado contrato tiene n criterios impuestos por la ley X»
También me viene a la cabeza el uso de un lenguaje confuso lleno de términos que a menudo tienen un significado completamente diferente en un contexto técnico: «incrementar», «archivar», «historizar», «desplegar». Recordemos que aquellas formulaciones que a algunos nos pueden parecer obvias no lo son necesariamente para otros.
Y lo que pasaba era sencillo: «a palabras necias, oídos sordos».
Si no te expresas con claridad, no puedes esperar que te entiendan. Corres el riesgo de que malinterpreten tu mensaje, haciendo perder el tiempo a todo el mundo.
En su lugar, prueba a hacer esto:
- Explica las cosas con palabras sencillas que todos los miembros del equipo puedan entender.
- Reformula sistemáticamente todo lo que se te dice para despejar las posibles dudas.
- No compliques las cosas con conceptos que solo tienen sentido para ti.
- No utilices conceptos técnicos que no dominas. Tu equipo te recordará ese fallo. Sé curioso, haz tantas preguntas como puedas.
- Crea un glosario común.
Hacer peticiones injustificadas
Este es el error más común que cometen las empresas que todavía consideran a su equipo de desarrollo como una especie de apoyo auxiliar para su negocio. Las solicitudes que se les plantean a los desarrolladores sin ningún objetivo o propósito específico.
Por ejemplo:
«Queremos añadir esta función porque está de moda. ¡Todo el mundo lo hace!»
frente a
«Queremos probar esta función, que está demostrando ser una buena práctica del sector, y comprobar si mejora realmente nuestros problemas de retención»
Lo mismo ocurre con las limitaciones de tiempo que se imponen sin haberse tomado la molestia de darse cuenta del alcance de las tareas que implica un determinado desarrollo.
«Queremos que esta función se extienda a todos los dispositivos para Navidad»
frente a
«El departamento de monetización nos impone un time to market para la Navidad, ya que es cuando se realizan más compras. ¿Qué versión de la funcionalidad podemos considerar con ese plazo?»
Ante esta falta de racionalidad, es muy normal que tu equipo coja la costumbre de desacreditar tus peticiones. También hay que entender que los desarrolladores están muy interesados en recibir comentarios y otros KPI sobre las características que se han puesto en producción. Da un paso atrás y trata de:
- Formular tus peticiones en forma de problemas. Esto permitirá que el equipo sea más creativo y proponer soluciones alternativas con mayor facilidad.
- Pedir una evaluación de la carga de trabajo para las diferentes versiones de tu funcionalidad antes de anunciar una fecha límite que podría añadir un estrés adicional innecesario (Extreme quotation, por ejemplo).
Usar un tono paternalista
He dudado mucho antes de añadir este punto, pero al ver que muchos Product Managers siguen expresándose de una forma paternalista, quiero recordarles lo importante que es la humildad en cualquier trabajo colaborativo.
Si usas un tono de voz y demuestras una actitud que haga pensar a tus desarrolladores que trabajan para ti y no contigo, te enfrentarás al menos a uno de los siguientes problemas: falta de espíritu de equipo, frustración general, omisión de información, espíritu competitivo poco sano.... ¿Es productivo que un desarrollador tenga resentimiento? No, así que intenta plantearte un reto:
- Exprésate como miembro de pleno derecho del equipo.
- No le digas a los demás lo que no quieres que te digan a ti.
- Y si eres capaz, prueba con una actitud más natural y desenfadada.
Espero haberte ayudado a ver que la comunicación de un Product Owner o Product Manager es muy importante dentro de un equipo ágil. Tienes los medios para que las interacciones entre los equipos sean agradables y conseguir la máxima creatividad de tus colaboradores con unas pocas palabras bien dichas.
Para saber más: descarga el libro Agile Product Management
Foto de Annie Spratt en Unsplash
