Mentalidad de producto: por qué no basta si la organización sigue funcionando por proyectos

Muchas organizaciones llevan años intentando incorporar una mayor mentalidad de producto a su forma de trabajar. Forman a sus equipos, introducen discovery, empiezan a hablar de outcomes en lugar de outputs y buscan que negocio, producto y tecnología trabajen de forma más cercana.

Sin embargo, hay un momento en el que muchas de estas transformaciones empiezan a atascarse. El equipo aprende una nueva forma de trabajar, pero cuando vuelve al día a día se encuentra con un sistema que sigue pidiendo lo mismo de siempre: un alcance cerrado para conseguir presupuesto, fechas comprometidas con meses de antelación, decisiones que deben escalar y un reporting donde el éxito sigue estando muy ligado a cumplir el plan.

Ahí aparece una contradicción importante. Podemos enseñar a un equipo a pensar como producto y, al mismo tiempo, obligarlo a trabajar como un proyecto.

La mentalidad de producto no depende únicamente de las prácticas que adopta un equipo. También depende del sistema organizativo en el que ese equipo tiene que tomar decisiones. Si financiación, métricas, derechos de decisión y gobernanza siguen respondiendo a una lógica distinta, tarde o temprano acabarán condicionando el comportamiento.

Qué significa realmente trabajar con mentalidad de producto

Trabajar con mentalidad de producto no consiste en sustituir la palabra “proyecto” por “producto” en el organigrama ni en incorporar unas cuantas ceremonias nuevas. Tampoco significa renunciar a la planificación, los presupuestos o los compromisos.

El cambio está en cómo entendemos el trabajo. Un equipo orientado a producto parte de un problema, intenta comprenderlo, decide dónde puede generar valor, construye una solución, observa lo que ocurre y utiliza lo aprendido para decidir el siguiente paso.

Eso implica aceptar cierta incertidumbre. Podemos conocer el problema que queremos resolver y tener una dirección clara, pero no siempre podemos saber desde el primer día cuál será exactamente la mejor solución dentro de seis meses.

Por eso, si queremos que los equipos trabajen de esta manera, no basta con darles nuevas herramientas. También necesitamos crear un entorno que les permita aprender y tomar decisiones a medida que aparece nueva información.

La financiación condiciona más de lo que parece

Imaginemos que pedimos a un equipo que haga discovery, valide hipótesis y adapte la solución según lo que vaya aprendiendo. Al mismo tiempo, para conseguir financiación le exigimos comprometer un listado detallado de funcionalidades para los próximos doce meses.

Las dos cosas entran fácilmente en conflicto.

El equipo puede hablar de outcomes, pero su compromiso real sigue estando ligado a aquello que prometió entregar para conseguir presupuesto. Si descubre a mitad de camino que una parte importante del roadmap no tiene sentido, cambiarlo puede convertirse en un problema aunque esa sea precisamente la decisión correcta desde una perspectiva de producto.

Esto no significa que los productos deban disponer de presupuesto ilimitado. Significa que podemos replantearnos qué estamos financiando. En algunos casos tiene más sentido invertir en una capacidad, un producto o un problema relevante y revisar periódicamente si sigue justificándose esa inversión, en lugar de intentar definir toda la solución de antemano.

La conversación cambia entonces de “¿cuánto cuesta entregar este alcance?” a “¿cuánto estamos dispuestos a invertir en resolver este problema y qué necesitamos aprender para decidir si seguimos haciéndolo?”.

El matiz parece pequeño, pero cambia bastante la forma en la que un equipo puede actuar.

Pedir autonomía no sirve si no puede decidir

Otra palabra habitual en las transformaciones de producto es autonomía. Queremos equipos autónomos, responsables y capaces de tomar decisiones.

Pero la autonomía solo existe de verdad cuando sabemos qué puede decidir el equipo sin tener que pedir permiso constantemente.

¿Puede modificar una funcionalidad después de hablar con usuarios? ¿Puede cambiar prioridades? ¿Puede decidir no construir algo que estaba previsto? ¿Puede detener una iniciativa si la evidencia indica que no está funcionando?

Si la mayoría de esas decisiones tiene que escalar varios niveles, probablemente no estamos hablando de autonomía, sino de ejecución delegada.

