Desarrollar software es una forma bastante cara de descubrir que una idea era mala.
Puedes pasar seis semanas construyendo una funcionalidad y obtener la respuesta en cinco minutos después de enseñársela a un usuario.
Product discovery intenta invertir ese orden.
Primero aprender.
Después construir.
No elimina el riesgo.
Pero consigue que compres evidencia de una forma mucho más barata.
Qué es product discovery
Product discovery es el proceso de reducir incertidumbre antes de desarrollar una solución.
Normalmente intenta responder preguntas como:
- ¿este problema existe de verdad?
- ¿es suficientemente importante?
- ¿a qué usuarios afecta?
- ¿cómo lo resuelven hoy?
- ¿nuestra solución tiene sentido?
- ¿sería usable?
- ¿movería alguna métrica importante?
- ¿merece el coste de desarrollarla?
Discovery no significa hacer entrevistas eternamente.
Significa aprender lo suficiente para tomar una decisión mejor.
Empieza por el riesgo más grande
No todas las ideas tienen la misma incertidumbre.
A veces dudas de si existe demanda.
Otras veces sabes que el problema existe, pero no sabes si la solución es usable.
O si técnicamente es viable.
O si alguien pagaría.
Yo identificaría primero qué tendría que ser verdad para que la idea funcionara.
Y después preguntaría:
¿Cuál de esas cosas es la que menos segura está?
Ese debería ser el primer experimento.
No empieces diseñando la solución
Es muy fácil enamorarse de una funcionalidad.
"Necesitamos un dashboard."
"Tenemos que poner un chat."
"Los usuarios quieren exportar a Excel."
Antes de dibujar pantallas intentaría expresar el problema.
¿Qué intenta conseguir el usuario?
¿Qué le impide hacerlo hoy?
¿Qué coste tiene?
¿Con qué frecuencia ocurre?
Si no entiendes bien eso, estás validando una implementación.
No una necesidad.
Separar problema y solución también mejora el product roadmap.
Entrevistas: busca comportamiento, no opiniones
No preguntaría:
"¿Usarías una funcionalidad que hiciera X?"
Es muy fácil responder que sí.
Preguntaría:
"¿Cuándo fue la última vez que tuviste este problema?"
"¿Qué hiciste?"
"¿Cuánto tardaste?"
"¿Qué herramienta utilizaste?"
"¿Qué pasó si no lo resolviste?"
El comportamiento pasado suele ser una señal más útil que una intención futura.
Busco ejemplos.
No cumplidos.
Habla con usuarios que tengan el problema
También importa a quién entrevistas.
Si preguntas a cualquiera, obtendrás feedback genérico.
Intentaría seleccionar usuarios que cumplan el contexto donde creo que existe el problema.
Si estamos investigando churn de un SaaS, hablaría con quienes se dieron de baja.
Si investigamos onboarding, con nuevos usuarios que abandonaron antes de activarse.
Si estamos pensando en una función para equipos, con cuentas donde ya colaboran varias personas.
Discovery mejora muchísimo cuando el grupo tiene un motivo real para hablar del problema.
Datos cuantitativos: encuentra dónde mirar
Las entrevistas explican contexto.
Los datos ayudan a saber dónde merece la pena investigar.
Por ejemplo:
- un paso del funnel con abandono alto;
- una funcionalidad usada solo por clientes que retienen;
- un segmento con churn especialmente bajo;
- búsquedas recurrentes dentro del producto;
- tickets de soporte repetidos.
No necesitas tener una infraestructura analítica perfecta.
Pero sí alguna evidencia de comportamiento.
En SaaS, muchas investigaciones empiezan mirando activación u onboarding.
Prueba la solución más barata posible
Una vez entiendes el problema, intentaría validar la solución sin construirla completa.
Dependiendo del caso:
- un prototipo;
- una landing;
- un botón falso;
- una demo;
- un proceso manual;
- una hoja de cálculo;
- un servicio realizado por una persona;
- una versión extremadamente reducida.
No intentas engañar al usuario.
Intentas responder una pregunta concreta.
Si queremos saber si las empresas pagarían por un informe automático, quizá primero podemos generar ese informe manualmente.
Si nadie lo quiere ni así, automatizarlo no arreglará la demanda.
Define qué evidencia cambiaría tu decisión
Antes del experimento escribiría qué esperamos aprender.
Por ejemplo:
"Si al menos cinco de diez usuarios con este problema intentan utilizar la función, seguiremos."
O:
"Si los usuarios completan el prototipo sin ayuda y entienden el resultado, pasaremos a desarrollo."
No porque esos números sean universales.
Sino porque decidir antes evita reinterpretar cualquier resultado como una victoria.
Discovery sirve para matar ideas también.
Eso es una buena noticia.
Has ahorrado desarrollo.
Qué ocurre cuando los usuarios piden algo
Una petición de usuario es una señal.
No una orden.
Intentaría descubrir:
- qué problema intenta resolver;
- cuánto le afecta;
- si otros usuarios lo comparten;
- qué hace hoy;
- y qué ocurriría si no lo solucionamos.
Si varias personas piden soluciones distintas para el mismo problema, ahí suele haber una oportunidad interesante.
El trabajo de producto consiste en encontrar el patrón.
No en contar votos de funcionalidades.
Product discovery y estrategia de producto
Discovery no debería investigar cualquier cosa.
La estrategia de producto define dónde queremos competir y qué resultados nos importan.
Discovery reduce incertidumbre dentro de ese espacio.
Sin estrategia puedes hacer experimentos muy buenos sobre problemas que no son importantes para el negocio.
Sin discovery puedes tener una estrategia correcta y construir soluciones equivocadas.
Necesitas ambas.
Discovery antes y después del product market fit
Antes del product market fit, discovery suele ser más amplio.
Estás aprendiendo:
- quién es realmente el cliente;
- qué problema duele;
- qué propuesta genera interés;
- qué experiencia entrega valor.
Después puedes utilizarlo de forma más localizada.
Cómo mejorar retención.
Qué segmento expandir.
Qué necesidad adyacente resolver.
Qué funcionalidad priorizar.
El proceso cambia de escala.
No de lógica.
Cuánto discovery es suficiente
Tampoco convertiría discovery en una excusa para no lanzar.
No necesitas certeza.
Necesitas reducir el riesgo más importante hasta un nivel razonable.
Si una funcionalidad cuesta dos horas, quizá no merece una semana de investigación.
Si implica tres meses de trabajo, cambia la cosa.
El esfuerzo de discovery debería ser proporcional al coste de equivocarse.
Una secuencia sencilla
Si tuviera que resumirlo:
- Define el problema.
- Identifica el mayor riesgo.
- Busca evidencia existente.
- Habla con usuarios relevantes.
- Diseña el experimento más barato.
- Decide qué resultado cambia la decisión.
- Ejecuta.
- Aprende.
- Construye, cambia o descarta.
No hace falta llamarlo framework.
Hace falta hacerlo antes de comprometer semanas.
La regla que usaría
La pregunta de discovery no es:
¿Podemos construirlo?
En software, la respuesta suele ser sí.
La pregunta útil es:
¿Qué necesitamos aprender antes de decidir si merece la pena construirlo?
Ahí está casi todo el valor.