La idea de diseñar y desarrollar productos altamente enfocados y funcionalmente limitados para validar los supuestos centrales del negocio está muy difundida en la industria. Desde procesos como Design Thinking hasta metodologías ágiles como Scrum y Kanban y conceptos como Lean Startup y MVP, apuntamos constantemente a la creación de nuevos productos como pequeños experimentos que confirmen o refuten nuestras ideas.

Esta misma idea, que quizás se percibe como genérica a todo un producto, también es aplicada con frecuencia al enfoque funcional del mismo. Es decir, una funcionalidad responde a una tarea que el usuario debe realizar en tu plataforma para resolver cierta necesidad. Y existen diversas formas de presentar dicha funcionalidad, algunas más complejas y sofisticadas y otras más simples y sencillas.

La clave aquí es justamente entender cuál es la mínima expresión de una funcionalidad que permita al usuario resolver una tarea y obtener valor de la misma. Por ejemplo, ¿es realmente necesario desarrollar un registro de usuarios por Google, Facebook y LinkedIn al comienzo? Si ya con el registro por email el usuario resuelve su tarea de crear una cuenta. A veces sucede que nos vemos en la tentación de agregar una mayor descripción funcional a nuestras features que las hacen escalar en complejidad y su incremento de valor es marginal.

En otras ocasiones, nos vemos con la necesidad de desarrollar una feature si o si y que no podemos remover del alcance de nuestro producto. En tal caso la estrategia en lugar de recortar funcionalidad consiste en alcanzar la expresión mínima a implementar. Se trata de encontrar low-hanging fruits, funcionalidades que requieren un pequeño esfuerzo de desarrollo pero que aportan un alto valor al usuario.

En este artículo estaremos repasando el concepto y cómo se aplica al universo de producto. ¡Alla vamos! 🚀

‍

El principio de Pareto en Producto

El principio de Pareto (también conocido como Ley de Pareto o la Regla 80/20) constituye uno de los modelos mentales más importantes que existen para la toma de decisiones. Básicamente retrata el siguiente fenómeno estadístico: en cualquier observación, una proporción pequeña de la población contribuye a la mayor parte del efecto. En otras palabras, en cualquier sistema no todas las partes contribuyen de forma equitativa, sino que la distribución de poder e influencia está concentrada en un pequeño porcentaje.

De ahí la relación 80-20. Aplicado a las tareas que realizamos en nuestro día, esto quiere decir que el 80% del valor que obtenemos se consigue con el 20% de nuestro esfuerzo. Desde ya que esta relación es orientativa, pero el principio aplica también para los casos en los que la distribución sea 99-1, 90-10 o 70-30, por poner algunos ejemplos. En sintesís, si solo un pequeño porcentaje del esfuerzo nos da gran parte de los resultados, es muy relevante entonces identificar qué es lo más importante, saber priorizar y poner foco para optimizar nuestros recursos. Porque sino seremos víctimas de su forma inversa: un 80% de nuestro esfuerzo nos dará tan solo un 20% de los resultados esperados.

Creo que el punto más destacado del principio es su capacidad para ser generalizado a distintos ámbitos de la vida: desde trabajo y finanzas hasta relaciones humanas, deportes, experiencias, etc. Particularmente en este artículo veremos la aplicación de este principio en Product Management. Como ejemplo, pensaremos en el desarrollo de una funcionalidad para poder pagar un producto de forma online a través de una plataforma de e-commerce.

‍

‍

Si buscamos una implementación completa de esta feature, la misma puede volverse bastante compleja ya que esto implicaría cubrir múltiples casos de uso para satisfacer a la mayor parte posible de usuarios: habilitar pagos con tarjeta de débito y crédito, pagos en efectivo por bocas de pago, billeteras digitales, criptomonedas y otros medios.

Ahora, en esencia, si bien cada usuario tiene sus preferencias en cuánto a métodos de pago, lo que necesita a fin de cuentas es PAGAR para adquirir su producto. Y si bien implementar pagos con criptomonedas puede ser una idea atractiva, debemos considerar cuál es el caso de uso qué tiene mayor impacto y requiere menor esfuerzo. En este ejemplo, la gran parte de nuestros usuarios cuentan con tarjetas de crédito y débito, y hay múltiples proveedores que nos ofrecen infraestructura para poder aceptar pagos a través de estos medios con una simple integración.