Eso tampoco significa que un equipo de producto deba decidirlo todo. Hay decisiones estratégicas, regulatorias, financieras o arquitectónicas que legítimamente pertenecen a otros niveles de la organización. Lo importante es hacer explícitas esas fronteras.

Porque hay una diferencia importante entre pedir ownership y conceder derechos de decisión. Cuando exigimos al equipo que responda por un resultado pero no le damos capacidad para modificar muchas de las variables que afectan a ese resultado, generamos una contradicción difícil de sostener.

Las métricas enseñan qué importa de verdad

Las organizaciones pueden hablar mucho de cultura, pero una de las formas más claras de entender qué valoran realmente es observar qué preguntan y qué miden.

Podemos decir que queremos equipos centrados en impacto y, al mismo tiempo, dedicar la mayor parte del seguimiento a comprobar cuántas funcionalidades se han entregado, qué porcentaje del roadmap está completado o si llegaremos a la fecha prevista.

Ninguna de esas métricas es necesariamente mala. El problema aparece cuando son las únicas que utilizamos para definir el éxito.

Si el equipo sabe que será evaluado principalmente por cumplir el plan, aprenderá a optimizar el cumplimiento del plan. Es bastante lógico.

Una organización más orientada a producto necesita ampliar esas conversaciones. Además de preguntar qué hemos entregado, conviene preguntarnos qué comportamiento queríamos cambiar, qué problema queríamos reducir, qué señales estamos observando y qué hemos aprendido desde que empezamos.

No siempre tendremos una atribución perfecta. Algunos outcomes tardan en aparecer, dependen de varias causas o simplemente no permiten un experimento limpio. Trabajar con producto tampoco consiste en convertir cada decisión en un A/B test.

La cuestión es no confundir la dificultad de medir impacto con una razón para dejar de intentarlo. Podemos combinar datos, feedback cualitativo, señales operativas y criterio para entender si estamos avanzando en la dirección adecuada.

La gobernanza también forma parte del modelo

Hay otra capa que suele quedar algo más lejos del equipo, pero que condiciona muchísimo cómo trabaja: la gobernanza.

Un equipo puede tener buenas prácticas de producto, cierto margen de decisión y métricas razonables. Pero si cada pocos meses tiene que defender un listado cerrado de entregables ante distintos comités, es muy fácil que vuelva a aparecer una lógica de proyecto.

Gobernar no significa controlar cada decisión. De hecho, cuando concedemos más autonomía a los equipos, necesitamos aún más transparencia sobre lo que están haciendo, lo que están aprendiendo y dónde están invirtiendo.

La diferencia está en el tipo de conversación.

En lugar de preguntar únicamente si el proyecto sigue en verde, podemos preguntar qué problema estamos intentando resolver, qué resultados estamos observando, qué hemos aprendido desde la última revisión, qué riesgos han aparecido o si sigue teniendo sentido mantener la inversión.

La gobernanza no desaparece en una organización orientada a producto. Cambia el objeto sobre el que gobierna.

Cuando cambian las prácticas, pero no cambia el sistema

Por eso algunas transformaciones producen situaciones un poco extrañas. Equipos que hacen discovery cuando las decisiones principales ya están tomadas. OKRs que conviven con roadmaps prácticamente contractuales. Product Managers que terminan dedicando gran parte de su tiempo a coordinar entregas. Equipos supuestamente estables que se crean y desaparecen alrededor de iniciativas temporales.

No significa que incorporar nuevas prácticas no sirva. Sirve y puede ser un primer paso importante.

El problema aparece cuando esperamos que esas prácticas cambien por sí solas la forma de operar de toda una organización.

Un equipo tiene capacidad limitada para comportarse de forma diferente si el sistema que lo rodea sigue premiando exactamente el comportamiento anterior. Y, a largo plazo, el sistema suele ganar.

Pasar de proyectos a producto no significa eliminar los proyectos

También conviene evitar convertir esta conversación en una batalla entre proyectos y productos.

No todo necesita convertirse en un producto permanente. Hay iniciativas que tienen un resultado bien definido, un inicio y un final claros y poca incertidumbre sobre la solución. Una migración concreta, una implantación regulatoria o determinados trabajos de infraestructura pueden funcionar perfectamente con una lógica de proyecto.

