Discovery de producto: problemas antes que soluciones
La mayor parte del software que se construye no se usa. No porque esté mal hecho, sino porque se construyó sobre un problema que nadie verificó. Discovery es el trabajo de verificarlo antes, y le toca también a quien programa.
El desperdicio más caro de un equipo de software no es el código mal escrito: es el código bien escrito que nadie usa. Y casi siempre tiene el mismo origen: alguien pidió una solución —«hace falta un tablero con filtros»— y el equipo la construyó sin preguntar qué problema resolvía.
Discovery es el trabajo de convertir un pedido en un problema verificado antes de escribir la primera línea. No es una etapa previa que hace otra persona: es una costumbre de preguntar, y quien programa es quien más barato puede ejercerla.
Del pedido al problema
Un pedido viene con la solución adentro. Lo que hay que recuperar es lo de atrás: qué está pasando hoy, cada cuánto, y qué hace la persona mientras tanto.
| El pedido | La pregunta que lo abre | Lo que suele aparecer |
|---|---|---|
| «Necesitamos exportar a Excel» | ¿Qué hacés con el archivo cuando lo bajás? | Lo pegan en otra planilla para un informe mensual: quizás el informe se puede generar solo |
| «Queremos notificaciones push» | ¿Qué se pierden hoy por no enterarse a tiempo? | Se enteran tarde de un solo evento crítico: un mail puede alcanzar |
| «Hace falta un buscador» | ¿Qué estabas buscando la última vez? | Siempre buscan lo mismo: un filtro fijo resuelve el 80% |
| «El sistema es lento» | ¿En qué pantalla y a qué hora? | Una sola consulta al cierre del mes, no el sistema entero |
| «Queremos un tablero» | ¿Qué decisión vas a tomar con eso? | Ninguna: querían saber si un proceso terminó |
Antes de seguir, predecí
Cómo se pregunta
Plantilla
Entrevista de discovery, 20 minutos
Contexto (3 min)
¿Cómo es un día típico tuyo con esta parte del sistema? ¿Cuándo la usás?
Sin mencionar la idea todavía. En cuanto la nombrás, la conversación se convierte en una opinión sobre tu idea.
La última vez (8 min)
Contame la última vez que tuviste que armar ese informe. ¿Qué hiciste exactamente, paso por paso?
El corazón de la entrevista. Hechos concretos y recientes, no generalidades. Si dice «normalmente hago…», volvé a traerlo a la última vez.
El apaño (4 min)
¿Y cuando no te alcanza con eso, qué hacés? ¿Alguna planilla aparte, alguien a quien le pedís?
Los apaños son la evidencia más fuerte de un problema real: alguien invirtió trabajo propio en resolverlo.
El costo (3 min)
¿Cuánto tiempo te lleva? ¿Cada cuánto te pasa? ¿Qué pasa si sale mal?
Sin esto no se puede priorizar después: un problema sin frecuencia ni costo no compite contra nada.
Cierre (2 min)
¿Hay algo que no te pregunté y que debería haberte preguntado?
La pregunta que más veces trae lo importante, porque abre lo que no estaba en tu guion.
| Señal | Qué tan fuerte es | Por qué |
|---|---|---|
| Alguien construyó un apaño propio | Muy fuerte | Invirtió tiempo real en resolverlo sin que nadie se lo pidiera |
| Lo mencionan sin que preguntes | Fuerte | Está arriba en su cabeza |
| Pagarían por resolverlo | Fuerte, si es real | Sólo vale si hay presupuesto y decisión, no como opinión |
| Lo piden varias personas distintas | Media | Puede ser el mismo pedido copiado |
| Dicen que estaría bueno | Débil | Es cortesía |
| Lo pidió alguien con jerarquía | No es señal de problema | Es señal de prioridad política, que es otra cosa y conviene no confundir |
Un pedido que llega cerrado
Escenario · 1 decisión como mínimo
El área comercial pide un tablero con filtros, para el mes que viene
El responsable comercial escribe: «necesitamos un tablero con filtros por vendedor, zona y producto, para el 30». Tu equipo tiene capacidad para eso y para nada más este mes. ¿Qué hacés primero?
Entregás el tablero el 28. A los dos meses, los registros de uso muestran nueve visitas en total, todas del mismo día.
DesenlaceUn mes de equipo para una pantalla que nadie usa y que igual hay que mantener. Lo doloroso es que se podía saber antes con una sola pregunta: qué se iba a hacer con esos datos.
Dos semanas después te enterás de que armaron el informe a mano, con tres personas y dos días por semana.
DesenlaceEl problema era real y grande; el pedido, una mala solución. Decir que no a un pedido sin entender el problema descarta las dos cosas juntas.
En la llamada contás que querés entender el uso. Te dicen: «los lunes revisamos qué vendedores quedaron abajo del objetivo, y armar esa lista nos lleva toda la mañana». ¿Qué proponés?
El tablero sale y lo usan los lunes.
DesenlaceResultado aceptable: resolvió el problema. El costo de oportunidad es lo que no se ve: el mismo resultado estaba disponible por una semana de trabajo, y las otras tres se podían usar en otra cosa.
El mail automático sale en cuatro días. A las tres semanas preguntan si se le puede agregar la comparación con el mes anterior.
DesenlaceEl mejor final, y el pedido de la comparación lo confirma: ahora están pidiendo sobre algo que usan de verdad, que es la única clase de pedido que vale la pena escuchar sin discutir. Con las tres semanas que sobraron se hizo otra cosa.
Fijate que en ningún camino se discutió si el pedido era razonable. Discovery no es decir que no: es cambiar la pregunta de «¿lo hacemos?» a «¿qué problema resuelve?».
Cómo se descubre antes de construir
| Pregunta | Cómo se responde | Qué no sirve |
|---|---|---|
| ¿El problema existe? | hablar con quien lo tiene | preguntar si les gustaría una funcionalidad |
| ¿Les importa? | ver qué hacen hoy para resolverlo | que digan que sí |
| ¿Nuestra solución sirve? | un prototipo que puedan usar | una descripción |
| ¿Se puede construir? | una rebanada delgada de punta a punta | una estimación sobre un documento |
| ¿Conviene? | el costo contra el valor esperado | la intuición de quien lo pidió |
Cierre
Autoevaluación
¿Lo entendiste?
Práctica