Cómo conseguir de verdad que las cosas se construyan
El 8 de mayo de 2025 he hecho algunas ediciones para aclarar varios puntos. Me preocupaba haber quitado mérito al trabajo duro que lleva construir productos y quería dejarlo claro. He dejado aquí mi redacción original como referencia. No quiero ofender a nadie, pero sí ser honesto sobre los retos que tenemos. Puede que lo hiciera sin querer. Pido disculpas y he cambiado el texto para ganar claridad.
Los equipos de producto suelen complicarlo todo.
Escriben PRDs larguísimos, hacen investigación de usuarios exhaustiva y siguen las metodologías Agile al pie de la letra. Pero por el camino pierden de vista lo importante: dar valor a los usuarios.
Esa complicación es un síntoma de que les importa. La gente quiere hacer un buen trabajo, así que amontona procesos y documentación. Pero más capas no significan más claridad. A menudo solo lo ralentizan todo.
Los equipos de producto suelen tratar los PRDs como el mapa definitivo de la entrega: detallados, meditados y basados en investigación con clientes. Y con razón.
Pero desde la ingeniería, esos documentos a veces parecen optimizados para la trazabilidad y el contexto, no para la claridad de ejecución.
No es una crítica al rigor ni al enfoque. Si acaso, refleja lo complejo que se ha vuelto el desarrollo de producto moderno. Pero cuando estoy construyendo, necesito un plano. Una visión clara y simplificada de lo que se espera, de cómo funciona y de qué aspecto tiene el éxito en código.
Súmale los fallos de comunicación. Los equipos trabajan de maneras distintas. Sin un lenguaje común ni alineación, esas diferencias abren huecos. Y los huecos generan retrasos.
Luego está el MVP, mal entendido y mal usado. No consiste en lanzar una versión a medio hacer del producto. Es una apuesta de entregable mínimo: una hipótesis comprobable con lo justo construido para probar o refutar algo. ¿Y si no cuaja? Se mata y se sigue.
“Keep It Simple, Stupid”, el viejo principio KISS, sigue vigente. La sencillez está infravalorada. Sobre todo cuando intentas construir algo rápido con un equipo de gente lista que piensa cada uno de una manera.
Dave Thomas, uno de los autores del Manifiesto Ágil, lo dijo bien:
“Agile has become a noun, and that’s the problem. We need to focus on agility.” (Agile se ha convertido en un sustantivo, y ese es el problema. Tenemos que centrarnos en la agilidad.)
La agilidad es el objetivo. No las reglas, no los rituales, solo la capacidad de respuesta. Quieres poder cambiar de rumbo sin fricción.
El camino es clarísimo: menos lastre, más claridad.
Empieza con planos de una página. Solo lo esencial:
- Recorridos de usuario: ¿quién intenta hacer qué?
- Prioridades MoSCoW: ¿qué hay que hacer sí o sí y qué queda fuera?
Trátalos como documentos vivos. Guárdalos en Notion o donde colaboréis. Cuando algo cambie, actualiza el plano. Avisa al equipo. Si el cambio es grande, reserva un rato para reagruparos.
Esa es tu fuente de verdad, no una herramienta de gestión de proyectos ni un tablero de Jira.
Usa Linear (o Jira, si te va el sufrimiento) para seguir lo que hay que hacer. No para registrar casos límite ni el historial de decisiones. Si un caso límite importa, añádelo a los criterios de aceptación o recógelo en el plano. Si no, no ensucies el tablero.
En la implementación técnica, los ingenieros pueden apoyarse en UML, diagramas entidad-relación, diagramas de secuencia, lo de siempre. Ese es su mundo. Pero el resto del documento es una carta de Producto a Ingeniería. Y debería leerse como tal.
Clara. Enfocada. Sin relleno.
Y cuando algo ya está construido, probarlo no es solo cosa de desarrollo. Producto es dueño de la hipótesis. Hablaste con los usuarios. La acotaste. Ahora vuelve y valídala. ¿Funcionó? ¿Resolvió de verdad el problema?
Todo este proceso, cuando va fino, es una máquina preciosa. Cuando no, es un desastre. Pero la solución no es más proceso. Es menos. Justo la cantidad necesaria. Suficiente para alinear a la gente, no para paralizarla.
Si quieres profundizar: