Pregunta en cualquier foro de producto qué fases tiene el desarrollo de un producto digital y recibirás la misma respuesta de siempre: discovery, definición, diseño, desarrollo, lanzamiento. Quizás con alguna variante de naming. Quizás con un diagrama de diamante doble si el que responde tiene cierta afición a los frameworks. La respuesta es correcta y, al mismo tiempo, casi inútil.
El problema no es que el modelo de fases sea falso. Es que describe el proceso como si fuera un embudo limpio y secuencial cuando, en la práctica, es más parecido a una obra civil: hay replanteos, hay cimientos que condicionan todo lo que viene encima, hay momentos en los que la realidad obliga a volver atrás, y hay decisiones tomadas en fase temprana que se pagan —con intereses— en producción. Y nadie en la obra te lo dice en la primera reunión.
Este post no repite el modelo estándar. Lo lee desde dentro, con los problemas reales que aparecen en cada fase, y propone el criterio que en Room 714 aplicamos para que cada etapa sirva a la siguiente sin crear deuda que se cobre más tarde.
- Las fases no son el problema: lo es la ilusión de que son estancas y no se retroalimentan.
- La arquitectura técnica que eliges en semanas 2 y 3 te persigue durante años.
- El lanzamiento no es el final: es el momento en que el producto deja de ser tuyo y empieza a ser del usuario.
Discovery: La Fase que Decide Todo lo Demás (y que Muchos Acortan)
La fase de discovery tiene mala fama en según qué contextos. A veces porque dura demasiado y no produce nada tangible; a veces porque dura demasiado poco y produce un falso mapa de certezas. Ambos extremos son caros, pero el segundo lo es más: un discovery apresurado es una deuda de comprensión que se paga en forma de rediseños, cambios de alcance en mitad del sprint y funcionalidades construidas para un usuario que nadie investigó bien.
La pregunta que guía un buen discovery no es "¿qué quiere el usuario?". Esa pregunta devuelve listas de features. La pregunta correcta, desde el marco Jobs-to-be-Done, es "¿qué progreso está intentando conseguir el usuario que hoy no puede conseguir bien?". La diferencia parece sutil; en la práctica determina si construyes un producto que resuelve algo o un catálogo de funcionalidades bien empaquetadas.
En esta fase, los entregables que importan son tres: una definición compartida del problema (no del producto), una hipótesis de valor clara y falsable, y una decisión sobre qué no se va a construir. Este último punto es el más difícil y el más valioso. Un buen discovery termina con restricciones explícitas, no solo con posibilidades abiertas.
Un discovery que termina con "todo es posible" no ha terminado: ha pospuesto las decisiones difíciles al momento más caro, que es cuando ya hay código escrito.
Arquitectura y Diseño: El Momento en que las Decisiones se Vuelven Caras de Revertir
La mayoría de los proyectos tratan el diseño y la arquitectura técnica como fases paralelas que se coordinan al final. Es un error con consecuencias predecibles: el diseño propone flujos que la arquitectura no soporta sin reescribir media capa de servicios, o la arquitectura toma decisiones de estructura de datos que obligan al diseño a renunciar a interacciones que eran clave para la experiencia.
En Room 714 tratamos estas dos disciplinas como una sola conversación, aunque la tengan personas distintas. El diseñador necesita saber qué puede costar medio sprint y qué puede costar tres semanas. El arquitecto necesita entender qué flujos son críticos para el usuario antes de elegir cómo modelar los datos. Cuando esa conversación no ocurre, el producto resultante es técnicamente correcto y experiencialmente mediocre —o al revés.
Arquitectura: el coste de las decisiones invisibles
La elección de arquitectura en un producto digital nuevo rara vez se hace con el tiempo que merece. El equipo tiene presión de arrancar, hay un deadline que alguien puso en un slide, y las decisiones de estructura se toman por defecto —"usamos lo que conocemos"— o por moda —"todo el mundo usa microservicios"—. Ambos criterios son igualmente pobres si no pasan antes por la pregunta de qué necesita este producto en concreto.
Un monolito bien estructurado puede ser la respuesta correcta para un producto que aún no sabe qué va a escalar. Una arquitectura de microservicios puede ser la respuesta correcta para un equipo grande con dominios bien definidos. El error es aplicar el patrón sin entender el contexto. Como hemos escrito antes al hablar de orquestación de herramientas de IA, el problema no suele ser la elección tecnológica en sí, sino no saber por qué se elige.
Diseño: lo que el prototipo no puede simular
El diseño en esta fase tiene una trampa específica: los prototipos funcionan bien en condiciones de laboratorio y mal en condiciones reales. En un test de usabilidad con Figma, el usuario sabe que está evaluando algo; en producción, el usuario tiene prisa, tiene el teléfono con el 12% de batería y acaba de recibir una notificación. El diseño tiene que anticipar ese contexto, no el contexto del test.
Esto no significa que los prototipos sean inútiles —son imprescindibles—. Significa que hay que diseñar deliberadamente para las condiciones adversas: flujos de error, estados vacíos, degradación progresiva cuando algo falla. Esas pantallas son las que más se ven en producción y las que menos tiempo reciben en la fase de diseño.
Desarrollo: Velocidad, Deuda y el Mito del Sprint Perfecto
El desarrollo iterativo funciona. Los sprints funcionan. Lo que no funciona es tratar cada sprint como una unidad independiente que optimiza su propio output sin pensar en la estructura que va acumulando. La deuda técnica no se genera en los bugs; se genera en las decisiones de atajos que parecen razonables en el sprint 3 y que en el sprint 15 hacen que cualquier cambio sea una excavación arqueológica.
Hay tres tipos de deuda que vemos repetidamente en productos que llegan a nosotros para ser rescatados o modernizados. La primera es la deuda de comprensión: código que nadie entiende del todo porque se escribió rápido y sin documentar la decisión. La segunda es la deuda de acoplamiento: módulos que dependen unos de otros de formas no explícitas, de modo que tocar uno rompe otro. La tercera —y la más cara— es la deuda de arquitectura: una estructura de base que no soporta los casos de uso que el producto ha ido adquiriendo.
Esta tercera categoría es la que convierte lo que debería ser una migración de tres meses en una reescritura de un año. Y suele tener su origen en la fase anterior: arquitectura elegida por defecto, bajo presión de tiempo, sin la conversación que mencionábamos antes. Vale la pena leer también nuestro análisis sobre cómo las decisiones de diseño de sistemas se pagan en producción cuando los supuestos iniciales ya no aguantan la realidad.
La velocidad de desarrollo no se mide en story points por sprint. Se mide en cuánto tarda el equipo en hacer el décimo cambio importante, no el primero.
El antídoto no es ir despacio. Es ir con criterio. Hay atajos que cuestan poco y se pagan poco; hay atajos que cuestan poco ahora y se pagan con intereses compuestos. Distinguirlos es parte del trabajo de ingeniería que los equipos suelen no tener tiempo de hacer —o no tienen el mandato de hacer— bajo presión de entrega.
Lanzamiento y Post-Lanzamiento: La Fase que el Roadmap Siempre Subestima
El lanzamiento de un producto digital tiene una paradoja: es el momento de máxima visibilidad y, a la vez, el momento en que menos información tienes sobre si lo que has construido funciona. Los tests internos, los betas cerrados, los pilotos con usuarios seleccionados son útiles pero estructuralmente sesgados: los usuarios que participan en ellos no son los usuarios medios, tienen más paciencia, más motivación para dar feedback y menos representatividad del comportamiento real en producción.
El primer mes post-lanzamiento debería tratarse como una fase de observación activa, no de desarrollo a pleno rendimiento. El equipo necesita instrumentación suficiente para ver dónde se rompe el flujo, qué features se usan y cuáles no, dónde aparece fricción que no fue prevista. Sin esa instrumentación, el equipo toma decisiones de roadmap basadas en opiniones internas, que son el sustituto más caro de los datos reales.
Aquí es donde la experiencia de cliente vuelve a ser central. Un producto puede funcionar técnicamente y tener una tasa de adopción pésima porque el flujo de activación tiene tres pasos que parecían razonables en el diseño y que en producción resultan incomprensibles para el 40% de los usuarios. Detectar eso en la semana 2 post-lanzamiento y corregirlo en la semana 4 es el tipo de agilidad que realmente importa. Detectarlo en el mes 6, cuando ya hay churning de usuarios que nunca activaron, es mucho más caro.
El producto vivo: mantenimiento como decisión estratégica
Después del lanzamiento, los productos digitales entran en una fase que los roadmaps suelen llamar "mantenimiento" con cierta condescendencia, como si fuera algo menor respecto al desarrollo inicial. No lo es. El mantenimiento es la fase en que se decide si el producto mejora o se degrada lentamente mientras el equipo persigue nuevas features.
Un producto sin inversión continua en su salud técnica y en su experiencia acumula deuda en ambas dimensiones. La deuda técnica ya la hemos mencionado. La deuda de experiencia es menos visible pero igual de real: flujos que funcionaban bien cuando el producto tenía 500 usuarios empiezan a crujir cuando tiene 5.000, no porque el código falle, sino porque los casos de uso han cambiado y el diseño no ha evolucionado con ellos.
La decisión estratégica en esta fase no es cuánto invertir en mantenimiento, sino cómo estructurar el equipo y el proceso para que la evolución del producto sea continua y no reactiva. Un equipo que solo actúa cuando algo se rompe es un equipo que siempre va por detrás de sus usuarios. Y los usuarios, cuando llevan suficiente tiempo esperando mejoras, dejan de esperar.
Si tienes un producto que ya existe y estás evaluando cómo estructurar su desarrollo a partir de ahora —qué fase priorizar, qué deuda atacar primero, cómo organizar el equipo—, en nuestra práctica de desarrollo de software de producto trabajamos exactamente eso: diagnóstico técnico, priorización de arquitectura y diseño de la evolución. Sin dogma de metodología, con criterio de negocio.
