Antes de validar ideas, aterriza el problema

segunda parte del 12,5%

Ideas se nos ocurren a todos

Ana entró en la sala. Sin decir ni una palabra, arrancó el proyector y sobre el blanco lienzo proyectó una imagen con una montaña de billetes y en mayúsculas se leía:

Queremos aumentar 15 puntos el porcentaje de personas que activan la versión premium del producto

Nadie dijo nada.

— ¿Y bien? — dijo Ana — ¿Qué podemos hacer para conseguir el objetivo de este trimestre? ¡Ideas, quiero ideas!

Tímidamente la sala empezó a aportar:

• Crear un tramo más bajo para animar a los usuarios gratis a cruzar la barrera de pago

• Ofrecer un descuento los primeros 3 meses del plan actual para incentivar la compra

• Ofrecer gratis siete días del plan actual para atraer más usuarios

• Incluir una funcionalidad del plan superior en el plan barato

• Crear un plan de referidos con descuentos para los usuarios existentes

• …

---

No hay más historia.

Me he inventado un problema “razonable” y me he autoimpuesto pensar en ideas que puedan aumentar la conversión. Y he conseguido que me salgan varias. Luego podría haber votado, priorizado, … para elegir la mejor y después empezar con todo el ciclo de validación, desarrollo y monitorización. Este proceso ocurre en todas las empresas. Hay veces que lo camuflamos de agile, poniendo postits en paredes y dejando que todo el mundo hable de forma respetuosa y colaborativa, pero la realidad es que si pides ideas, saldrán ideas. Y de ese torrente de ideas, lo más normal es que sólo el 12,5% de ellas funcionen como esperamos.

Hace un año aproximadamente escribí un artículo acerca de este tema, que, aunque no tuvo tanta actividad como me esperaba, para mí ha sido uno de esos artículos que he ido recordando durante el año en varios momentos. La última vez fue la semana pasada grabando el podcast con los fundadores de FeatureIt y al terminar decidí continuar el artículo con los aprendizajes de este año.

El mensaje se mantiene igual, solo el 12,5% de las ideas funciona porque:

• Solo la mitad de las ideas son buenas

• Solo la mitad de las ideas buenas se implementan bien

• Solo la mitad de las ideas buenas bien implementadas provocan el cambio que esperamos en el comportamiento del usuario

Asimilar cada una de ellas, implica un ejercicio de humildad por parte de los equipos de producto. Al final, son los que conocen el problema y la solución mejor que nadie. Que cuentan con profesionales con experiencia en tecnología, UX y negocio. Que conocen cuáles son las buenas prácticas para hacer producto digital de forma ágil. Y aun así sólo un 12,5% de las ideas funcionarán. ¡Qué bajón…

Cuando afirmo que el sólo el 12,5% de las ideas funcionan, hay una condición que dejo fuera sin querer y es que estoy hablado de las ideas que resuelven los verdaderos problemas de la empresa. Poner el login social de Google o Stripe como pasarela de pago, en el 90% de los casos serán buenas ideas. Utilizar el servicio de dockers de una nube pública o una librería de React con componentes para ir más rápido, también será una buena idea. Cambiar tu onboarding en el que aparecen dos cajas de texto para recopilar el email y la contraseña, por uno con imágenes del producto y la propuesta de valor, probablemente será una buena idea.

Ahora bien: ¿cómo reduzco un 50% la latencia en ese servicio que ya estaba optimizado? ¿cómo consigo que más gente active la versión de pago en el producto? ¿cómo consigo que los usuarios no dejen de usar a la aplicación?

Este tipo de problemas son los que generan un porcentaje tan elevado de “malas ideas”. Porque aquí también hay que aclarar, que no son malas ideas. Simplemente son ideas que, como dice el título, no funcionan.

Está claro que para reducir la tasa de ideas que no funcionan, lo inmediato que viene a la cabeza es que hay que validar el éxito de las ideas antes de empezar con la fase de desarrollo para mejorar nuestras probabilidades de acierto. Revisando el artículo del año pasado, me he dado cuenta de que me faltó incluir un punto previo que es crítico.

Las ideas vienen después de acotar el problema y definir unas hipótesis de tu entendimiento de los motivos detrás del comportamiento del usuario.

Aumentar el porcentaje de usuarios de pago no es un problema con el que pueda trabajar un equipo de producto. Hay que entender bien el contexto que tienen esos usuarios para no convertir a usuarios de pago. Por un lado, podemos analizar el segmento de usuarios a los que pertenecen. Podemos clasificarlos por el tiempo que llevan desde que se registraron en el producto, ver si usan de forma recurrente algunas de las funcionalidades gratis, analizar si responden a los correos de activación que se mandan. Todo ello, enriquecerá tu hipótesis con la que trabajarás a continuación para poder proponer esas ideas.

Un ejemplo de hipótesis bien trabajada podría parecerse a esta:

Los usuarios que llevan utilizando dos meses la funcionalidad principal de mi tramo gratuito, no activan el modo de pago porque desconocen el valor que les puede aportar.

Una de las ventajas de trabajar con hipótesis tan aterrizadas, es que las puedes validar con mucha facilidad. Tienes una hipótesis acotada del motivo por el que tus usuarios no hacen el upgrade y puedes preguntar a ese segmento de tus usuarios a través de un formulario, un correo, una entrevista. Si al preguntar a tus usuarios, todos ellos responden con éxito cual es la funcionalidad por la que estas pagando, puedes plantear una segunda hipótesis con la que trabajar y seguir con el ciclo.

Una segunda hipótesis podría ir en la siguiente línea:

Los usuarios que llevan utilizando dos meses la funcionalidad principal de mi tramo gratuito, no activan el modo de pago porque es caro.

Con cada iteración no sólo nos acercamos a la verdad absoluta, sino que además por el camino vamos dejando migas de pan con las pistas que vamos encontrando.

Este proceso se tiene que llevar de forma rigurosa, validando todas las partes de la hipótesis:

• Dos meses

• Utilizando la funcionalidad

• El precio

Sólo cuando acertamos de forma contundente toda la hipótesis, podemos continuar al siguiente paso que es el de proponer ideas. Hasta entonces no tiene sentido que continúes, ya que en pasos posteriores si no observas ese cambio en el comportamiento, no podrás decir de forma contundente si el problema ha sido la solución o la hipótesis.

Además, definir las hipótesis así, te permitirte hilar mejor con las soluciones que pueden satisfacer a esos usuarios, y, por tanto, la validación de esas soluciones será mucho más sencilla.

Tienes una población validada de forma cualitativa sobre la que deberías observar un cambio de comportamiento cuantitativo cuando implementes los cambios.

Identificar las ideas que transformarán el rumbo de la empresa es un desafío. Es fácil que se introduzcan sesgos del equipo durante el proceso y olvidemos que los usuarios piensan y actúan de manera diferente a nosotros. La clave para encontrar buenas ideas es realizar un ejercicio previo de definición clara del problema y de hipótesis específicas. Esto nos permitirá consolidar el aprendizaje y crear un entorno de trabajo riguroso para validar y ejecutar eficazmente las soluciones propuestas.

¡Si tienes en el equipo un compañero que piensa en ideas a las que buscar justificación en vez de buscar problemas bien justificados que resolver, compártele el artículo y deja tus opiniones!

---

Si te perdiste la primera parte: