- La mayoría de los usuarios solo aprovecha cerca del 20% de las funciones de una aplicación que realmente necesita, y ese 20% es diferente para cada persona
- El 80% restante de funciones a veces se percibe como una distracción e incluso termina provocando incomodidad o frustración
- Si se apunta con precisión a un mercado de nicho, se puede construir una base de usuarios sólida
- Casos como Kagi, Figma y Notion, que resolvieron bien ese 20% ignorado por las grandes empresas y crearon mercados muy leales, muestran una nueva oportunidad de mercado
- VS Code, Slack y Discord permiten que los usuarios optimicen por sí mismos su propio 20% mediante extensibilidad y personalización
- La clave no es hacer un producto para todo el mundo, sino crear una herramienta que satisfaga a fondo la parte que cada quien quiere, y ese es el camino para evitar el problema del exceso de funciones
Experiencias de la infancia y la forma de usar el software
- Cuando era niño, el autor solía dañar su computadora mientras borraba archivos inútiles para administrar 2 GB de almacenamiento
- Después de eliminar archivos importantes del sistema como
.ini, tenía que reinstalar Windows y Office 97 desde cero
- Su padre insistía en que no olvidara instalar Excel, pero para el autor Excel no era más que una herramienta para pegar tablas en Word
- Entre las innumerables funciones de Excel, lo único que realmente le importaba era copiar y pegar tablas
- Una persona cercana también usó Excel únicamente como libro de gastos del hogar, sin tocar las demás funciones
El 20% diferente de cada quien
- En el uso del software existe la regla 80/20: la mayoría de los usuarios solo utiliza el 20% de las funciones totales
- Pero el 20% en el que se enfoca cada usuario es distinto, y cada quien considera que la parte que usa es la más importante
- Ejemplo: en Word usan tablas pero no combinación de correspondencia; en Excel usan tablas dinámicas pero no scripts; en PowerPoint no usan animaciones
- Cuando se agregan nuevas funciones o cambian la UI en una actualización, surge la queja de que la aplicación se volvió más lenta o se llenó de cosas innecesarias
- El 80% de funciones que no se usa puede incluso percibirse como algo que interfiere con el flujo de trabajo de ese 20%
El deseo de obtener un resultado perfecto
- Este fenómeno no aparece solo en Microsoft, sino también en otras empresas de TI
- Por ejemplo, cuando alguien quiere hacer una búsqueda exacta por palabras clave en Google Search, los resultados relacionados innecesarios pueden terminar generando frustración
- Desde la perspectiva de una empresa, podría verse como “la necesidad del 1% de los usuarios”, pero el 1% de mil millones de personas son diez millones: un mercado enorme
- Kagi atacó el mercado con una propuesta diferenciada de búsqueda centrada en la calidad, sin anuncios y con protección de la privacidad, especializada en ese pequeño mercado que Google pasa por alto
- Si se aprovechan los huecos que dejan las grandes empresas, es posible formar un mercado de nicho que satisfaga a grupos pequeños de usuarios
- No hace falta satisfacer a todo el mundo; es posible construir una estrategia que satisfaga perfectamente la experiencia del 20% de un grupo específico
Encontrar el 20% olvidado
- Muchas empresas innovadoras se enfocan intensamente en grupos específicos de usuarios que las grandes compañías dejan fuera
- Figma se concentró en superar a Adobe en la parte de diseño colaborativo, y Notion también se consolidó como una herramienta híbrida optimizada para necesidades concretas de ciertos usuarios
- El software exitoso tiende a sumar funciones con el tiempo, pero en ese proceso aparecen nichos donde el 20% de ciertos usuarios queda enterrado
- El software de código abierto tiene una ventaja en este terreno porque permite crear builds personalizados especializados en flujos de trabajo concretos
- Por ejemplo, es posible desarrollar una versión ligera de Blender solo para visualización arquitectónica
Diseñar para el 20% correcto
- Esta filosofía está muy bien implementada en VS Code
- Las funciones base se enfocan en la edición simple de texto, pero mediante extensiones se puede configurar el entorno de desarrollo que cada quien quiera
- Es una estructura en la que todos los usuarios pueden personalizar su propio 20%
- Las integraciones de Slack y los bots de Discord siguen el mismo principio y permiten que los usuarios adapten directamente su experiencia
- Desde el inicio es difícil predecir cuál será el 20% de cada usuario, pero si se ofrece extensibilidad y personalización, cada quien puede lograr su uso óptimo
Conclusión: más que un producto para todos, enfocarse en el “20% necesario” de cada quien
- Si se intenta hacer bien absolutamente todo, el resultado termina siendo un software pesado y que genera más quejas
- Lo importante es concentrarse en que cada función trabaje de forma perfecta para el usuario específico que realmente la busca
- Como al final los usuarios solo usarán una parte del total de funciones, resulta más efectivo enfocarse en hacer que ciertas funciones sean realmente extraordinarias
- Hace falta planear reconociendo que el software puede usarse de formas que no se anticiparon, y aceptando esa diversidad
- En vez de imponerles a los usuarios todas las partes del producto, es mejor desarrollar enfocándose solo en las partes que de verdad llegan a amar, porque eso produce mayor satisfacción
2 comentarios
Siempre se lo atribuyen a la ley de Pareto sí o sí;; ¿no podría ser 15% también? jajaja
Opinión de Hacker News
En una empresa SaaS donde trabajé, una vez intentamos hacer análisis basándonos solo en una parte de las funciones que los usuarios realmente usan. Queríamos reducir la complejidad del producto y eliminar funciones molestas para ajustarlo a algunos tipos de usuarios clave. Al final, aparte de la pantalla de inicio de sesión, ese 20% que cada quien consideraba importante era completamente distinto. Los resultados del análisis no fueron muy diferentes de un muestreo aleatorio ponderado
Totalmente de acuerdo. Pero cuando empiezas a vender el producto a clientes enterprise, la situación cambia por completo. Si te falta una sola “función higiénica”, el trato puede caerse. Y además, las funciones imprescindibles varían de una empresa a otra. “Funciones higiénicas” se usa como metáfora de lo mínimo indispensable que todo el mundo necesita, como un baño
Es un texto parecido que me hace recordar las publicaciones del blog de Spolsky
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
Hice yo mismo una app de hobby personal y a veces pienso en pulirla y publicarla. Pero como no tengo ninguna intención de promocionarla o darla a conocer, siento que publicarla no tendría mucho sentido. En realidad, la razón más grande es que no tengo ganas de implementar ese otro 80% de funciones que yo mismo no uso
En marketing existe la idea del Pareto modificado. No es 80/20, sino 60/20. El 20% de los usuarios intensivos consume el 60% del valor del producto, y el 80% de los usuarios ligeros consume el 40%. No es una proporción tan pequeña como para ignorarla, así que también hay que prestarles atención a los usuarios ligeros
value-paretos-bottom-80
Así funciona. En realidad, es mucho más importante que el usuario 'perciba' que el software puede resolver su problema. Si quieres que pague, el software tiene que dar la impresión de que potencialmente también puede resolver varios de sus otros problemas. Esos problemas diversos pueden estar relacionados con funciones que el usuario ni siquiera usa directamente. Por ejemplo, en software 3D, puede que el sistema de rigging solo lo use el 2% de los usuarios durante el 1% del tiempo, pero sin esa función hay personas que ni siquiera considerarían evaluar el producto
Como no se me da bien predecir cómo se va a usar realmente lo que hago, solo prefiero el enfoque de pavimentar las rutas ya visibles, algo que suele compararse con los “desire paths”
the-road-most-traveled-by-paving
Estoy de acuerdo con la idea de que “en vez de impedir que aumenten las funciones, hay que aceptar que el software puede usarse de formas que nunca imaginamos”. Por eso creo que la interoperabilidad es el elemento más importante del software. Mi impresión es que el problema principal del texto es el carácter cerrado de los formatos de archivo según el software y la versión. A mí no me molesta combinar varias herramientas, el problema es que esas herramientas no colaboran bien entre sí dentro de un pipeline. El sueño de Unix sí que es difícil
En apps de cierto tamaño, casi nunca pasa que todas las funciones se aprovechen al 100%. Por mi experiencia, casi todas las aplicaciones tienen entre un 10% y un 30% que queda completamente infrautilizado. Normalmente se debe a que está diseñado de una forma que casi nadie puede entender salvo el equipo de desarrollo, o porque el flujo de trabajo es terrible e ineficiente, o porque es una función tan básica que las empresas que realmente la necesitan ni siquiera tienen la capacidad económica para comprar ese software
Sí, pero como muchos usuarios valoran un 20% distinto de funciones, necesitas mantener todas las funciones para conservar tu base actual de usuarios. Aun así, si eliminas funciones casi no usadas que consumen mucho tiempo de mantenimiento o desarrollo, el ROI sube
Pero los usuarios no necesariamente valoran el mismo 20%. Y otra cosa a considerar es que, antes de usar realmente una app, los usuarios no saben bien qué funciones tiene. La decisión de instalarla se basa no en las funciones que realmente incluye, sino en las funciones que esperan que tenga antes de instalarla. Esa diferencia es importante. Puedes invertir esfuerzo en funciones, pero en la práctica solo cosechas ese valor después de haber adquirido usuarios.
Esto es especialmente importante al hacer un MVP. En la mayoría de los casos, lo que impide la instalación y el uso continuo no es la falta de funciones. Normalmente es el mensaje, el marketing, o simplemente que no hay una propuesta de valor que realmente atraiga al usuario. Agregar funciones sin parar no resuelve esos problemas. Parece algo simple, pero muchas empresas lo pasan por alto.
El MVP más simple ni siquiera requiere implementar nada al principio: basta con lograr que la gente se preregistre. Así puedes validar si el mensaje realmente está conectando. Si después de registrarse se decepcionan, al menos sabrás que el mensaje sí estaba funcionando.
Claro, eso también significa lanzar un MVP sin que esté tan completo como prometía, con el riesgo de generar decepción por una promesa incompleta. Además, muchas funciones en realidad pueden no ser necesarias, especialmente en SaaS, donde muchas no son lo bastante esenciales como para que alguien pague por ellas. En vez de tomar los requisitos del cliente como condiciones obligatorias de inmediato, hay que entender con claridad si de verdad consideran eso algo de 'valor', si realmente estarían dispuestos a pagar por ello y si resuelve un dolor importante. Entender por qué el cliente hizo la solicitud es mucho más importante que construir esa función de inmediato