E039 - Lean Product Management, con Gerard Chiva

En los productos con los que has colaborado, ¿todos ellos partían de un problema identificado? Porque también es cierto que hay productos, como TikTok que han tenido muchísimo éxito, que no entiendo qué problema resuelven.

No creo que sea una cuestión de suerte. Creo que más bien estar en el momento correcto en el sitio correcto. Déjame responderte con un ejemplo no mío.

El caso del Iridium patrocinado por Motorola, esta red de satélites que debería proporcionar cobertura móvil a todo el mundo. Eso fue un epic fail por la burrada de millones que se gastaron, por la bancarrota o el fracaso de la compañía y porque no era el momento. Pero 20 años más tarde Motorola y SpaceX y no sé quién más están haciendo lo mismo, el Iridium NEXT, y creo que ahora va a funcionar. Entonces, ¿cuál es la diferencia? Esencialmente lo mismo, es el mismo producto. Lo único que ha cambiado es que la sociedad, por ejemplo, ya está preparada. O sea, la comunicación móvil en el año 98 era prácticamente inexistente. Ahora forma parte de nuestras vidas. ¿Qué problema solucionaba? El mismo, seguramente, pero en momentos diferentes, donde quizá el problema existía, pero la gente no era consciente de que tenía ese problema.

Luego están las barreras de adopción. Es decir, si tú lanzas algo y para que la gente utilice esa cosa, tiene que dejar de hacer algo que igual lleva toda la vida haciéndolo, aunque miserablemente mal, pero lo está haciendo, igual te cuesta mucho hacerles hacer el cambio. Entonces yo no te sabría dar una respuesta exacta. Creo que un producto siempre resuelve un problema o problema o una necesidad.

Están en los trabajos funcionales y están los trabajos emocionales y los sociales. Hay productos que han sido un éxito para resolver una necesidad meramente emocional o social. Seguramente TikTok, Instagram, Facebook ... se me ocurren pocos productos ahora que no solucionan nada en el mundo.

Valor Es crear un impacto positivo en la vida de una persona. 

Steve Jobs decía que para él HP era una empresa de analítica que creaba productos en base a las métricas, en base a la analítica, a los procesos, y que Apple creaba productos en base a la emoción, en base a la belleza, a la genialidad, o sea, utilizaba la genialidad, la inspiración y que eso era mucho más disruptivo en potencia.

Siempre ha estado ese debate encima de la mesa, me parece apasionante. Hay dos temas.

1. El primero: La innovación sigue un proceso. Hay gente que sé cree que el iPhone fue una noche de inspiración de Steve Jobs y al cabo de dos días se estaban produciendo el iPhone. El iPhone tiene detrás 7 u 8 años de iteración. La primera versión del iPhone me parece que era un Motorola, estamos hablando de hace muchos años, en los noventa y tanto, hay un libro que se llama The One Product donde explica la evolución del iPhone. Y eso también lo explica muy bien Clayton Christensen. Es decir, tú no tienes una idea y la lanzas y funciona. Puede ser, porque hay un 30% que sí, pero el 70% no va a funcionar. Puede ser que se junten los astros y lo claves. Pero si eso no soluciona algo en el mercado...
2. El punto 2: un tuit reciente decía que la gente no compraba productos, si no que compraba experiencias. Y yo no sé la gente, pero yo que soy una persona muy práctica, si compro algo que no hace mi vida mejor, más rápida, más eficaz, más eficiente o mejor, en alguna forma no lo compro.

Creo que en el mundo habrá de todo. Por ejemplo, yo tengo todo el ecosistema de Apple, ¿por qué no me compro un Samsung? Incluso seguramente es tecnológicamente superior al iPhone. Pues porque la primera vez que probé un Samsung dije: esto no funciona igual que un iPhone y ahí se acabó. La usabilidad era mucho mejor.

Siempre hay algo, y puede ser que no lo sepamos expresar o incluso cuantificar, pero hay algo que te hace decidir utilizar un producto y no otro, el precio es un factor pero hay muchos más.

