Crear un producto digital sin un proceso claro es como construir sin planos. Entender el problema del usuario es solo el inicio; lo que marca la diferencia es contar con un flujo estructurado que permita generar valor de forma continua, medir resultados y mejorar con cada iteración. Aquí se presenta el flow framework, un modelo flexible que organiza el desarrollo de producto en etapas concretas, métricas accionables y una distribución inteligente de tareas.
¿Qué es el flow framework y por qué elegirlo?
Existen muchos frameworks para gestionar la creación de producto, y cada equipo debe encontrar el que mejor se adapte a su organización. El flow framework parte de una premisa poderosa: todo lo que hacemos debe generar valor para el usuario [0:36]. Esa premisa se traduce en el concepto de value stream o cadena de valor, un camino donde cada paso existe para entregar algo significativo al cliente final.
Este marco se compone de tres pilares:
- Cuatro etapas del flujo de valor: ideación, creación, release y operación.
- Métricas duales: del flujo de trabajo y del negocio.
- Distribución de tareas según su naturaleza: features, bugs, deuda técnica y riesgo.
Lo importante no es seguir la metodología al pie de la letra, sino tomar lo que genera valor y adaptarlo a las necesidades reales del equipo [8:49].
¿Cómo funcionan las cuatro etapas del value stream?
¿Qué ocurre en la etapa de ideación?
La ideación inicia con la comprensión del problema del usuario y termina cuando existe un prototipo validado listo para desarrollo [2:22]. El product manager trabaja de la mano con el product designer para prototipar, entrevistar usuarios y asegurarse de que la solución propuesta se adapte a quienes la van a usar.
¿Qué implica la creación y el release?
En la etapa de creación, los desarrolladores toman el prototipo validado, comprenden el producto que se quiere construir y lo desarrollan [3:03]. Un punto clave: los desarrolladores deben participar desde etapas tempranas. Caer en un sistema de cascada, donde cada fase es estrictamente secuencial, no es efectivo para el desarrollo de producto.
Una vez el producto está listo, se pasa al release: ponerlo disponible para los clientes finales.
¿Por qué la operación es parte esencial del producto?
Que el software esté disponible no significa que el trabajo terminó. La operación abarca todo lo necesario para que la experiencia funcione en la vida real [3:46]. Si en Uber un conductor y un pasajero tienen un conflicto, eso es operación. Si en Airbnb un huésped llega a una casa que no coincide con lo publicado, eso también es parte del producto.
Además, operar incluye medir si lo liberado generó valor o no. Tanto en éxito como en fracaso, entender las razones permite iterar y seguir mejorando [4:30].
¿Qué métricas importan en el flow framework?
Las métricas del flujo miden la velocidad, la eficiencia de recursos y la carga de trabajo de cada miembro del equipo [4:52]. La diferencia frente a Scrum es que el flow framework no encasilla el trabajo en sprints fijos. Si un MVP se puede hacer en dos días, el flujo dura dos días. Si robustecer un producto toma cuatro semanas, también es válido [5:33]. El objetivo es buscar la mayor eficiencia posible para lograr iteraciones rápidas, sin pretender que un equipo nuevo funcione como una máquina desde el primer día.
Desde el lado del negocio, las métricas clave son:
- Valor vs. costo: ¿lo que generamos supera la inversión en nómina y tiempo? [6:36]
- Calidad: no sirve lanzar cada dos semanas si el producto está lleno de errores [7:08].
- Felicidad del cliente: medida a través del NPS (Net Promoter Score), quejas en Customer Success o netnografía, que consiste en rastrear la huella digital de los usuarios para entender su percepción [7:30].
¿Cómo se distribuyen las tareas dentro del flujo?
El flow framework clasifica el trabajo en cuatro tipos [9:22]:
- Features: funcionalidades nuevas que antes no existían.
- Bugs: errores en el código que afectan la experiencia. Se clasifican en críticos (impiden usar el producto), funcionales (permiten usar el producto pero sin experiencia óptima) y estéticos.
- Deuda técnica: código que se acumula y hace más lento al equipo con el tiempo. Entender su valor futuro es clave, incluso cuando no se puede medir de inmediato [10:19].
- Riesgo: tareas vinculadas a amenazas que podrían acabar con la empresa o, por el contrario, detonar crecimiento. A veces se asumen riesgos sin resolverlos; otras veces es imprescindible actuar [10:50].
Como product manager, eres el abogado del cliente dentro de la empresa [11:12]. Clasificar correctamente estas tareas requiere empatía genuina con el usuario y el criterio que se construye al entender profundamente sus problemas. Esa capacidad de liderazgo es lo que permite dirigir al equipo con claridad y propósito.
¿Ya usas algún framework en tu equipo o estás buscando implementar uno? Comparte tu experiencia y qué elementos del flow framework crees que podrían funcionar en tu contexto.