La pregunta interesante no es si los proyectos son malos y los productos buenos. Es qué modelo encaja mejor con la naturaleza del problema.

Cuando existe incertidumbre, aprendizaje continuo, comportamiento de usuarios y necesidad de evolución, una lógica de producto suele tener mucho sentido. Cuando el resultado está claramente definido y el reto está principalmente en ejecutar, un proyecto puede ser totalmente adecuado.

Lo importante es no utilizar el mismo modelo operativo para cualquier tipo de trabajo por defecto.

Tres conversaciones que merece la pena tener

Si una organización está intentando trabajar de forma más orientada a producto, hay tres preguntas que pueden revelar rápidamente hasta dónde está llegando realmente el cambio.

La primera es cómo financiamos. ¿Estamos financiando principalmente un listado cerrado de entregables o estamos invirtiendo en resolver problemas y revisando periódicamente si sigue teniendo sentido hacerlo?

La segunda es quién puede decidir. ¿El equipo tiene capacidad real para adaptar la solución según lo que aprende o su función consiste principalmente en ejecutar decisiones tomadas fuera?

Y la tercera es qué consideramos éxito. ¿Seguimos midiendo fundamentalmente actividad y cumplimiento o estamos incorporando señales sobre lo que cambia para usuarios y negocio?

Si estas conversaciones todavía no han aparecido, probablemente la transformación se está produciendo sobre todo dentro de los equipos. Eso puede ser un buen comienzo, pero difícilmente será suficiente.

Cambiar la forma de trabajar implica cambiar lo que hay alrededor

Adoptar mentalidad de producto requiere desarrollar capacidades en discovery, estrategia, priorización, datos, experimentación o colaboración entre negocio y tecnología. Todo eso sigue siendo importante.

Pero no podemos pedir a los equipos que trabajen de una manera mientras el resto de la organización continúa incentivando otra.

A veces, el siguiente paso de una transformación no consiste en introducir otro framework ni en añadir una nueva práctica. Consiste en mirar alrededor del equipo y hacerse una pregunta bastante menos vistosa:

¿Qué hay en nuestro sistema que sigue haciendo más fácil trabajar como proyecto que trabajar como producto?

Es ahí donde suelen aparecer las conversaciones más interesantes. Y también donde una transformación empieza a dejar de ser un cambio de prácticas para convertirse en un cambio real del modelo operativo.

En Kelea trabajamos precisamente en ese punto: no solo en ayudar a los equipos a incorporar nuevas formas de trabajar, sino en entender qué tiene que cambiar alrededor para que puedan sostenerse en el tiempo.

Preguntas frecuentes

¿Qué es la mentalidad de producto?
La mentalidad de producto es una forma de trabajar centrada en comprender un problema, generar valor para usuarios y negocio, observar los resultados y adaptar las decisiones a partir de lo aprendido. No consiste únicamente en entregar funcionalidades ni en adoptar una metodología concreta.

¿Cuál es la diferencia entre trabajar por proyectos y trabajar por productos?
Un proyecto suele organizarse alrededor de un alcance, un presupuesto y un plazo definidos. Un producto evoluciona mientras continúe resolviendo un problema relevante. Ningún enfoque es siempre mejor: la elección depende de la naturaleza del trabajo y del nivel de incertidumbre.

¿Por qué una transformación de producto puede frenarse aunque los equipos estén formados?
Porque las prácticas del equipo pueden entrar en conflicto con el sistema organizativo. Si la financiación, las decisiones, las métricas y la gobernanza siguen funcionando con lógica de proyecto, los equipos tenderán a adaptarse a esos incentivos.

¿Qué necesita cambiar para implantar una mentalidad de producto?
Además de desarrollar capacidades en los equipos, conviene revisar cómo se financia el trabajo, qué decisiones pueden tomar los equipos, cómo se mide el éxito y cómo se gobierna la inversión y el aprendizaje.

¿Hay que eliminar los proyectos para trabajar con mentalidad de producto?
No. Algunas iniciativas funcionan perfectamente como proyectos. La clave está en elegir conscientemente el modelo adecuado en lugar de aplicar una lógica de proyecto a cualquier tipo de problema.