Creemos en el concepto de Lean de Value Stream, donde todos trabajan para un objetivo común y de una forma compartida

A la hora de evolucionar un producto, tú te gastas el dinero en reducir incertidumbre. ¿Por qué decías que cada vez tienes que pagar más?

La información tiene un valor o un coste, conforme tienes más incertidumbre o menos sabes, menos te cuesta aprender mucho. 

Si nos imaginamos una gráfica, en el eje vertical tenemos la incertidumbre y en el horizontal la información que necesitas. Entonces, si os imagináis una asíntota desde el eje vertical que baja muy pronunciadamente hasta abajo y luego gira para convertirse en casi una asíntota en el eje horizontal.

Lo voy a explicar con un ejemplo: constrúyeme un taladro rojo con una potencia de 3000 kilovatios.

Esto cada product manager o head of product que nos está escuchando lo puede trasladar a su mundo, recibe muchas peticiones de este estilo: "construye esto" o "un cliente me ha pedido esto". Lo primero que tenemos que hacer es a un coste muy bajo y incluso en un tiempo muy corto, es decir, vamos a coger a cinco clientes potenciales* y preguntarles qué es lo que están intentando hacer. Esto cuesta poco y si de los cinco o diez dicen que eso no les interesa para nada, ya puedes estar casi seguro, y aunque me digáis que no es una muestra estadística, piensa en otra cosa, eso que te ha costado preparar un cuestionario y hacer cinco entrevistas de 500 euros, entonces a eso me refiero y has aprendido mucho o te has evitado invertir muchos millones.

Entonces, dependiendo del producto, si es más tecnológico, si es un B2B, un B2C, un marketplace, las incertidumbres vendrán en diferentes partes del modelo de negocio. Ahí está en visualizar el modelo de negocio, detectar esas incertidumbres y explorarlas y validarlas con prototipado lo más rápido posible. Pero aún no has construido nada. Lo máximo que habrás conseguido es un prototipo que igual lo tiras a la basura, pero no has invertido millones y tampoco has afectado a tu marca. 

Cuidado con lanzar algo que sea un epic fail. Larry Ellison tiene los suyos, Steve Jobs tiene lo suyos y Amazon... todos tienen. No hay un Silver Bullet para eso, sí se puede reducir la probabilidad de fallo. O como mínimo parar antes de cuentas. Y eso enlaza también con nuestro propósito como empresa: nos pasamos mucho tiempo trabajando, que como mínimo sea un tiempo de valor para nosotros y para la sociedad. 

Vamos a intentar que lo que haga la gente tenga un impacto en el mundo, que aprendan, pueden decidir parar a tiempo y vamos a hacer otra cosa.

Eso creo que a nivel de motivación de la gente en las empresas es muy potente.

*Nielsen Group dice que con cinco entrevistas, puedes sacar el 80% de insights.

¿Qué es valor?

Valor es crear un impacto positivo en la vida de una persona/ usuario/ cliente. Para mí eso es valor. Lo malo y lo bueno del valor es que siempre se mide desde el punto de vista del que lo recibe, no del que ofrece, entonces como empresa de producto, somos empresas de producto pero desde un punto de vista Lean somos empresas de experiencia de cliente. Es decir, si lo que tú haces no provoca un cambio positivo en la vida de los clientes, aunque positivo, tú lo puedas ver como es esta mierda de Tik Tok.

Eso es lo que tienes que conseguir como empresa, detectar qué es ese valor y cómo lo miden los usuarios, los clientes. Para mí es hacer la vida de alguien mejor. 

El problema principal es que las empresas, y da igual el tamaño, la edad, la industria, siguen pensando en proyectos. Creo que tiene mucho que ver con la mentalidad de los fundadores y claro, un fundador de una startup de healthcare puede ser muy bueno en su especialidad, que es la medicina, pero no tiene idea de Lean Startup y quizá sigue pensando en las fases de desarrollo de un medicamento.

La gente sigue pensando en proyectos y no en productos.

