¿Qué pasa después del discovery? El desafío de definir qué construir

Terminar el Discovery no significa que un equipo esté listo para desarrollar. Antes de comenzar, todavía queda un trabajo clave: acordar qué se va a construir, qué quedará fuera del alcance y qué preguntas deben resolverse para evitar retrabajos más adelante.

Cumplir con las fechas comprometidas, optimizar recursos y demostrar impacto forman parte del día a día de quienes lideran productos. Con esa presión por avanzar, es fácil asumir que, una vez terminado el Discovery, es momento de comenzar el desarrollo.

Sin embargo, terminar esa etapa no siempre significa que el equipo esté listo para dar el siguiente paso. Muchas veces todavía quedan decisiones importantes por tomar: qué se va a construir, qué quedará fuera del alcance o qué preguntas necesitan responderse antes de comenzar.

Cuando esas conversaciones no se dan de manera explícita, es fácil asumir que todos entendieron lo mismo. Esa sensación de alineación suele durar hasta que el desarrollo está en marcha y empiezan a aparecer interpretaciones distintas, cambios de alcance o funcionalidades que terminan resolviendo algo diferente a lo que se esperaba.

Las consecuencias de esa falta de definición no siempre aparecen de inmediato. De acuerdo con el reporte global Pulse of the Profession 2023 del Project Management Institute (PMI), el rendimiento deficiente en los proyectos genera un desperdicio promedio del 5,2% de la inversión total (lo que equivale a US$0,052 por cada dólar gastado). Esta cifra se dispara de forma alarmante cuando los equipos fallan en comunicarse y colaborar de manera efectiva: en organizaciones que no priorizan estas habilidades de alineación, la pérdida presupuestaria sube hasta alcanzar un 8,8%. Además, la falta de una visión común provoca que el 40% de los proyectos sufra de deslizamiento de alcance, obligando a re-trabajos constantes (frente a solo un 28% en entornos con buena comunicación).

Más allá de las cifras, detrás de esos resultados suele repetirse el mismo patrón: equipos que empiezan a desarrollar antes de asegurarse de que todos están hablando de lo mismo.

Cuando todos dicen que sí, pero no a lo mismo

Hay conversaciones que parecen innecesarias hasta que alguien hace una pregunta muy simple. Por ejemplo: ¿qué significa exactamente que un pedido está “completado”?

Aunque parezca una pregunta sencilla, la respuesta cambia según quién la responda. Para un equipo de operaciones puede significar que el pedido salió de la bodega; para quienes desarrollan un sistema de seguimiento, en cambio, puede significar que el cliente ya lo recibió.

Ninguna de las dos respuestas es incorrecta. La diferencia es que esa interpretación suele aparecer cuando el desarrollo ya avanzó o incluso cuando el producto ya está siendo utilizado. Es recién en ese momento cuando el equipo descubre que una misma palabra significaba cosas distintas para cada área.

Algo parecido ocurre con conceptos mucho más cotidianos. ¿Qué entendemos por un “usuario nuevo”? Para marketing puede ser cualquier persona que completó el registro, mientras que para producto será alguien que ya utilizó el servicio por primera vez.

Ambos equipos trabajan con la misma información, pero están respondiendo a preguntas distintas.

Mirar el producto como un todo

Es común que los equipos definan cada funcionalidad por separado y que recién al momento de integrarlas aparezcan conexiones que nadie había considerado, recorridos incompletos o decisiones que obligan a volver atrás.

El problema rara vez está en una funcionalidad en particular. Generalmente aparece en lo que ocurre entre ellas: esos espacios donde nadie se detuvo a pensar cómo una decisión impactaba en la siguiente o cómo todas las piezas terminaban construyendo una experiencia.

Mirar el producto como un todo permite identificar esos vacíos antes de que comience el desarrollo. ¿Qué necesita hacer realmente el usuario? ¿Qué pasos son indispensables? ¿Qué parte del recorrido todavía no está cubierta?

Herramientas como el User Story Mapping ayudan justamente a armar una visión compartida de la experiencia completa y, desde ahí, definir las funcionalidades que darán forma a la solución.

Ese ejercicio también facilita una de las decisiones más importantes para quienes lideran productos: qué construir primero, qué puede esperar para una siguiente iteración y qué, al menos por ahora, quedará fuera del alcance.

Definir para avanzar con claridad

Dedicar tiempo a definir qué se va a construir puede parecer un retraso, especialmente cuando ya existe evidencia de que vale la pena desarrollar una solución.

Sin embargo, ese tiempo permite evitar uno de los problemas más costosos en el desarrollo de productos: descubrir demasiado tarde que el equipo no compartía el mismo entendimiento sobre lo que debía construir.

Por eso, antes de comenzar el desarrollo, vale la pena hacerse una última pregunta: ¿cualquier persona del equipo podría explicar qué se va a construir, para quién y qué quedará fuera del alcance? Si la respuesta es sí, probablemente existe una base sólida para avanzar.

Dedicar tiempo a definir no retrasa el desarrollo. Muchas veces es lo que permite que el equipo avance con mayor claridad, reduzca el retrabajo y tome mejores decisiones durante el desarrollo.

La IA como apoyo para acelerar la definición

Las herramientas de inteligencia artificial (IA) pueden ser un apoyo durante la etapa de definición. Por ejemplo, pueden ayudar a organizar la información obtenida durante el Discovery, identificar preguntas que todavía no tienen respuestas o generar una primera propuesta de User Story Mapping.

También pueden ser útiles para detectar vacíos en la definición, ordenar las funcionalidades según el recorrido del usuario o transformar esas ideas en un primer plan de trabajo.

Sin embargo, su principal aporte está en acelerar el análisis y la documentación, no en reemplazar las conversaciones del equipo. Definir qué se va a construir, qué quedará fuera del alcance o cómo se abordarán las preguntas abiertas sigue siendo una tarea que requiere contexto, criterio y acuerdos compartidos.