Entonces, en lugar de desarrollar de forma completa una feature, podemos encontrar su expresión mínima que habilite un gran beneficio a toda la plataforma. Luego ya tendremos tiempo para iterar nuestro producto y la propia funcionalidad, agregando nuevos casos de uso que permitan la captación de nuevos segmentos de usuarios, formen ventajas competitivas y explotemos su potencial.

‍

Sobre las “low-hanging fruits”

Esencialmente, una low-hanging fruit en producto es la regla 80/20 aplicada a una feature particular. Tenemos distintas formas de embarcar el desarrollo de una idea, y, naturalmente, algunas un poco más rebuscadas que otras. Una low-hanging fruit cae en aquel sector donde percibimos un grado relativamente bajo de esfuerzo y un alto impacto esperado. Esta es básicamente su definición, así de sencillo.

La disciplina Growth Hacking lleva años pensando de esta manera. Su principal desafío se encuentra en fomentar el crecimiento de nuestra base de usuarios de forma escalable. Es una práctica frecuente diseñar experimentos y pruebas pequeñas que puedan impulsar la adquisición de usuarios. Siempre se están implementando y descartando nuevas ideas de forma eficiente, cuidando los recursos y tiempo del equipo.

‍

‍

De todas formas, si bien el valor de las low-hanging fruits es evidente, es importante ejecutar una estrategia de desarrollo de producto con criterio. Existen situaciones donde quizás desarrollar features al mínimo esfuerzo no sea la mejor opción, o directamente no sea viable. Esto puede suceder por ejemplo en situaciones como:

• Segmentos de clientes exigentes que demandan máxima calidad.
• Productos de naturaleza sensible (ej: plataformas de gestión médica).
• Productos altamente regulados (ej: bancos digitales).
• Respuesta a la competencia
• Decisiones estratégicas y objetivos ambiciosos (en algún momento hay que trabajar sobre los asuntos de gran valor pero de gran esfuerzo)

En el caso de que ninguna de las situaciones previamente mencionadas apliquen, entonces podremos trabajar nuevas features desde un enfoque mínimo para ir luego escalando en complejidad una vez hayan sido validadas con los usuarios. Tradicionalmente la técnica de tomar una funcionalidad compleja y dividirla en pequeñas partes se llama slicing, y existen diversos criterios para reducir esta complejidad. Algunos criterios que pueden aplicar para esta técnica son:

• Capacidad: reducimos el alcance de la funcionalidad. Por ejemplo, en lugar de diseñar 4 filtros, implementamos solo uno: por precio.
• Camino feliz: desarrollamos únicamente el flujo donde las cosas salen bien. No hay caminos alternativos, desviaciones lógicas, mensajes de error o empty states.
• Tercerización: nos apalancamos en un servicio externo para ofrecer la funcionalidad sin necesidad de un desarrollo propio. Puede implicar el desarrollo de una API.
• Tecnología: realizamos la feature para una única resolución de pantalla, navegador, sistema operativo o tipo de dispositivo.
• Segmento: desarrollamos la funcionalidad para un tipo de usuario concreto.

‍

Matrices de priorización

Una vez comprendida la regla 80/20 y el concepto de low-hanging fruit, creo que es importante presentar algunas formas de priorización que existen en Product Management. Ya que, después de todo, una low-hanging fruit puede ser identificada a partir de este proceso.

La tarea de priorización no es una tarea sencilla. Varias herramientas buscan simplificar esta actividad en un par de variables, lo que puede resultar engañoso cuando la realidad nos obliga a realizar una análisis más sofisticado. Por otro lado, existen algunas variables que se repiten en cada ronda de priorización mientras qué hay otras más específicas que se encuentran únicamente en situaciones determinadas. Aquí va un listado de variables de priorización:

• Impacto: refiere al valor esperado y puede abrirse en dos - impacto esperado por el usuario e impacto esperado por el negocio, ya que no siempre una iniciativa de producto favorece a ambos (aunque como Product Managers deberíamos procurar porque los objetivos del usuario y del negocio estén alienados).
• Esfuerzo: nivel de involucramiento del equipo. Refiere a la cantidad de recursos que se deben destinar para su desarrollo (sean económicos, cognitivos, tiempo, etc).
• Urgencia: apunta a las restricciones temporales y necesidad de ejecutar cierta tarea en un plazo breve de tiempo.
• Riesgo: refiere al nivel de incertidumbre inherente en la tarea.
• Otras: viabilidad técnica y financiera, existencia de dependencias, impacto a largo plazo, magnitud/alcance (a cuantas personas afecta), gravedad (cual es el impacto negativo en caso de tenerlo), probabilidad de ocurrencia, etc

