Resumen “Escaping The Build Trap” Parte 3

Este post es el tercero de una serie de 3 posts resumiendo el libro Escaping The Build Trap de Melissa Perri. Puedes encontrar aquí el primer post y aquí el segundo.

Anteriormente vimos:

2. Resumen

2.1 Parte 1: La trampa de construir

2.2 Parte 2: El rol del Product Manager

2.3 Parte 3: Estrategia

Por eso vamos a continuar con:

2.4 Parte 4: El proceso

Las soluciones están ligadas a los problemas que los usuarios quieren resolver. El trabajo del Product Manager junto con su equipo consiste en utilizar el Product Kata para encontrar el marco mental correcto con el cual enamorarse del problema. A partir de ahí, deberá explorar mediante iteraciones hasta alcanzar los resultados positivos.

Muchas veces las empresas empiezan a perder cuota de mercado de forma progresiva y caen en la trampa de construir más y más features en lugar de preguntarse dónde está el valor que NO están ofreciendo a sus usuarios. Como decía Marty Cagan en su libro INSPIRED, estas empresas son como grandes barcos en los que ha empezado a entrar agua. Quizá se mantengan a flote durante 5 o 10 años, pero han perdido su estabilidad en el mercado y están condenadas a hundirse poco a poco aunque en muchos casos ni siquiera sean conscientes.

Cuando vemos que nuestros números empiezan a desestabilizarse, debemos explorar en profundidad cuál es el problema real que está impidiendo a nuestra empresa avanzar, en lugar de simplemente lanzar soluciones basadas en creencias o intuiciones. Muchas veces el problema puede parecer muy claro a simple vista, pero si no investigamos con métodos fiables dicho problema es posible que estemos centrando nuestros esfuerzos en resolver aquello que no es prioritario.

En base a nuestra visión, debemos revisitar nuestra propuesta de valor para obtener hipótesis válidas sobre qué puede ser lo que está fallando en nuestro producto. Para hacer esto tenemos que escoger qué caminos queremos explorar. Por ejemplo: Podríamos explorar la forma de conseguir más usuarios nuevos, podríamos explorar la forma de retener mejor a nuestros usuarios ya existentes o podríamos tratar de crear nuevas vías de monetización de los usuarios existentes.

A través de los datos estadísticos utilizando herramientas como por ejemplo Google Analytics, podemos ver qué camino creemos que es más crítico. Una vez elegido el camino que queremos explorar podremos establecer distintas iniciativas y experimentos que nos ayudarán a acercarnos a la raíz del problema.

Entendiendo la dirección en la que nos movemos, podemos establecer las métricas adecuadas para rastrear los resultados de nuestras acciones. Pero es importante no caer en las métricas de la vanidad, es decir, aquellas que nos ofrecen datos que nos gustan, como podría ser un aumento de visitas hacia la web, pero NO nos están arrojando luz sobre el problema que tratamos de solventar. Las métricas deben ir orientadas hacia resultados concretos en relación a nuestra exploración, como por ejemplo la satisfacción o la retención del usuario.

En el proceso de exploración del problema debemos ser creativos y utilizar las herramientas que nos ofrezcan mejores respuestas a nuestras preguntas. Quizá debamos hacer experimentos A/B, lanzar cuestionarios a los usuarios cuando abandonan nuestra página… utilizar nuestro ingenio para conseguir los datos que validen que estamos ante el problema adecuado.

Una vez hecho esto, es cuando toca explorar las posibles soluciones. Para ello debemos experimentar teniendo muy presente que nuestro objetivo es aprender. Podremos utilizar técnicas como el Producto Mínimo Viable, que nos permitirá ir aumentando nuestro conocimiento por medio de un prototipo que iremos desarrollando en base a un feedback constante. También podremos utilizar técnicas de experimentación como el Mago de Oz, haciendo creer a los usuarios que el proceso detrás del producto está automatizado cuando realmente es manual, el Concierge, que sí da a entender a los usuarios que no se trata de un producto final y que quien va a recibir esos datos es una persona de carne y hueso o el Concept Testing, con el cual muestras a los usuarios el concepto que tienes en mente para ver si el feedback que recibes te lleva hacia dónde tú creías o te lleva por nuevos caminos. El Método Delphi, explicado en el libro Scrum de Jeff Sutherland, también es una buena herramienta para obtener resultados.

Cuando tenemos resultados analíticos y establecemos la dirección en la cual vamos a construir nuestra solución para el producto, podemos servirnos del documento Estrella del Norte. Este documento explica el producto de una manera que pueda ser visualizada por todo el equipo y toda la empresa. Incluye el problema, la solución propuesta, el contexto y factores que afectan a dicha solución y los resultados esperados de ésta. Por otro lado, el Story Mapping es un documento que sirve para ayudar a los equipos a concretar qué tareas deben realizar dentro del contexto ofrecido por la Estrella del Norte.

Existe una herramienta que puede ser de gran utilidad a la hora de priorizar el trabajo y es el Coste de la Demora. Si tardamos mucho en probar nuestro prototipo podemos estar perdiendo oportunidades, pero si nos adelantamos y lo probamos antes de que esté en un estado adecuado, puede que el feedback que recibamos no sea del todo acertado. Aquí la importancia de la autonomía de los equipos es vital. La empresa debe confiar en ellos y dejar que experimenten y aprendan sin miedos ni restricciones.

2.6 Parte 5: Empresa enfocada al producto

La empresa enfocada al producto se caracteriza por tener una cultura que se organiza en torno a los resultados que ofrecen valor en lugar de centrarse en la cantidad de resultados sin tener en cuenta el por qué de estos. En estas empresas, a los trabajadores se les recompensa por aprender y lograr objetivos. Los directivos animan a sus equipos de producto a acercarse a los clientes y el desarrollo de producto es concebido como una función crítica para la empresa.

Melissa empieza esta parte del libro contando cómo ella estuvo presente en Kodak un año después del lanzamiento del iPhone. Kodak es uno de los grandes ejemplos de empresas que no supieron adaptarse a una disrupción en el mercado. Con la llegada de los smartphones las cámaras digitales pasaron a un segundo plano. Kodak tuvo la oportunidad de asociarse con otras empresas para integrar su tecnología en los teléfonos, pero la compañía NO estaba preparada para un cambio tan drástico en tan poco tiempo. Decidieron seguir con su modelo de cámaras digitales en un momento en el que el mercado estaba viviendo una revolución y esto supuso su desaparición.

La forma en la que se organiza y comunica una empresa es vital para poder desenvolverse en el marco de las metodologías ágiles y no caer en la trampa de construir. Esto debe empezar desde las capas más altas de la organización. Si los directivos de una empresa de software no son capaces de cambiar el chip y dejar a sus trabajadores fluir en entornos ágiles, lo más probable es que más antes que después acaben hundiéndose. Las empresas que provienen de métodos Waterfall están acostumbradas a trabajar con Roadmaps, entendiendo estos como planificaciones fijas de lanzamientos. Por ejemplo: “Vamos a lanzar esta feature el 18 de Enero y después vamos a lanzar esta otra el 20 de Marzo”. Sin embargo, los Roadmaps deben ser algo dinámico que cambie con el tiempo y que se comuniquen de diferente forma según con quién estemos hablando. Un Roadmap debe servirnos para saber dónde estamos y hacia dónde vamos. Debe tener un tema, una hipótesis, objetivos y sus métricas, acontecimientos relevantes y el estado del desarrollo del producto, que puede ser experimental, Alpha, Beta o Disponibilidad General.

Los incentivos y las recompensas individuales, así como los presupuestos a cada producto deben establecerse en torno a la investigación, aprendizaje e implementación del valor real del producto y no en torno a si hemos alcanzado la cantidad de features preestablecida al comienzo del año o del trimestre. Una empresa ágil debe ser capaz de moverse en el mercado a la mayor velocidad posible y no funcionar de forma reactiva a los cambios que éste vaya sufriendo.

Una empresa enfocada en el producto debe asegurar la seguridad del aprendizaje de sus empleados. No puede cerrar filas en cuanto las cosas no sean como esperaba y volver a la rigidez de la metodología Waterfall o similares. En el ejemplo que puse antes de Netflix, cuando Netflix metió la pata con el Proyecto Griffin, no por ello se echó para atrás y dejó de experimentar. Todo lo contrario, pocos años después empezaron a producir sus propios contenidos audiovisuales. Netflix de esta forma demostró que no tenía miedo a experimentar y a apostar por nuevas fórmulas persiguiendo así su visión de marca: ofrecer a sus usuarios la forma más cómoda y conveniente de consumir contenidos audiovisuales. Al igual que Netflix, Spotify, Google, Amazon y las grandes empresas tecnológicas de nuestra era se han caracterizado por esto mismo: por experimentar y romper barreras siguiendo una visión que pone siempre en el centro el valor que ofrecemos al cliente.

Y con esto concluimos el resumen. Espero que os haya sido de utilidad. ¡Nos vemos en el próximo post!