Motivación en equipos de producto

Técnicas e ideas prácticas sobre cómo motivar a equipos de producto desde la posición de Product Manager.

Un equipo motivado es un equipo feliz. Un equipo feliz es más creativo, proporciona mejores soluciones y por si fuera poco también es más productivo. 

En el post de hoy me gustaría introducir algunas técnicas e ideas que he ido refinando durante los últimos 20 años enfocadas a la motivación de equipos de producto.

Photo by Ian Schneider on Unsplash

Embárcalos en una misión.

“You want a team of missionaries, not mercenaries.” — Marty Cagan.

La diferencia entre un misionero y un mercenario es que el primero está allí por convicción, mientras el segundo podría estar allí como podría estar en cualquier otro sitio.

El producto resultante de tener un equipo formado por unos u otros variará enormemente. Es por eso que una de las prioridades de cualquier Product Manager debe ser articular una misión inspiradora a la que el equipo se quiera sumar.

Para construir esta misión nos podemos apoyar en múltiples frameworks. En Voicemod utilizamos uno que recomiendo proveniente de LinkedIn llamado Vision-to-Values. Independientemente del que utilicemos, el objetivo debería ser poder responder en una página a las siguientes preguntas:

• Visión: ¿Para qué existimos? ¿Cuál es el objetivo aspiracional del equipo?

• Misión: ¿Qué hacemos para conseguir ese objetivo?

• A quién servimos: ¿Quiénes son nuestros usuarios?

• Prioridades: En el caso de que haya varias, ¿cuáles son las más importantes?

• Métricas: ¿Cómo sabemos si avanzamos en los objetivos?

Por supuesto, este documento no puede llover del cielo. Es vital que el Product Manager haga el trabajo necesario para entender las expectativas de la empresa respecto al equipo, y que todo éste participe en su definición y su confección.

Cuéntales el problema. No les des la solución.

“If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.” — Albert Einstein.

A poco que hables con cualquier equipo de producto experimentado hoy en día, uno de los mensajes que más vas a escuchar es “tráenos problemas, no soluciones”.

Y este es, quizás, uno de los retos más importantes para cualquier Product Manager. Abrazar el problema tan íntimamente que la solución nos parezca evidente, pero al mismo tiempo dejar la especificación en un nivel de detalle lo suficientemente alto para que sea el equipo el que asuma encontrar la solución.

Nuestro trabajo consiste en guiar al equipo en el espacio del problema, en asegurarnos que se contemplan todos los escenarios, y en validar que la solución propuesta satisfará las necesidades del usuario. 

Si no lo hacemos así, si invertimos nuestro tiempo en escribir especificaciones infinitamente detalladas sin dejar ningún margen a la imaginación, ¿para qué querríamos a un equipo de ingenieros de producto? Los ingenieros que necesitan trabajar así están en consultoras que venden su carne por hora. Son reemplazables. Los buenos ingenieros exigen participar en las soluciones. Rodéate de estos.

Dales autonomía.

“Control leads to compliance; autonomy leads to engagement.” — Daniel H. Pink.

Los mejores equipos de producto se autoorganizan. No necesitan una figura paternal que esté vigilando que siempre estén produciendo al 100%. Todavía no he visto un equipo de producto motivado que no esté siempre entregando al máximo de su capacidad. La diferencia es que lo hacen en las cosas que verdaderamente importan. 

No tenemos que olvidar nunca que, como Product Managers, nuestro foco es obtener valor del equipo, no puntos de historia. Un equipo puede hacer 200 puntos de historia por sprint y no estar aportando ningún valor, o incluso restándolo. 

En contraposición, un equipo caótico, que no siga ningún proceso aparentemente lógico puede estar aportando un valor inmenso a la empresa. Creedme. Este equipo es mucho más importante para la compañía que el primero. 

Protege su tiempo.

“Time isn't the main thing. It's the only thing.” — Miles Davis.

El desarrollo de producto es una actividad que requiere de grandes espacios de tiempo de trabajo sin interrupciones. Protege a tu equipo a toda costa de reuniones innecesarias. 

Aprovecha el daily standup para hacer las preguntas que necesites. Es mejor que el daily del día siguiente se alargue 10 minutos, que romper el flow de todo el equipo a mitad del día para resolver una duda. 

Concentra las reuniones en una franja horaria concreta del día. Después del daily es un buen momento. Nunca sobrepases esa franja. Si una reunión se alarga más de una hora, intenta cortarla, probablemente no esté siendo productiva. 

Declara días sin reuniones en los que el equipo pueda enfocarse 100% en el desarrollo. Ninguna reunión es tan urgente que no pueda esperar al día siguiente. 

No confundas proteger el tiempo del equipo con aislarlos del cliente. Tu función no es ser cuello de botella y actuar de filtro para todo lo que llega. Tu misión es conectar al equipo con el problema, y eso incluye ponerlos en contacto directo con los usuarios. Esas reuniones son las que verdaderamente aportan valor. Foméntalas. 