Yo creo que el ser humano es secuencial por definición. La gente piensa en soluciones y no en problemas en el mundo. ¿Qué problema voy a solucionar? Aunque muchas veces te digan: constrúyeme un taladro de color rojo. Vale, pero ¿me permites tirar unos pasos para atrás y ver quién va a necesitar un taladro o problema hay? ¿Qué problema voy a solucionar?
"Quiero colgar un cuadro en la pared". Entonces como soluciones tienes desde tiras autoadhesivos que aguanten hasta 10 kilos, el velcro, hay muchas opciones; "Quiero colgar una estantería para libros". Quizá entonces necesitas un taladro. La gente y el ser humano creo que tiene tendencia a pensar en soluciones.

¡Busquemos problemas por solucionar en el mundo y quién tiene esos problemas y cómo lo vamos a medir!

Otro problema es que la gente sigue pensando en proyectos y no en productos.

Los proyectos empiezan y acaban y los productos los vas cambiando, los vas adaptando. Un producto sigue un ciclo de vida muy largo. No es lo mismo desarrollar la primera versión del producto para el early market que para el grand market. Hay múltiples product market fits a lo largo de la vida de un producto.

Otro problema que nos encontramos con las empresas: tenemos una idea y lo vamos a petar; vamos a vamos a hacer el budget anual y lo vamos a asignar a este proyecto; vas a reservar los recursos y las personas para ello, ya upfront, suponiendo que eso va a ser un éxito. La mentalidad que creemos que funciona hoy en día y que está funcionando en el mundo de las startups es conforme vas reduciendo riesgo o vas reduciendo incertidumbre, vas invirtiendo más.

No necesitas toda tu infraestructura en Amazon Web Services y 15 developers, si aún no sabes si eso te lo va a comprar alguien. Desarrollar un producto o llevar al mercado un producto es un proceso continuo de reducción de la incertidumbre. Al principio, cuando tienes mucha incertidumbre, es muy barato reducir esa incertidumbre. Esa exploración inicial, observar a los clientes potenciales, hablar con ellos, cuáles son sus jobs to be done, todo eso va reduciendo incertidumbre y conforme va reduciendo la incertidumbre, tienes que pagar más. 

Es como ir comprando respuestas a preguntas que cada vez son más caras. Y como bien decía en un webinar hace poco Eduardo Ferro, "escribir una línea de códigos es un liability". Tienes que hacer todo lo que puedas para escribir el menor código posible. Esto desde el punto de vista del mundo digital. Hay una parte inicial de Discovery, de intentar validar lo que vas a construir antes, y eso ya es criterio del equipo, del product manager, de si es una cosa que has hecho veinte mil veces y sabes que va a funcionar, pues no hace falta que nos liemos ahora a entrevistar a los clientes, pero si es una idea nueva, una nueva línea de productos, un nuevo target segment, vamos a hacer una exploración para no meternos a picar código, aunque sea con continuous integration, que vamos a hacer muy rápido algo que nadie quiere. Entonces no hace falta y en ese camino también vamos a aprender muchas cosas. Ese es otro de los fallos habituales. 

Hablas de integración continua como si fuese algo normal o fuese algo ya estándar estandarizado en el mercado. Ojalá fuese así. 

Sí que es cierto, al menos en nuestra experiencia, yendo a posibles clientes de industrias que consideraríamos laggards dentro del agilismo, (insurance, banking, farma, etcétera), la parte de delivery está bastante avanzada, mucho más de lo que nos pensamos. Pensamos que solo Facebook, Amazon y estas empresas tienen un delivery potente, pero me he sorprendido en los últimos dos años de cómo han avanzado las grandes empresas en este aspecto. Pero sigue fallando la parte de decidir qué construir. 

La cuestión es asumir que la mayoría de ideas que tienes van a ser un fracaso.

Muchas veces estamos construyendo muy rápido y entregando frecuentemente cosas que no necesitamos, que nadie quiere utilizar. Y eso es muy grave porque es que vale mucho dinero.

Sí que hay ejercicios que generan cierto impacto. Decirle al Head of product, Product Manager o Product Owner: "coge el roadmap del año pasado y de todo lo que hiciste, dime cuántas cosas han funcionado". 

