Reflexión sobre la incómoda charla “The Root Cause Of Product Failure” de Marty Cagan

Hoy me ha pasado la charla @ziraco y me dice “escúchala, que creo que te gustará”. Ea, si lo dice @ziraco, con grapadora en mano o no, allá que voy.

Llevo 15 minutos viéndola, y como nivel de ansiedad aumentaba poco a poco, he decidido escribir este post a medida que la escucho, a modo de apuntes y resumen de ideas fuerza que a mi me han inspirado (probablemente no estén todas).

La charla trata de reflejar un proceso de innovación típico en una empresa, muy similar al de la gran mayoría, y dicta 10 razones por las que Marty Cagan expresa que el proceso es fundamentalmente erróneo. Inspirador y a la vez incómodo.

La charla en cuestión es la siguiente:

¿Seguro que haces Agile?

Mira este proceso desde el desarrollo de la idea hasta su despliegue. ¿Es esto realmente un proceso Agile?

¿Parece un proceso algo en cascada, no? ¿Cuánto tiempo y riesgo se acumula desde la idea hasta el despliegue de ésta?

El origen de las ideas: executives and managers

En empresas de base tecnológica, la innovación reside allá donde esté la tecnología y donde ésta se dirija. ¿Son los executives y los managers los que más cerca están de ella? ¿Son los que más saben lo que la tecnología puede hacer?

No, ellos saben lo que el cliente quiere, lo que al cliente le duele, lo que la empresa debería hacer, pero no lo que la empresa puede hacer.

¿Están invitados los que conocen la tecnología (aka “engineers”, “técnicos”, etc.) a las reuniones más cercanas al producto y de ideación? ¿Tenemos eso por cultura?

La falacia de los business cases

Los Business Cases no deberíamos orientarlo o mezclarlo con dos variables:

• ¿Cuánto voy a ganar con esto? Cómo lo vamos a saber. ¿Sirve poner algún objetivo si luego no sabemos si será realmente viable, o si la funcionalidad pivotará, o qué?
• ¿Cuánto me va a costar? Depende de miles de cosas. O quizás descubrimos que para pulir bien una idea necesitamos 3 iteraciones. Es imposible saberlo antes. Y lo peor es que con esta pregunta comienza las presiones hacia el equipo de desarrollo, y “la cascada” hacia el problema de las estimaciones.

¿No hay formas alternativas de plantearse “merece esta funcionalidad ser realizada”? (Luego lo veremos)

El problema de los roadmaps

2 razones principales:

• Usabilidad: La realidad es que no sabemos si nuestras funcionalidades servirán para algo. Y no lo sabremos ni a la primera. Quizás es por usabilidad, quizás porque los clientes no lo necesitaban… Y como tenemos un roadmap, saltamos a la siguiente funcionalidad, y dejamos la anterior “a medias”, o “sin finalizar”. ¿Es porque la estimación era incorrecta? ¿O es porque no nos centramos en aprender por qué no “funciona” (por qué no es usada) y terminarla o pulirla?

Ejercicio simple: revisar los últimos 6 meses de funcionalidades implementadas del roadmap y revisar si los objetivos se cumplieron o no, y si hay algo de real en el anterior punto.

• Monetización: Una vez que se implementa una funcionalidad, esta no está pulida hasta que realmente da dinero; hasta que su funcionalidad es realmente útil de cara al negocio. Pasamos de usar el concepto “Time to market” a usar “Time to money”. Estas funcionalidades se comerán el resto del roadmap. ¿Cómo vamos a dejar a medias algo que la gente usa pero que no le estamos sacando todo el $ que podemos?

Be stubborn on your vision, flexible on the details!

(Usar un roadmap es totalmente contrario a todo eso!)

Tus empleados no están cómodos con esto

¿Lo está un Product Manager que no puede flexibilizar los requisitos?

¿Lo está un diseñador que no tiene tiempo para pulir una funcionalidad?

¿Lo está un desarrollador empujado por cumplir plazos, estimaciones y un timeline, en vez de prestar atención a su funcionalidad?

Tus empleados probablemente estén buscando otras empresas donde este ciclo esté funcionando mejor.

¿Ventajas ágiles?

¿Es realmente un ciclo ágil? Probablemente las ventajas del “agilismo” no están visibilizándose con un flujo tan en cascada. El cliente ve el resultado al final de todo este proceso. Y el riesgo aumenta durante todo este tiempo. Es lento y caro, tiene un alto coste de oportunidad. Y es frustrante. Se acaba el dinero.

Nos centramos en sacar funcionalidades, no en mejorar el producto

El roadmap es un listado de funcionalidades. Un equipo enfocado en roadmap , si tiene mucho éxito, lo único que hará es solo sacar funcionalidades de forma rápida. Este equipo no se centra en obtener resultados de negocio. Deberían tener cultura de resultados de negocio, no de sacar funcionalidades.

¿Hay alternativa? Continuos delivery and discovery

Se propone crear 2 tracks:

• Discovery: donde están todos los perfiles representados (engineers + designers + managers + …)
• Delivery: la construcción, con un equipo sólido de producto.

Y usar OKRs: Objectives and Key Results: Business outcomes priorizados. En vez de que los managers entreguen roadmaps, lo que hacen es entregar “resultados de negocio esperados priorizados”. Y piden al equipo de producto (discovery + delivery) que descubra cómo obtener dichos outcomes.

Así además se crea un sentimiento de misión, dentro del equipo.

The key is a *strong product team*: outsourcing por ejemplo, limita esta posibilidad.

Se necesitarán experimentos rápidos (quick experiments) con MVPs para ver la validez de determinadas ideas. Solo se construye la idea si el resultado permite descubrir:

• ¿El usuario la compraría?
• ¿Sabría usarla?
• ¿Hay capacidad de construirla?
• ¿Están todos los stakeholders de la solución alineados con la funcionalidad a implementar? (legal, marketing, etc.)

Una empresa orientada a producto debe tener como misión masterizar este proceso. Debemos ser realmente buenos en esto, estudiar los problemas actuales, buscar alternativas e inspiraciones para descubrir y entregar más rápido. Sino, el riesgo aumenta, y el dinero disminuye.

Para saber más: Inspired, how to create product customers love. By Marty Cagan. Como dice @ziraco, “el libro de Marzo”.

Disclaimer: perdón por el estilo de redacción. Pretendía ser algo de uso interno, pero luego he decidido compartirlo para dar visibilidad a una charla que a mi parecer merece ser vista.

Y actualizo este post con este chiste que me acabo de encontrar por internet.