El principal objetivo del discovery es reducir el riesgo de desarrollar una solución que no cumpla las expectativas de los usuarios o los objetivos de la empresa. Probar las posibles soluciones, comparándolas con las reacciones de tus usuarios y la realidad sobre el terreno, te permite reducir aún más el riesgo de fracaso antes de lanzarte al desarrollo.
Tipos de pruebas de soluciones
Validar la propuesta de valor
Cuando empiezas a tener ideas para soluciones, e incluso antes de diseñar un prototipo, puedes comprobar que se entiende bien la propuesta de valor de una funcionalidad. Una prueba de propuesta de valor te permite validar el atractivo de una funcionalidad utilizando medios poco costosos, como la prueba de humo.
La prueba de humo consiste en simular que la funcionalidad ya existe y evaluar las reacciones de los usuarios. Puedes adoptar la forma de un botón falso, un anuncio que resuma la propuesta de valor o una página de aterrizaje falsa. También se conoce como prueba de la puerta falsa, porque la funcionalidad no existe realmente y no es posible utilizarla una vez atravesada la puerta de prueba. Evaluando el porcentaje de usuarios que hacen clic en el botón, visitan la página de destino o dejan comentarios, puedes estimar el éxito futuro de esta funcionalidad.
Sin embargo, ten cuidado, porque las pruebas de propuesta de valor, como las pruebas de humo, pueden llevar a la decepción de los usuarios cuando se den cuenta de que la solución propuesta no está disponible. Ten cuidado de no quebrantar la confianza de los usuarios ni dañar la imagen del producto. Presta especial atención al mensaje que transmites en la interfaz de esta prueba. En lugar de fingir que ha ocurrido un error técnico, es mejor ser claro con el usuario, explicándole que la función está prevista para un futuro próximo e invitándole a dar su opinión.
Este artículo es un extracto del libro:
Probar la usabilidad de la solución
Las pruebas de prototipos permiten comprobar si la solución es fácil de usar y entender. Por tanto, es muy útil para averiguar cómo mejorar la experiencia de usuario de una funcionalidad.
Para llevar a cabo este tipo de prueba, es recomendable trabajar con Product Designers para diseñar un prototipo basado en maquetas interactivas. El prototipo puede ser más o menos detallado y fiel a la realidad de la funcionalidad prevista. La prueba se lleva a cabo durante una serie de entrevistas con los usuarios, durante las cuales se observa su comportamiento, se recogen sus impresiones y acciones y, por último, se registran sus impresiones.
Al final de una prueba de prototipo, se obtienen las señales adecuadas para poder decir si se ha logrado el ajuste Problema/Solución, es decir, si la solución parece responder al problema. Ten cuidado, estas señales verifican que la solución es buena sobre el papel, pero no garantizan que la aplicación vaya a satisfacer a los usuarios en una situación real. Por eso es importante no sacar generalizaciones precipitadas de los resultados obtenidos, y completarlos estableciendo el valor y midiendo el comportamiento real.
Probar aportando valor
Validar el valor con un MVP
El objetivo del MVP (Producto Mínimo Viable) es aprender probando el valor en lugar de entregar un producto o una funcionalidad. El enfoque MVP se utiliza para detectar el ajuste producto/mercado, es decir, si el producto o la funcionalidad satisfacen las expectativas del mercado.
El MVP se basa en el bucle Construir-Medir-Aprender de la metodología Lean Startup. Este proceso iterativo se utiliza para probar la necesidad y el compromiso de un público reducido, los usuarios tempranos (early adopters), proporcionando el valor mínimo. No se dirige inmediatamente al público más amplio, conocido como la mayoría temprana (early majority).
Los diferentes objetivos de los usuarios (Diagrama de Geoffrey A. Moore)
¡Pensar en un MVP significa pensar en grande, empezar en pequeño! Frente a la filosofía Get Big Fast, que consiste en lanzar rápidamente un producto industrializado sin validar antes su atractivo para los usuarios. Incluso Facebook, que ahora se dirige al gran público, empezó dirigiéndose a los estudiantes de Harvard antes de expandirse a otras universidades estadounidenses, luego a institutos, etc., adaptando su producto a cada ocasión.
Para llevar a cabo su prueba del MVP, puedes llegar a ofrecer una versión muy manual de sus funciones. Conocidas como Mechanical Turk, Wizard of Oz o Concierge Test, estas pruebas pretenden simular manualmente la experiencia final, dando al mismo tiempo la impresión de una forma de automatización. De este modo, el valor lo aporta un ser humano en lugar del código. Por ejemplo, Airbnb probó un sitio web en el que los fundadores ofrecían su propio piso en alquiler. Otro ejemplo sería un chatbot, manejado en realidad por un humano con escenarios de respuesta predefinidos.
Herramientas No-Code para pruebas rápidas
El enfoque No-Code permite crear productos digitales sin necesidad de conocimientos de programación, utilizando herramientas que simplifican el desarrollo. Esto permite lanzar rápidamente una versión funcional para probar y aprender de los usuarios sin grandes compromisos de desarrollo. Ejemplos de empresas que han utilizado este enfoque incluyen Qonto y Payfit.
Cómo realizar pruebas de soluciones
Decidir qué Probar y qué no probar
No todas las soluciones necesitan ser probadas. Algunas funcionalidades relacionadas con limitaciones técnicas o de bajo riesgo pueden desarrollarse directamente. Sin embargo, cuanto más innovadora o compleja sea una solución, más pruebas serán necesarias. Evalúa el riesgo y el coste de volver atrás si la solución no funciona como se espera.
Definir la hipótesis y los criterios de éxito
Hay que empezar por definir las hipótesis que se pretenden validar o refutar, basándose en las posibles soluciones identificadas como resultado del descubrimiento. A continuación, para validar o rechazar estas hipótesis, hay que definir uno o varios criterios de éxito, incluido un umbral de rendimiento a partir del cual las hipótesis puedan considerarse validadas. Para ayudarte a definir este umbral, utiliza los datos de que dispongas o elige un valor por debajo del cual no desees invertir en desarrollo.
Si las hipótesis están mal definidas o son demasiado generales, los criterios de éxito son poco o nada relevantes y los umbrales de rendimiento se eligen sobre la marcha, el análisis del rendimiento de la solución será defectuoso. Al final, todo el proceso puede hacer perder más tiempo del que ahorra. Para ayudarte a definir correctamente estos elementos, piensa en tus objetivos.
Ejecutar las pruebas
Elige la prueba más adecuada para validar tus hipótesis, generando datos cuantitativos o cualitativos. Puedes complementar los resultados con entrevistas para entender por qué se obtuvieron ciertos resultados. Esta combinación de datos ofrece una visión más profunda del valor que los usuarios perciben en tu solución.
Analizars de los resultados
Una vez recopilados los datos de la prueba, pregúntate si se han alcanzado los umbrales de éxito definidos. Si no es así, considera que la prueba ha refutado las hipótesis y que debes buscar otras soluciones posibles. Pero que no cunda el pánico. Ten en cuenta que el objetivo es aprender.
En caso de fracaso total, no habrás perdido el tiempo ni el presupuesto: comprender que vas por mal camino desde el principio minimiza las pérdidas. Por último, también es posible que valides la solución, pero también que se te ocurran nuevas hipótesis que poner a prueba. En este caso, puede que te resulte necesario iniciar una nueva prueba.
Nuestros Consejos
- Sé objetivo: No te apegues emocionalmente a las soluciones. Evalúa los resultados según los criterios de éxito establecidos.
- Estrategia de despliegue gradual: Si decides no probar, puedes limitar riesgos lanzando una funcionalidad a un pequeño grupo de usuarios antes de expandirla.
- Ten en cuenta las restricciones: Si las limitaciones de marca o seguridad dificultan pruebas de humo o MVP, opta por pruebas de prototipo para minimizar los riesgos sin comprometer la imagen.
Para saber más: descarga nuestro libro Las Claves del Product Management