Algunos te responderán "no sé si han funcionado", que ya estamos en otra discusión, porque, claro, tienes que tener un sistema de métricas y de medir el impacto de lo que tú estás haciendo. Suponiendo que eso existe, ves claramente como un 40% o un 30%. No hay nada malo en eso. La cuestión es asumir que sea así, que la mayoría de ideas que tienes van a ser un fracaso. Fracaso en el sentido de que no van a funcionar como tú esperas. ¿Qué hemos aprendido de eso? ¿Qué mecanismos tenemos en todo el proceso, desde la idea hasta el mercado de poder parar algo a tiempo? El famoso Kill, Pivot or Persevere, de Lean Startup. lo matamos, lo avanzamos un poquito más o pivotamos.

Pivotar puede significar: esto iba para el segmento de jóvenes de 15 a 30 años y resulta que no, que va para mayores de no sé qué edad. El mismo producto orientado al segmento de mercado totalmente distinto, quizá variando la propuesta de valor y el pricing, etcétera, pero no tienes que tocar nada el producto en esencia, pero puede ser la diferencia entre el éxito y el fracaso. ¿Qué mecanismos tienes en tu proceso hasta que algo llega al mercado para tener esos puntos de decisión que no son por fases, son por iteraciones?

¿Por qué sucede que tardamos demasiado tiempo en lanzar un producto al mercado? ¿En qué medida crees que afecta la organización formal de una compañía?

Afecta, afecta mucho. Tiene que ver también con qué hacemos y qué no hacemos en nuestra empresa. En cierto punto tomamos la decisión de enfocar nuestro trabajo con nuestros clientes y con nuestros partners en lo que nosotros llamamos el Hard Core de las empresas: estructuras, procesos, estrategia, y dejar para otros cambio cultural, liderazgo, mindset... Fue una decisión tomada concienzudamente y una decisión estratégica. 

Creemos que las estructuras influyen en las acciones que realizan las personas dentro de esa organización. Si tú tienes el dominio o el reino de marketing y el reino de ventas, y el reino de producto y el reino de ingeniería, pues cada uno será muy difícil evitar que se formen las tribus, las asociaciones, los amiguismos y las luchas. Nosotros creemos en el concepto de Lean de Value Stream, le podemos llamar equipo de producto si quieres, donde realmente todos trabajan para un objetivo común y de una forma compartida. 

Añado un tema que es la paradoja de la tiranía de Lean y Agile.

Habrás oído hablar de la paradoja de la intolerancia. Es decir, hay que ser intolerantes con los intolerantes para que su intolerancia no avance en la sociedad. Y nosotros creemos que, a diferencia de mucha otra gente, que en la paradoja de la tiranía del Agile y de Lean, es decir, que para cambiar una organización a un modelo descentralizado o a un modelo de autonomía, lo puedes y muchas veces lo tienes que hacer desde una perspectiva dictatorial.

Y esto está muy bien explicado en un libro que se llama Lean Thinking de James P. Womack, que es el director del Lean Enterprise Institute, y es justamente ahí donde sale la paradoja de la implementación dictatorial de Lean para conseguir una empresa descentralizada, donde haya liderazgo a todos los niveles, donde cada uno puede tomar las decisiones que le tocan, etcétera, lo tienes que hacer desde un punto de vista push.

Habrá gente que no estará de acuerdo con esto y me parece bien. Pero nosotros tampoco entramos en eso. Nosotros vamos a nuestros clientes y decimos: estas son las estructuras y los procesos que tenéis que utilizar. Os vamos a acompañar nosotros en el cambio si queréis, si no traemos a partners que os pueden hacer más la parte de coaching, acompañamiento, etcétera.

No puedes pretender hacerlo bien todo. Entonces tomamos esta decisión a conciencia: vamos a centrarnos en estrategia, estructuras y procesos, prácticas, técnicas, etc. Y lo otro se lo vamos a dejar a otra gente que a veces colaboran con nosotros.