10 claves para un desarrollo de productos exitoso
Hace exactamente un año fui invitado a la Craft Conference en Budapest y hablé allí sobre las 10 principales razones por las que fracasan los equipos de producto. Hablé principalmente de por qué muchos equipos son tan ineficaces y, a pesar de todas las afirmaciones en contrario, la mayoría de las organizaciones aún no son realmente "ágiles", ya que siguen trabajando según el principio de cascada. Así que este año me invitaron nuevamente a la conferencia para hablar sobre cómo trabajan los mejores equipos que conozco. Este artículo es un resumen de mi charla.
Después de mi primera charla, algunas personas me contactaron pidiéndome más información. Aparte de recomendarles leer mi libro o participar en un taller, no sentía que pudiera darles una respuesta satisfactoria. Eso me inspiró a pensar más detenidamente sobre las características más importantes de los equipos de producto extremadamente fuertes. Así que elaboré mi Top 10 personal.
Continuous Discovery y Delivery
Al igual que describí los diez mayores problemas del modelo en cascada, también he descrito las diez características de los equipos exitosos en relación con Continuous Discovery y Delivery (también llamado Dual Track Agile, Discovery Sprints o Delivery Sprints). ¿Cuáles son los factores de éxito para un desarrollo de productos exitoso?
1. Equipos de producto empoderados
El factor más importante es el concepto absolutamente fundamental de los equipos de producto fuertes. Pero, ¿qué significa exactamente?
En primer lugar, es importante que el equipo exista a largo plazo en esta configuración y que los miembros del equipo no sean movidos como piezas de ajedrez. Si los equipos deben ser innovadores, necesitan tiempo para aprender más sobre sí mismos, la tecnología, los clientes y el contexto empresarial.
En segundo lugar, la química entre los miembros del equipo es crucial. Esto significa que deben conocerse y respetarse lo suficiente para que cada miembro del equipo se sienta cómodo y se atreva a proponer cosas, así como a motivarse a sí mismos y a los demás a rendir mejor constantemente.
En tercer lugar, un equipo debe tener una cierta diversidad de habilidades, que normalmente consiste en gestión de producto, diseño de experiencia de usuario y desarrollo. A menudo también incluye análisis de datos e investigación de usuarios.
Y por último, es ventajoso que todos los miembros del equipo trabajen juntos en el mismo lugar, aunque para muchas empresas este no es un tema fácil. Los product managers, diseñadores de producto y los desarrolladores (o al menos el líder del equipo de desarrollo) deberían tener sus escritorios uno al lado del otro. Lamentablemente, esto no siempre es viable, pero al menos se puede intentar. Y solo para aclarar, no son los equipos individuales en diferentes lugares lo que representa un problema. Lo que tiene un impacto negativo en la Velocity y, sobre todo, en la innovación es cuando los miembros del mismo equipo están separados geográficamente.
2. Visión y estrategia de producto
Para tener equipos de producto verdaderamente empoderados y autónomos, los miembros del equipo necesitan una buena comprensión del contexto empresarial. Esto comienza con una visión de producto clara y convincente y el camino hacia ella: la estrategia de producto.
La visión de producto describe el mundo que queremos crear en los próximos dos a cinco años (en hardware generalmente un poco más).
La visión de producto debe ser inspiradora. Una buena visión de producto es una de nuestras herramientas de reclutamiento más eficaces y motiva a las personas a ir a trabajar todos los días. Una visión inspiradora atrae buenos profesionales, porque quieren ser parte de algo significativo.
La estrategia de producto es la secuencia de productos que queremos entregar en el camino hacia la realización de la visión. Sería una mala estrategia intentar satisfacer a todas las partes interesadas con un solo Release. En cambio, tenemos una lista priorizada de mercados, geografías o personas y nos enfocamos en que el producto y el respectivo mercado encajen.
Cuantos más equipos de producto se tengan, más importantes son una visión y estrategia unificadas para que cada equipo individual pueda tomar las decisiones correctas.
Lo más importante es que la visión de producto sea inspiradora y que la estrategia de producto sea tomada de forma consciente.
3. Business Outcome
La segunda parte del contexto empresarial que un equipo empoderado y autónomo necesita para tomar buenas decisiones es un conjunto de objetivos de negocio priorizados. El sistema OKR (Objectives and Key Results) está diseñado exactamente para esto.
Los OKR reflejan una lista de problemas de negocio específicos que el equipo debe resolver. Sin embargo, estos no son features. Los features son solo soluciones potenciales para problemas. Completar un feature no hace exitoso a un equipo; sino la resolución del problema real.
Los dos principios detrás de estos métodos de gestión del rendimiento son:
1) Los equipos rinden mejor cuando se les dan problemas para resolver por sí mismos, en lugar de prescribirles las soluciones.
2) El equipo se mide por resultados, no por output. Entregar features de una hoja de ruta es output; resolver un problema de negocio es un resultado.
4. Un product manager competente
Lamentablemente, la mayoría de los desarrolladores nunca han tenido la oportunidad de trabajar con un product manager capaz. Aquellos que sí la han tenido son también los que insisten en tener siempre a una persona así en el equipo. Y aún peor es el hecho de que muchos desarrolladores ni siquiera saben exactamente qué debe aportar el product manager al equipo.
Imagina todo esto de la siguiente manera: para que un equipo de producto resuelva problemas de negocio reales, no basta con que una solución solo funcione técnicamente o que al cliente le encante. La solución también debe funcionar para tu negocio, y eso suele ser lo más difícil.
Piensa en lo que eso significa. Imagina que trabajas para Uber o AirBnB y tienes que lidiar con leyes complejas, grupos de empleadores y sindicatos. O piensa en eBay, donde había restricciones considerables para ser clasificado como un marketplace en lugar de un sitio de e-commerce. O Tesla, donde había cuestiones de responsabilidad sobre el Autopilot que resolver. Cada empresa tiene su propia lista de obstáculos que superar:
Obstáculos legales, financieros, relacionados con ventas y precios, así como obstáculos de marca y marketing, privacidad de datos, seguridad, condiciones de cooperación, etc.
Desafortunadamente, la única persona que entiende todo esto es el director general, y en este caso se puede comprender por qué le resulta tan difícil empoderar al equipo para que tome las decisiones correctas por sí mismo.
Hay tres formas en que un equipo puede trabajar. Una es que el director general u otro superior decida todo. La segunda es que un product manager convoque una gran reunión y discuta todo con toda la dirección ("Design By Committee"), lo que generalmente produce malos resultados. La tercera opción es que el product manager haga su trabajo, se ocupe de los obstáculos y los transmita a los miembros del equipo para que ellos mismos elaboren la solución del problema.
Combina eso con un buen entendimiento de la tecnología y un conocimiento sólido de los usuarios y clientes, y entonces podrás ver por qué este es un trabajo duro pero absolutamente esencial para un equipo de producto, especialmente si el equipo debe disfrutar de un grado significativo de autonomía.
5. Soluciones a través de la colaboración
"Colaboración" no debe ser una palabra de moda aquí. Solo quiero decir que las tres áreas de producto, diseño y desarrollo deberían trabajar juntas para resolver un problema, en lugar de que el product manager pase "requisitos", el diseñador lo empaquete todo bonito y los desarrolladores escriban el código que se les pide. La razón es que en las buenas soluciones, la tecnología y la funcionalidad se impulsan mutuamente. La tecnología hace posibles ciertas opciones de diseño, al igual que el diseño influye en la selección de la tecnología. Y las decisiones de diseño influyen en la funcionalidad, y viceversa.
Tecnología, diseño de experiencia de usuario y funcionalidad están entrelazados. Las buenas soluciones surgen de un constante ir y venir, un permanente dar y recibir entre las tres áreas.
Esta es también la razón principal por la que los equipos que trabajan juntos en el mismo lugar son fundamentalmente siempre mejores que los equipos donde esto no es el caso.
6. Product Discovery: Aprendizaje rápido
Los grandes productos tienen mucho que ver con la capacidad de un equipo para probar rápidamente muchas ideas. Queremos separar lo más rápido posible las buenas ideas de las malas. Product Discovery abarca toda una serie de técnicas que nos ayudan a descubrir rápidamente qué ideas son geniales y cuáles no tanto. Algunas ideas son realmente geniales y otras menos. Algunas son arriesgadas y otras costosas. A veces necesitamos pruebas y otras veces solo indicios.
La gente lo describe de las formas más diversas. Algunos se ciñen al dicho "fake it before you make it", que significa algo así como "simula hasta que funcione". Otras personas enfatizan que se deben construir cosas que no sean escalables. Lo principal es que aprendamos rápido y minimicemos el desperdicio.
Hacer que un equipo de desarrollo construya un producto real y lo lance al mercado para probar una idea es prácticamente el método más lento y costoso de aprender.
7. Concentrarse en los riesgos principales
En el Product Discovery hay algunos puntos importantes que se deben tener en cuenta.
Primero, necesitamos concentrarnos en los cuatro riesgos principales:
Valor – ¿alguien compraría o querría usar este producto?
Usabilidad – ¿los clientes entenderían cómo usarlo?
Factibilidad – ¿pueden nuestros desarrolladores construir el producto con la tecnología, el tiempo y las habilidades del equipo disponibles?
Stakeholders – ¿están todos los involucrados en la empresa de acuerdo con la solución propuesta?
Product Discovery es la búsqueda de buenas respuestas a estas cuatro preguntas. Cuando las encontramos, tenemos las evidencias necesarias y estamos seguros de que el equipo de desarrollo puede implementar y entregar una solución de calidad y escalable.
8. El rol del MVP
El concepto del Minimum Viable Product es uno de los conceptos más importantes en el desarrollo de productos y, sin embargo, también es uno de los conceptos más mal utilizados y malentendidos.
Generalizar siempre es peligroso, pero me arriesgo a afirmar que un MVP nunca debería ser un producto. Cada vez que me encontré con un equipo que había construido un MVP con mucho tiempo y dinero, luego pude mostrarles cómo podrían haber logrado el mismo aprendizaje con mucho menos costo y mucho menos desperdicio.
Un MVP es entonces un experimento, una prueba. Normalmente es una especie de prototipo. A menudo es un prototipo para el usuario, a veces un prototipo con datos en vivo o se utiliza para estudios de factibilidad. Y a veces es una mezcla de estas cosas. En cualquier caso, siempre es solo una pequeña parte del desarrollo de un producto real.
9. Product Delivery: Sin compromisos en el release
Aquí no se trata de decirles a los desarrolladores cómo deben desarrollar y lanzar software. Al contrario. Un problema que surge cuando un equipo de desarrollo tiene que desarrollar el MVP es que a menudo se siente obligado a lanzar software de la que no está convencido. No están realmente comprometidos al cien por cien. Quizás hay problemas de fiabilidad, escalabilidad o rendimiento, pero el product manager simplemente sigue diciendo: "¡Es solo un MVP, relájense!"
Simplemente digo que no se deben hacer compromisos cuando se trata de software de la que los clientes dependen para mantener su negocio. Hay muchas buenas técnicas de Product Discovery para probar MVPs que protegen a nuestros clientes, nuestros ingresos, nuestra reputación y nuestros empleados.
Así que utiliza tus mejores prácticas y solo lanza productos cuando tengas plena confianza en ese release.
10. Estar obsesionado con el cliente
Este último punto va en una dirección un poco diferente. En casi todas las empresas a las que llego, me dicen cuánto aman a sus clientes. Eso suele ser parte de los valores o la declaración de misión de la empresa. Decirlo es fácil, pero actuar realmente en consecuencia es mucho más difícil.
Eso lo noto bastante rápido cuando hablo con un equipo. ¿Cómo maneja el equipo cuando surge un problema con el cliente? ¿Qué tan urgente es? ¿Se pone el equipo en contacto con el cliente para entenderlo mejor si es necesario? ¿Conocen los miembros del equipo a los clientes por nombre? ¿Qué relación tienen con los clientes? ¿Les resultan molestos los clientes o son más bien como colegas para los miembros del equipo?
La mejor manera de despertar verdadera empatía y compromiso con el cliente es que los miembros del equipo (especialmente los desarrolladores) se pongan en contacto directo con el cliente.
Espero que esto te ayude a desarrollar una mejor percepción de lo que hace grandes a los equipos de producto.
Este texto proviene del blog de Marty Cagan y fue traducido al español.
Outcome vs. Output
=> Entender el Minimum Viable Product (MVP)