‍

‍

En producto muchas veces utilizamos herramientas de priorización para guiar nuestro trabajo. En las fases iniciales de un proyecto solemos contar con la libertad de correr mayores riesgos y las instancias de priorización no son tan sofisticadas, por lo que frecuentemente utilizamos herramientas como:

• Matriz de Eisenhower: evalúa features según su impacto y urgencia
• Criterio Valor/Esfuerzo: evalúa features según su impacto y esfuerzo
• Criterio MoSCow: categoriza features en base a cuatro niveles de prioridad: “Must have”, “Should have”, “Could have” y “Won’t have”.
• Matriz de evaluación de riesgos: evalúa el impacto y la probabilidad de un suceso
• Modelo KANO: categoriza features en base a las expectativas del usuario y el nivel de satisfacción que provee.

En caso de requerir un análisis más extenso, las distintas funcionalidades pueden someterse a la evaluación de distintas variables a través de una matriz. Podemos enlistar distintas ideas en una tabla y crear columnas que hagan referencia a distintas variables. Luego estableceremos una escala númerica para evaluar cada idea por variable, y asignaremos puntajes. En caso de que hayan variables de mayor importancia que otras, podemos ponderarlas para que tengan un mayor peso a la hora de calcular el puntaje final promedio.

‍

Pensar en pequeño y en grande: algunos ejemplos

Para cerrar el artículo, presentaré algunos ejemplos para orientar el concepto de low-hanging fruit a la práctica:

Ejemplo 1 - Microcopy

A veces la inclusión de un pequeño texto puede lograr grandes resultados. Por ejemplo, en el caso de que muchos usuarios se sientan inseguros a la hora de realizar una compra en línea, se puede acompañar el flujo de checkout como textos del estilo “Compra 100% segura”, “14 días de prueba”, “Contamos con política de reembolsos”, “Garantía oficial incluida” para aportar confianza y lograr un gran incremento en la tasa de conversión y las ventas totales.

Ejemplo 2 - Cupones de referidos

Los programas de referidos son bastante utilizados porque representan una forma escalabe de adquirir usuarios a través de tu base actual de clientes activos. Un incentivo económico es muy poderoso, especialmente cuando se ofrecen beneficios para los dos lados: tanto la persona que refiere como el referido pueden obtener descuentos o puntos que les pueden ser de utilidad. Uber persiguió durante un buen tiempo esta estrategia en su expansión, como tras tantas startups.

Ejemplo 3 - Curación de contenido

Los productos cuyos modelos de negocio están apalancado en UCG (user generated content) comparten un desafío similar cuando crecen en escala: la búsqueda de nuevo contenido útil y relevante se vuelve tedioso al existir tantas publicaciones. Por lo que funcionalidades básicas de filtrado, búsqueda y ordenamiento pueden tener un valor muy grande para los usuarios, así cómo también la curación de contenido y recomendación de publicaciones de alta calidad. Youtube es un claro ejemplo, cuyo feed está altamente customizado en base a nuestras preferencias e historial.

Ejemplo 4 - Social sharing

Nuestro progreso en diversas apps nos enorgullece, y premiamos a nuestros usuarios por eso. Este puede ser el caso de apps de fitness con rutinas de ejercicios para realizar seguimiento, apps de dieta o incluso plataformas de educación. Si habilitamos a los usuarios para que puedan compartir de forma rápida sus logros con otras personas entonces quizás podremos habilitar crecimiento viral. Un ejemplo de esto pueden ser los certificados de Coderhouse.

En resumen, pensar para cada iniciativa de producto cuáles son nuestras low-hanging fruits nos lleva a tener una mentalidad de optimización constante, donde buscaremos generar continuamente un alto valor al menor esfuerzo posible. Es un enfoque ideal para reducir riesgo de implementación y para experimentar nuevas features cuyo valor final aún no es claro. Cómo todo producto, es naturalmente que tras el éxito de un low-hanging fruit busquemos atrapar frutas más altas en el árbol: es parte del trabajo de iteración en producto. Pero nuestro primer acercamiento debe ser altamente enfocado y con criterio.

¡Y eso es todo!  Espero que hayan disfrutado el artículo. Me ayudarían mucho en compartirlo con las personas que crean que les será útil. ¡Te aconsejo que te suscribas a Productified para no perderte ninguna novedad!