Hace unos meses hablaba con un responsable de producto de una importante aceleradora. Me comentó que casi cada startup con la que habla tiene una forma distinta de hacer producto.
Yo llevo tiempo observando exactamente lo mismo.
Con el tiempo he llegado a una conclusión incómoda. En muchos casos no estamos viendo “muchas formas” de Product Management, sino un waterfall “tuneado” que se disfraza de producto.
Igual que pasó con Agile.
Adoptamos sprints, dailies, ceremonias y herramientas. Pero lo que define de verdad Agile —aprender rápido, co-crear y adaptar el rumbo— apenas cambió. El modelo de fondo seguía siendo el mismo: plan cerrado, control, fechas comprometidas y éxito medido por entregas. Parecía mejor. Pero seguía siendo waterfall.
Con Product Management pasa algo parecido ya que incorporamos prácticas valiosas… pero sin cambiar lo que de verdad importa. El resultado es un “waterfall tuneado” que se ve moderno, suena bien, pero no cambia cómo se toman decisiones ni qué se considera éxito.
El “agujero negro” del waterfall
El waterfall es poderoso por dos motivos.
El primero es obvio, da control. Decide qué vamos a hacer, cuándo estará, cuánto costará. Reduce incertidumbre. Da tranquilidad.
El segundo es más sutil, viene de la inercia. Llevamos años trabajando así. Cambiarlo no es solo “aplicar un framework nuevo”; es cambiar hábitos, roles, expectativas y, sobre todo, la relación con la incertidumbre.
Y aquí aparece el choque ya que el Product Management es incómodo.
Te pide que trabajes con hipótesis. Que aceptes que no sabes. Que midas lo que ocurre. Que hables con usuarios. Que cambies el plan si lo aprendido lo exige. Que priorices por impacto, no por “lo que toca entregar”.
Cuando esa transición no se hace bien, el waterfall no desaparece. Solo aprende a camuflarse.
Hacer producto no va de PRÁCTICAS. Va de resultados.
Para mí, la definición es simple:
Hacer producto va de mover métricas y conseguir resultados.
No como una frase vacía, sino como un compromiso con objetivos claros. Primero decides qué resultado quieres lograr y qué métrica lo representa. Luego trabajas hacia eso entendiendo problemas reales, tomando decisiones con información, validando lo que desarrollas, aprendiendo rápido y ajustando el rumbo.
Si eso no está en el centro, todo lo demás se convierte en decoración.
Y aquí aparece el síntoma más general de todos. Seguimos midiendo el éxito por cumplir plazos, no por impacto.
Si te evalúan por “lo que sale”, por “lo que se entrega”, por “cumplir el plan”… es muy difícil que el equipo pueda trabajar para lograr resultados. Aunque tengas OKRs. Aunque hagas entrevistas puntuales. Aunque mires dashboards.
Señales claras de “producto tuneado”
Si te reconoces en varias de estas, probablemente estás en ese punto intermedio donde parece que haces producto… pero el sistema te empuja a seguir haciendo waterfall:
- El éxito se mide por entregas, no por el cambio que generan (uso, comportamiento, métricas, negocio).
- No se entienden las palancas del negocio, así que el roadmap se llena de “cosas razonables” sin una apuesta clara sobre qué métrica se quiere mover.
- El contacto con usuarios es esporádico: se entrevista “cuando hay tiempo”, y rara vez condiciona prioridades.
- Los datos existen, pero se usan para reportar, no para decidir (o llegan tarde, o no tienen consecuencias).
- El backlog tiene dueños fuera del equipo y producto actúa como coordinador, no como decisor.
- Se lanza y se pasa a lo siguiente: cada release es un punto final, no un punto de partida para aprender e iterar.
- Faltan objetivos claros o autonomía real: o no hay outcomes, o el equipo no puede decidir cómo alcanzarlos.
Nada de esto significa que “no estéis haciendo nada”. De hecho, muchas veces el “tuneo” mejora cosas. El problema es que no resuelve el problema de base: seguir construyendo sin una relación directa entre decisiones y resultados.
El ejemplo típico, OKRs con roadmap de funcionalidades
Este es un caso muy común de buenas prácticas absorbidas por waterfall.
Definimos OKRs con buena intención, pero el día a día sigue gobernado por un roadmap de funcionalidades con fechas. Por fuera la conversación parece más madura. Por dentro, el sistema opera igual.
Y ahí es donde aparece una desconexión silenciosa. Al principio del trimestre, los OKRs pueden tener presencia. Se presentan, se comparten, incluso generan una buena conversación. Pero, a medida que el trabajo avanza, el centro de gravedad vuelve a lo de siempre.
Porque el día a día no se organiza alrededor del resultado que quieres conseguir, sino alrededor del roadmap de funcionalidades. Y cuando tu unidad de planificación son features, el foco cambia sin que nadie lo decida explícitamente. Dejas de preguntarte qué palanca vas a mover o qué comportamiento necesitas cambiar, y pasas a gestionar alcance, dependencias y fechas.
En ese contexto, los OKRs no desaparecen por falta de voluntad. Simplemente dejan de tener consecuencias. Se quedan ahí, presentes como marco… pero lejos de las decisiones reales que determinan qué entra, qué sale y qué se prioriza.
Por eso tantas veces los OKRs terminan quedándose en una slide.
Lo que falta no es “más OKRs”, sino el puente que los hace operativos, un roadmap de resultados. Un roadmap que no ordena el futuro por entregables, sino por outcomes y aprendizaje. Que te obliga a planificar desde el cambio que necesitas lograr, no desde lo que vas a desarrollar.
Qué cambiar para salir del “producto tuneado” (sin una revolución)
No necesitas una revolución. Pero sí puedes empezar por cambios pequeños que ayudan a cambiar el sistema.
- Empieza por el resultado, no por la solución.
Antes de hablar de funcionalidades, deja claro qué cambio quieres provocar y qué métrica lo representa. Si no puedes responder a eso, lo demás es actividad organizada.
- Usa visión y estrategia como filtro.
La visión te da dirección. La estrategia te ayuda a decidir. Si no existe ese marco, todo parece prioritario y el roadmap acaba siendo una negociación de funcionalidades, no un plan para ganar en tu mercado.
- Convierte cada entrega en aprendizaje.
No lances para “cerrar”. Lanza para aprender. Una hipótesis simple, una medición mínima y una decisión posterior (seguir, ajustar o parar). Si no hay aprendizaje, el waterfall seguirá camuflado aunque cambie el vocabulario.
Sabrás que estás saliendo del “waterfall tuneado” cuando, poco a poco, la conversación pase de “qué vamos a entregar” a “qué métrica queremos mover”.
El punto no es “hacer más producto”. Es que funcione.
No se trata de sumar prácticas. Se trata de dejar de pedir certezas y empezar a liderar apuestas con aprendizaje.
Que “hacer producto” vuelva a significar lo mismo: construir cosas que importan y que generan impacto.
Si el modelo de fondo no cambia, el waterfall se lo traga todo.
Si quieres profundizar en esta transición, en Haz Producto lo desarrollo paso a paso.