Si tu Tech Lead o tu Engineering Manager conectan directamente con el cliente para solucionar una duda y sólo te enteras días después es que estás haciendo bien tu trabajo. La mejor sensación del mundo es cuando tu equipo es lo suficiente maduro como para desintermediarte. 

Estás presente.

"Be present above all else." — Naval Ravikant.

Un buen Product Manager está presente cuando se le necesita. Cualquier miembro del equipo puede tener una duda en un momento dado. Es importante que el Product Manager esté ahí para resolverla. 

Si hemos hemos entendido el problema íntimamente, la respuesta será evidente. En aquellos casos en los que no lo sea, reconócelo sin ambigüedades. A veces un “no lo sé” da más confianza que una respuesta claramente improvisada. 

Conecta con el equipo constantemente para entender sus preocupaciones y motivaciones. Personalmente cada dos semanas tengo un 1-on-1 con cada uno de los miembros del equipo. Entiende qué les motiva y poténcialo. Corrige el rumbo en aquellas cosas que no están funcionando. Cada equipo es un mundo, no hay patrones mágicos. Adapta tu forma de trabajar a lo que necesite el equipo y no al revés. 

Fomenta los ciclos de feedback rápidos.

“If you’re smart, you often want a feedback loop so you know if what you’ve done is right.” — Bill Gates.

Escoge siempre la ruta más corta para validar que lo que estáis haciendo aporta valor. Como norma general invertir más de mes y medio en cualquier iniciativa sin llevarla a producción es una receta segura para que el equipo se desmotive.

Si algo es demasiado grande, trocéalo de forma que seis semanas puedas estar validando. Lo perfecto es enemigo de lo bueno. 

Evita caer en la trampa de los costes hundidos. Cuánto más tiempo pases desarrollando algo, más te costará abandonarlo si no funciona. Si funciona siempre, es que no estamos yendo lo suficientemente rápidos. Desarrolla pequeño, valida e itera.

Los errores son tuyos, los éxitos del equipo.

“Only those who dare to fail greatly can ever achieve greatly.” - Robert F. Kennedy.

Cuando tengáis éxito, ensalza públicamente el trabajo la contribución del equipo y quédate al margen. Cuando haya un problema, sé el primero en responsabilizarte del mismo. 

Los problemas se resuelven internamente, no se airean públicamente. Tu equipo te respetará si lo haces, y desconfiará de ti si ante cualquier problema les haces responsables y les dejas en evidencia.

Nadie dijo que esto fuera fácil.

Mantén buenas relaciones con los managers de equipos.

“Succeding in business is all about making connections.” — Richard Branson.

En un mundo ideal todos los equipos serían 100% autónomos y podrían avanzar sin dependencias. En el mundo real habitualmente dependes de otros equipos para poder progresar.

Esfuérzate por conocer y mantener buenas relaciones con los managers de esos otros grupos. Ingeniería, Diseño, DevOps suelen ser los sospechosos habituales. 

Mantén una comunicación fluida con ellos, entiende sus preocupaciones y ayúdalos en lo que puedas para que ellos puedan ayudar al equipo cuando éste lo necesite. 

Reserva tiempo para atajar deuda técnica.

“Left unchecked, technical debt will ensure that the only work that gets done is unplanned work!” — Gene Kim.

Deberías reservar al menos un 15% del tiempo del equipo para limpiar deuda técnica. Si no lo haces, la base de código empeorará paulatinamente afectando a la motivación y lo que es más importante, a la capacidad de entregar valor.

Hay muchas formas de hacerlo. Personalmente me gusta la idea de reservar un sprint completo para deuda técnica después de cada trimestre. Por una parte, el equipo puede planificar ese sprint como si de cualquier otro se tratara escogiendo aquellos puntos más importantes a atacar. Por otro lado, permite desconectar respecto a la presión habitual del desarrollo en el día a día. 

Concluyendo.

El rol de Product Manager ya es lo suficientemente complicado como para además hacerlo con un equipo desmotivado. Hoy hemos visto algunas ideas sobre cómo podríamos mejorar la motivación de nuestros equipos:

• Embarcándolos en una misión.

• Contándoles el problema, no dándoles una solución.

• Dándoles autonomía para decidir cómo organizarse.

• Protegiendo su tiempo frente a interrupciones innecesarias.

• Estando presentes ante cualquier duda.

• Fomentando ciclos de feedback rápidos.

• Absorbiendo los errores y deflactando el éxito al equipo.

• Manteniendo buenas relaciones con los managers de otros equipos.

• Reservando tiempo para limpiar deuda técnica.

En cualquier caso, no cometas el error de aplicarlas sin más. Si detectas problemas de motivación, empieza entablando conversaciones uno a uno con los miembros del equipo para entender qué puede estar pasando. 

De forma general, los equipos más junior necesitarán más apoyo y serán menos independientes que los senior. Entiende en qué punto está tu equipo y ayúdalo a convertirse en un auténtico equipo senior de producto.

Por tu equipo. Por tu empresa. Por ti.