#144 Nunca adoptes a un zombie
Hola, soy @samuelgil, Partner en JME Ventures.
Bienvenido a mi newsletter semanal, un lugar donde nos reunimos aquellos que creemos que la tecnología transforma juegos de suma cero en juegos de Suma Positiva.
La edición de esta semana viene a cargo de Sergio García, Senior Product Manager en Cabify. Lleva más de 15 años en el sector tech centrado inicialmente en gestión de la innovación y, durante los últimos 6 años, en gestión de producto.
Esta edición de Suma Positiva ha sido patrocinada por:
Scalable Capital es el bróker alemán que se adapta a ti. Si haces algunas inversiones mensuales, tienes un coste muy reducido para negociar y los ETFs son sin comisiones. Si haces varias transacciones al mes, la tarifa plana de 2,99€ te permite invertir todo lo que quieras sin comisiones adicionales.
Ya no hace falta que tengas miles de apps y plataformas, en Scalable Capital puedes invertir en un mismo lugar en ETFs, acciones, fondos y criptos de forma segura.
❤️ ¿Quieres patrocinar Suma Positiva? Toda la información aquí.
Nunca adoptes a un zombie
por Sergio García
“¿Papá, cuál prefieres tú? ¿Cuál me gustará más? ¿Los leemos todos?” Llega la noche, mi hijo tiene que irse a la cama y toca elegir qué libro leemos. En mi cabeza está la idea de que si es él quien escoge el libro entre muchas opciones se irá más contento a dormir. Sin embargo, en su mente solo está la posibilidad de equivocarse en la decisión que tome. “¿Y si elijo el libro de Mickey pero me hubiese gustado más el de Peppa en el zoo? Es que también me gusta mucho el Osito Tito…”
Michal Maimaran, Research Associate Professor of Marketing en la Kellogg School of Management explica este fenómeno en su artículo “To increase engagement, offer less: The effect of assortment size on children’s engagement”.
En su investigación, Maimaran pidió a 42 niños de entre cuatro y cinco años que escogieran un libro de un conjunto de dos o siete títulos. Después, invitaba a los niños a mirar el libro todo el tiempo que quisieran. Los libros incluidos en el estudio tenían la misma extensión y compartían un diseño de portada similar.
Los niños que eligieron entre dos libros tomaron una decisión más rápida y dedicaron mucho más tiempo a mirar el libro en comparación con los niños que eligieron entre siete opciones.
Más no siempre es mejor
Lo anterior está relacionado con la denominada paradoja de la elección, estudiada por los psicólogos Sheena Iyengar y Mark Lepper de la Universidad de Columbia y Stanford en el año 2000.
En su investigación ofrecieron durante diferentes días dos opciones de compra de mermeladas. El primer día las opciones estaban limitadas a seis tipos de mermeladas, mientras que el segundo día los consumidores pudieron escoger entre 24 distintas. El resultado fue que, aunque eran más los consumidores que se acercaron a ver las 24 mermeladas, solo un 3% realizaron la compra, mientras que el primer día, con 6 opciones, más de un 30% de los consumidores compraron mermeladas.
En esta misma línea, Barry Schwartz, profesor de Psicología en la Universidad de Swarthmore y autor del libro “La paradoja de la elección” apunta dos aspectos clave cuando nos enfrentamos a la elección entre un número elevado de opciones:
Por un lado, nos cuesta más tomar la decisión dado que, como indica la Ley de Hick, aumentar el número de opciones aumenta el tiempo de decisión logarítmicamente.
Y, por otro lado, tener más opciones aumenta nuestras posibilidades (y también nuestra necesidad) de comparación, convenciéndonos de que una de las opciones descartadas debería haber sido perfecta incrementando, por tanto, la insatisfacción con la opción elegida.
Si nos centramos en los productos digitales, las opciones entre las que puede elegir un usuario guardan una estrecha relación con el número de funciones que ofrece dicho producto, siendo su número óptimo el resultado de un complejo equilibrio.
Al evaluar un producto los potenciales usuarios hacen balance entre sus deseos de capacidad y usabilidad, deseos que, para complicarlo aún más, varían con el tiempo. Este fenómeno fue estudiado por investigadores de las universidades de Georgetown y de Maryland en el trabajo “Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing”.
Según este estudio, los consumidores dan más peso al número de features y menos peso a la usabilidad antes de usar un producto mientras que, después de usarlo sucede lo contrario. Por ello, tienden a elegir productos demasiado complejos que no maximizan su satisfacción cuando los usan, lo que resulta en el fenómeno conocido como “feature fatigue” o fatiga de funcionalidades.
“Featuritis”
La “featuritis” es un concepto muy relacionado con lo anterior que puede definirse como la tendencia a que el número de funcionalidades de un producto —por lo general, un producto digital— aumente con cada nueva versión.
Hay un ejemplo reciente que me viene de perlas para ilustrar una de las muchas posibles causas de este fenómeno. Hace un par de meses Google anunciaba que su plataforma de videojuegos en streaming, Stadia, cerrará sus puertas a principios de 2023 argumentando que el servicio "no ha ganado la tracción con los usuarios que esperábamos". Hasta aquí, nada nuevo: la mayoría de los productos que se lanzan al mercado fracasan.
Este anuncio ha venido acompañado de un interesante debate abierto por un usuario de Reddit en el que se indicaba que la progresión profesional en Google se basa, ante todo, en la participación en lanzamientos porque "a nadie le ascienden por mantener o arreglar algo roto'".
El usuario define una dinámica que se percibe constantemente en los productos de Google: desarrollo rápido hasta el lanzamiento, y después todo se detiene. "Internamente llamábamos a esto el ciclo LPA (Lanzamiento, Promoción, Abandono)".
Este tipo de incentivos más centrado en el lanzamiento de nuevas features que en la creación de valor puede conducir a las conocidas como feature factories.
Feature factory se refiere a un negocio centrado en la creación de nuevas funcionalidades en lugar de, o por encima de, resolver los problemas de sus clientes. El equipo de producto mide su éxito por la cantidad y la frecuencia con la que se lanzan nuevas features teniendo, además, la certeza de que añadir una nueva funcionalidad siempre agrega valor al producto.
El impacto de este crecimiento constante de features sobre la experiencia del usuario ha sido representado por Kathy Sierra en su “curva de la featuritis”. A medida que el número de funcionalidades aumenta, también lo hace la felicidad de nuestros usuarios con el producto. Esto es así hasta alcanzar un máximo al que Kathy llama “Happy User Peak”. A partir de este punto, cada nueva feature no solo no incrementa la felicidad del usuario, sino que la reduce.
El caso de ICQ
Para aquellos que no lo conozcan, ICQ es un cliente de mensajería instantánea lanzado en 1996 que se convirtió en poco tiempo en un producto muy popular, con más de 100 millones de usuarios registrados. Spoiler alert: su éxito duró poco.
Ante el ritmo frenético en el crecimiento de usuarios y la aparición de nuevos competidores en escena el equipo de ICQ planteó, como parte de su estrategia de diferenciación, el constante lanzamiento de nuevas funcionalidades. Este bombardeo incesante de nuevas features les impidió ver cómo cada nueva característica afectaba tanto al producto en su conjunto, como a la experiencia de sus usuarios.
En 2001 el producto de mensajería central de ICQ estaba tan saturado de opciones que asustó a los usuarios nuevos y existentes por igual. Además, la función central del producto —chatear— se vio tremendamente obstaculizada por todas las features adicionales.
Para “resolver” este problema la empresa lanzó una versión simplificada llamada “ICQ Lite” en la que “sólo se incluían las características más populares de ICQ”. Nada podía salir mal: las funciones que más se usaban formaban la versión “Lite”, mientras que la versión principal permanecía sobrecargada con features que a nadie interesaban y que nadie, o casi nadie, usaba.
El ciclo de vida de las features
Todos los que trabajamos en producto sabemos que estos tienen un ciclo de vida formado por 4 etapas: introducción, crecimiento, madurez y declive. Si todo va bien, nuestro producto pasará por cada una de estas etapas y, en cada una de ellas, nuestro foco como Product Managers estará puesto en distintos procesos y métricas.
Sin embargo, es menos conocido que, a su vez, cada una de las features de un producto tiene su propio ciclo de vida que, según los autores del artículo “Time to Say Good Bye: Feature Lifecycle” se divide en 5 etapas:
“Feature Infancy”: se trata de una etapa pre-desarrollo centrada en entender, fundamentalmente mediante datos cualitativos, cuál será el valor de la feature.
“Feature Deployment”: en esta etapa una primera iteración de la feature es entregada al usuario. Esto permite obtener datos cuantitativos, así como cualitativos, que sirven para validar las hipótesis y continuar iterando.
“Feature Inflation”: la adopción de la feature por parte de los usuarios se intensifica en esta fase. La funcionalidad está en constante evolución mediante nuevas iteraciones que permiten incrementar la entrega de valor, así como diferenciarse de los competidores.
“Feature Recession”: en la etapa anterior el valor de la feature alcanza su máximo. A partir de dicho punto, los usuarios dejarán paulatinamente de utilizar la funcionalidad existiendo numerosas causas que explican este comportamiento como, por ejemplo: los usuarios pasan a utilizar productos de los competidores o una feature alternativa, el problema resuelto deja de ser relevante, o se lanzan nuevas features que desplazan el uso de otras anteriores o incluso tienen efectos negativos sobre aquellas.
“Feature Removal”: en esta última etapa los costes que supone el mantenimiento de la feature igualan, o incluso superan, el valor aportado por esta.
Cárgate a los zombies
La entrega de nuevas features, así como el número y frecuencia de dicha entrega es una de las herramientas que tenemos los Product Managers para cumplir nuestros objetivos. El problema no es la entrega frecuente de nuevas funcionalidades (aunque esto puede tener sus matices según estemos ante un producto B2C o B2B), el problema es creer que dicha entrega implica directamente incrementar el valor aportado por nuestro producto. El problema es no eliminar aquellas features que no están aportando suficiente valor. El problema es inferir que una feature que aporta valor en un momento determinado, va a hacerlo siempre.
La (triste) realidad es que cuando lanzamos una nueva feature muy probablemente no aportará prácticamente nada, incluso es probable que impacte negativamente (en términos de usabilidad, costes, complejidad para incluir nuevas features, bugs,…). Sin embargo, es poco probable que tenga un impacto positivo importante tanto para el usuario como para nosotros.
Teniendo en cuenta la paradoja de la elección y la fatiga con la que podemos sobrecargar a nuestros usuarios si el número de features de nuestro producto no hace más que crecer, parece lógico que, en algún momento, los responsables de producto deberíamos tomar una decisión sobre eliminar aquellas funcionalidades que no estén aportando suficiente valor (nótese la importancia de la palabra “suficiente”).
Aunque existen numerosos frameworks y sistemas de priorización para ayudarnos a decidir qué problemas u oportunidades deberíamos abordar desde nuestro producto, existe mucha menos información sobre cómo, cuándo y qué features deberíamos eliminar.
Uno de los artículos más destacables en este ámbito es “Upsides to Unshipping: The Art of Removing Features and Products” en el que se identifican ocho situaciones en las que una feature debería ser eliminada o, al menos, rediseñada y repensada. Dichas situaciones se pueden resumir en las siguientes:
No está alineada con la estrategia de la empresa (nunca lo estuvo o ha dejado de estarlo).
Tiene un gran número de bugs o representa unos costes técnicos o de mantenimiento demasiado elevados.
Solo tiene impacto sobre un nicho reducido y no relevante de usuarios.
El problema resuelto por la funcionalidad ha dejado de existir o de ser relevante para el usuario.
Existen otras features que resuelven mejor el problema abordado.
Es frecuente tener un volumen importante de datos y recoger muchas métricas antes y durante el lanzamiento de una nueva feature, así como durante las primeras semanas y meses desde que se produce su entrega. Sin embargo, una vez que se validan las hipótesis y se tienen suficientes datos sobre su impacto las funcionalidades dejan de monitorizarse con tanta atención y detalle permitiendo que las features zombies (aquellas que no aportan valor y deberían ser eliminadas) campen a sus anchas en nuestros productos.
Como símil simplón pero ilustrativo podemos decir que es como si Thomas Edison en sus más de mil intentos para conseguir una bombilla eléctrica que funcionase de forma continua durante un buen número de horas hubiese dejado las más de 900 que no funcionaron colgadas en el techo de su casa.
Antes de vernos forzados a lanzar una versión “lite” de nuestro producto en la que “sólo se incluyan las características más populares” deberíamos auditar de forma continua el catálogo de funcionalidades garantizando que todas aportan suficiente valor, y que dicho valor es mayor que su coste.
Por favor, nunca adoptes a un zombie.
Gracias por leer Suma Positiva.
Si te ha gustado esta edición, no te olvides de dar al ❤️ y de compartirla por email o redes sociales con otras personas a las que les pueda gustar.
Si quieres patrocinar una próxima edición, aquí tienes toda la información.
Netflix, como máximo exponente de demasiadas opciones y te terminas yendo a la cama antes de elegir la siguiente serie 😅
Más no es mejor, suficiente es mejor.