Antes de escribir una sola línea de código, un product manager debe confirmar que lo que diseñó y validó con usuarios realmente se puede construir, cumple las reglas del negocio y tiene sentido económico. Este proceso se llama viabilidad y recorre cuatro frentes: legal, ingeniería, diseño y finanzas. Saltarse cualquiera de ellos pone en riesgo el recurso más caro de todos: el tiempo de desarrollo.
¿Cómo se valida la viabilidad legal y técnica de un producto?
Cuando la empresa opera en una industria regulada, el primer paso es llevar el prototipo al área legal y verificar que sea compliant con las normativas internas y externas [0:28]. Si la empresa no está regulada, este paso simplemente se omite.
Después se presenta el prototipo al equipo de ingeniería —engineer manager, tech lead y las personas clave— para responder preguntas concretas [0:44]:
- ¿La arquitectura actual soporta lo que se propone?
- ¿Se necesita crear un sistema nuevo o modificar uno existente?
- ¿Qué tan rápido o complejo será el desarrollo?
Durante estas conversaciones aparece un concepto fundamental: el trade off. A veces, un ajuste pequeño en el diseño del prototipo reduce enormemente la complejidad técnica [1:02]. Aceptar ese intercambio significa tener un scope —una cobertura— más reducido, pero iterar más rápido.
¿Qué pasa cuando el código existente necesita un refactor?
Es frecuente que el área de la aplicación que se va a tocar ya acumule deuda técnica [1:30]. La negociación consiste en definir hasta dónde se puede saldar esa deuda dentro del mismo ciclo. El acuerdo resultante queda registrado para que no haya sorpresas durante la ejecución.
¿Qué se revisa con el equipo de diseño?
Con el design manager se evalúa si la experiencia propuesta representa el mejor esfuerzo posible y, en caso de que exista una alternativa superior, cuánto tiempo adicional requeriría [1:50]. Un punto crítico es confirmar que se está usando el design system de la aplicación [2:01].
- Si se propone un componente nuevo, hay que justificarlo.
- Si el prototipo se desvía del sistema de diseño, se corrige antes de pasar a desarrollo.
Esta revisión garantiza coherencia visual y de interacción con el resto del producto.
¿Cómo se demuestra la viabilidad financiera con un P&L?
La última validación no se confirma con el prototipo sino con números. El product manager, como persona de negocio, debe construir un documento llamado P&L (profits and losses), conocido en español como PyG —pérdidas y ganancias— [2:20].
Este documento no necesita ser sofisticado; su objetivo es mostrar:
- Costos mensuales: salarios del equipo, herramientas, infraestructura tecnológica y cualquier gasto recurrente que implique el producto [2:35].
- Retorno esperado: puede ser revenue directo, mejora en retención o incremento en adquisición de usuarios [2:55].
El equipo de finanzas traduce métricas como retención o adquisición a impacto monetario para decidir si la inversión vale la pena. Es exactamente como levantar inversión para una startup o medir el retorno de una campaña publicitaria [3:10]: se trata de justificar una inversión, no un gasto.
¿Por qué el one pager debe estar completo antes de desarrollar?
Una vez que se tiene la viabilidad de todos los equipos, los acuerdos se documentan en el one pager y el producto queda listo para desarrollo [3:30]. A partir de ese momento, no debería haber cambios.
Cada modificación durante el desarrollo implica:
- Desperdiciar tiempo del equipo.
- Escribir código que luego se borra.
- Generar trabajo que nunca llega a producción.
El product manager actúa como gatekeeper —guardián de la puerta— del equipo de desarrollo [3:45]. Solo se acepta un cambio si es absolutamente crítico. Si faltó considerar algo en las etapas previas, es un error del proceso, y lo correcto es aprender de él e incorporar esa lección para que no se repita.
¿Por qué el desarrollo de producto es un ciclo continuo?
Mientras el equipo construye la funcionalidad validada, el product manager ya está corriendo el proceso completo con la siguiente idea [4:10]. Definir problema, entender al usuario, prototipar, probar y validar viabilidad se repite de forma continua para que, al terminar un desarrollo, el siguiente ya esté lo más seguro posible para entrar a construcción.
Si quieres profundizar en cómo comunicar todo este trabajo más allá del one pager o en cómo detectar huecos en tu proceso antes de que cuesten tiempo de ingeniería, comparte en los comentarios qué parte del ciclo te resulta más desafiante.
