4 validaciones para evitar desperdiciar esfuerzo y dinero en algo que nadie use

Nota: este artículo fue originalmente publicado en ProductosDigitalesGanadores.com

En general solemos tener un montón de ideas para construir en nuestro producto. Abundan las fuentes para generarlas: pedidos de los clientes, proyectos de los stakeholders, competidores que avanzan con algo que no podemos no tener, partners que traen nuevas propuestas, y desde ya las propias cosas que el equipo proponga.

Lamentablemente, de esas ideas un 70% o más no van a tener ningún impacto de negocio. A veces esto pasa desapercibido cuando vemos publicaciones de compañías sobre resultados de las últimas features lanzadas, pero la verdad es que esas historias esconden lo que vivimos desde dentro: incontables intentos silenciosamente “apagados” para llegar a esa que tiene éxito.

Imaginen este escenario muy simplificado:

• Contratamos un equipo de desarrollo de un promedio de 4 personas, a unos U$3.000 mensuales de costo, construyendo en promedio 1 feature por mes. Construir 10 features nos costará U$S120.000 (y 10 meses de esfuerzo) y U$S84.000 habrán sido gastado en cosas que no tendrán retorno de negocio…

[Antes de profundizar y aprovechando que llegaste hasta acá, quiero contarte que el 21-7 estaré haciendo una clase online gratuita sobre estos temas, y puedes registrarte aquí. -Listo, no interrumpo más-]

Esto no es descabellado, por el contrario, los números suelen ser mucho mayores en compañías establecidas (y son los que pueden fundir un startup)… En general el negocio logra generar los resultados necesarios para que los U$S36.000 invertidos en funcionalidades rentables generen más que los U$S120.000 invertidos en el desarrollo total, y la rueda sigue girando.

¡Pero imaginen cuánto mayor sería el retorno de las inversiones si pudiéramos predecir ese 30% antes de empezar!

Seguramente lo estamos haciendo mal

Desde ya que esto no es nuevo, nadie hace “a proposito” 70% de features que no logran nada.

En un enfoque tradicional, antes de empezar a construir algo, trataremos de dilucidar en base a supuestos, cuáles de esas opciones de producto o features tienen más chance de tener éxito. Haremos cálculos de segmentos de clientes potenciales, tasa de conversión esperada, precio promedio y todos los factores estimados que nos podrían ayudar a priorizar qué funcionalidad es la correcta para hacer primero.

Incluso vamos a hablar con clientes, a preguntarles qué quieren o que nos digan si les gustaría este nuevo feature que estamos planeando construir.

Lamentablemente igual vamos a equivocarnos. Es posible que todo eso nos sirva para fallar sólo el 70% y no el 95%, pero la historia demuestra que aún no alcanza para discernir el 30% útil.

Por más expertos que seamos, no tenemos buenos fundamentos para esas hipótesis: en productos digitales el pasado no es tan buen predictor del futuro, y en general estaremos buscando hacer algo “novedoso” (a.k.a. innovador) con lo cual no habrá siquiera mucho pasado en el cual basarse.

Y respecto a nuestras entrevistas con clientes… bueno, ya repetí muchas veces la frase de Steve Jobs, “la gente no sabe lo que quiere hasta que no lo ve”, así que de poco nos sirve que digan que quieren, y peor aún si nos dicen que quieren algo es posible que sea no sea un buen indicador de su comportamiento futuro (más sobre esto en breve).

¿Qué es Product Discovery?

Ahora, ¿que pasa si tenemos una forma rápida de mostrar ese 100% de ideas a los clientes como productos “reales”, y validar con sus respuestas y reacciones cual debemos hacer primero?

Product Discovery o “Descubrimiento de producto” (y también podrás encontrar el mismo principio bajo otros nombres como Discovery Sprint o Discovery Framework entre otros) es una fase previa a la construcción de un producto digital -o a agregar una nueva funcionalidad-, cuyo objetivo es identificar cuáles de las ideas que tuvimos realmente vale la pena construir.

El equipo que esté trabajando en esta fase es el encargado de transformar este gran listado de posibles “funcionalidades” en un backlog que sepamos que tiene ítems que aportan valor, buscando de la forma más rápida y barata posible generar aprendizaje validado (validated learning), es decir que haya sido obtenido de clientes reales y que sean resultados tangibles.

(Una breve ilustración de Product Discovery en un entorno de Dual Track Agile)

¿Cómo validamos antes de haberlo construido?

La metodología de Product Discovery cuenta con una serie de técnicas y herramientas especialmente diseñadas para probar ideas rápido. Las podemos conocer como MVP Test, Pruebas de concepto, o prototipado rápido.

En esencia son distintas formas de prototipar nuestra idea, lo suficientemente reales como para poder ponerlo frente al usuario como si fuesen un producto real (con algunas excepciones que veremos luego) y pedirles que realicen una acción o nos cuenten su experiencia sobre algo que están viendo y podamos tomar eso como aprendizaje de cómo nuestra solución está llegando al usuario.

¿Qué características debemos validar?

Bajo la premisa de validar “lo más barato posible”, no podemos darnos el lujo de validar absolutamente todo. Eso lo volvería lento y costoso que va contra la premisa que buscamos.

Debemos limitarnos a los aspectos más riesgosos de lo que estamos persiguiendo,  que en general está dentro de estas 4 características:

• Deseable para suficientes usuarios (demanda)
• Valioso para el usuario
• Usable
• Factible que lo construyamos

Demanda

En primer lugar queremos saber si una idea va a tener una masa crítica suficiente de usuarios. Es decir, sin gastar aún ni un minuto de esfuerzo en profundizar la idea y pensar una solución, queremos ver si es un problema que realmente existe y necesita ser solucionado, y que si lo hacemos tendremos una masa suficiente de clientes que lo querría.

• ¿Cómo podemos validar esto en 1 día sin aún tener un producto que mostrar?

La forma más fácil es poner en una landing page la propuesta de valor que tiene el producto o feature que estamos ideando, con un botón “call to action” de compra o registro y medir la conversión (o CTR) que éste tenga.

(Nota: luego de apretar el botón los usuarios verán un cartel del estilo “gracias por su interés, aún lo estamos construyendo”, pero el grado de frustración generado será bajo en comparación con todo el aprendizaje obtenido).

De esta forma, podrán saber el porcentaje de su público objetivo que estaría dispuesto a usar su propuesta, sin haber invertido ni una línea de código para hacerlo. Existen infinidad de herramientas para montar una landing page para enviar este tráfico, como Lead Pages, Wix, Unbounce, etc, que no requieren conocimiento alguno de programación.

[Para más formas de validación de demanda pueden buscar en la guía gratuita de Product Discovery que verán más opciones y ejemplos]

Valioso (¿están dispuestos a pagar?)

El segundo aspecto que suele ser riesgoso es si efectivamente los usuarios están dispuestos a “comprar” (o usar, o efectuar cualquier compromiso que requiera por su parte), es decir si es lo suficientemente valioso para intercambiar algo de valor para ellos (dinero, tiempo, etc).

Por eso para esta característica buscamos algún tipo de pre-compra o confirmación concreta (por ejemplo un compromiso escrito) que usarán lo que estamos construyendo.

Si bien puede no resultarnos agradable cobrar dinero en un estadío tan prematuro, se ha comprobado cientos de veces que la pregunta “lo comprarías” suele ser contestada con un “por supuesto” que después no se condice con la realidad cuando efectivamente lanzamos. Por eso, debemos desafiar ese “por supuesto” con un “ok, ingresa los datos de tu tarjeta de crédito aquí”.

Acá también gracias a servicios novedosos podemos realizar pruebas sin hacer una línea de código. Por ejemplo, podemos con Paypal o MercadoPago, enviar por mail un link para que nos realicen un depósito y validar la tasa de gente que realmente pagó.

Usable

Siguiendo con tratar de validar (y aprender) de lo más riesgoso tenemos que obtener aprendizaje cuantificable sobre si los usuarios entienden y pueden usar nuestra idea de solución. Querremos ver si pueden completar en nuestro “prototipo” las tareas que necesitamos que hagan en el producto real.

Básicamente un prototipo es una representación gráfica del sistema que vamos a tener. La idea es traducir tu idea a algo que pueda mostrarse a usuarios como parte de las pruebas que estás realizando.

Los prototipos pueden tener distintos grados de “fidelidad”, empezando por un dibujo en un papel, hasta llegar a una imagen de alta calidad que se vea tal cual se verá el sitio o aplicación terminado y que reaccione a clicks, haciendo que el usuario no pueda distinguir la diferencia con un producto real (el ejemplo de la izquierda sería algo de baja fidelidad, y el de la derecha lo mismo pero con diseño final).

En general cuando hagamos pruebas podemos empezar por algo de baja fidelidad para una prueba más orientada a que se entienda el corazón de la solución y la propuesta de valor, y luego ir ganando en fidelidad para entender si nuestra solución es usable, si la elección de diseño atrae a los usuarios, si la posición de los elementos es la más adecuada, etcétera).

Si bien para los prototipos de alta fidelidad requerimos trabajo de diseñadores gráficos, para empezar con los primeros podemos usar herramientas gratis al alcance de cualquiera cómo Balsamiq, Mockinbird, y muchos más.

Y para mostrar prototipos reales con comportamiento, es decir, que reaccionen a los clicks, tampoco hace falta usar código, podemos usar herramientas como InvisionApp, Axure, e incluso PowerPoint! (y también existen soluciones para Mobile Apps).

Factible que lo construyamos

Validar la factibilidad suele tener que ver con 2 aspectos:

1. Si la tecnología es muy novedosa para el equipo (ejemplo: construir una app para iPhone si somos un equipo que hace aplicaciones web, o hacer algo para un nuevo wereable) necesitamos antes de comprometernos o embarcarnos a máxima velocidad en su construcción, que el equipo gane algo de conocimiento en esa tecnología y pueda tener mayor certeza en su grado de confianza para realizarlo.
2. Validar que los stakeholders vayan a soportar la idea. Imaginen el desperdicio si un stakeholder ve el producto por primera vez cuando está terminado luego de las iteraciones de validación y construcción, y ahí decide que no lo podemos lanzar al mercado. Al ver un prototipo en Discovery va a poder darnos ese mismo feedback pero antes que hayamos gastado $1 en su construcción.

(Nota: en este aspecto no solo piensen en “jefes”, también piensen en otros departamentos, como Legales o Customer Service. Soy de la opinión que más involucramiento temprano implique más “trabajo temprano”, pero es infinitamente más barato que involucramiento tardío que implique modificaciones.)

Conclusión

Cómo proponía en el título validar estos 4 aspectos que suelen ser los más riesgosos y pueden hacer que el 70% de nuestras iniciativas falle no nos cuesta demasiado esfuerzo ni dinero. Con las herramientas adecuadas (que acabo de presentar pero seguramente ya conocías) y voluntad para cambiar la forma de trabajar, podemos probar cualquier idea en 1 día, dejar de teorizar en base a supuestos y “salir de la oficina” para obtener feedback real de clientes y poder hacer mucho más efectivos los esfuerzos que haga el equipo al crear el producto.

[Si te interesó, puedo aportar más detalles, herramientas y explicaciones paso a paso sobre Product Discovery y estás técnicas. El 21 de Julio estaré haciendo una clase online gratuita a la que puedes registrarte aquí!]

Me encantaría que dejen en los comentarios  sus opiniones al respecto, si están validando o no estas características y los desafíos que están encontrando para hacerlo.