Mentalidad de producto: propósito, usuario y valor.

Si tuviera 30 segundos para saber si una iniciativa va bien encaminada, haría esta pregunta:

¿Qué cambia, para quién cambia y cómo sabremos que ha cambiado?

Cuando eso no está claro, suele pasar que hemos arrancado con energía, el backlog crece, entregamos cosas… y a las pocas semanas alguien pregunta: “vale, ¿y esto para qué era?” Y no suele ser un problema de esfuerzo, sino un problema de enfoque.

Para mí, la mentalidad de producto no va de roles, ceremonias o herramientas. Se trata de poner el foco en tres cosas antes de lanzarnos a construir: qué problema queremos resolver, para quién y qué valor esperamos generar.

El error más habitual es arrancar por el “qué”. Las primeras conversaciones giran alrededor de lo que hay que construir, los entregables que se esperan, para cuándo, quién lo hace y dónde lo seguimos. Son preguntas válidas. El problema es que, si arrancamos así, corremos el riesgo de organizarnos en torno a la ejecución de algo que quizá no era lo más importante.

Por eso, antes de bajar a la operativa, conviene aterrizar el propósito, el usuario y el valor con estas preguntas:

• ¿Por qué hacemos esto? ¿Qué problema estamos intentando resolver?
• ¿Quién es el usuario real?
• ¿Qué mejora esperamos ver y cómo la vamos a notar?

Si esto no está claro, bajar al backlog demasiado pronto no nos va a ayudar. Esto sucede con frecuencia con iniciativas que ya llegan formuladas de esta forma:

• “Necesitamos un dashboard.”
• “Hay que automatizar este proceso.”
• “Queremos una nueva pantalla.”

Ahí el riesgo es aceptar la solución sin haber entendido bien la necesidad. Pasa, por ejemplo, con peticiones como esta: “automatizar la aprobación de solicitudes”. Hasta ahí, lo que tenemos es una solución. La conversación útil empieza cuando preguntas: “vale, ¿para qué?”. Y entonces aparece el problema real: reducir tiempos de respuesta y evitar errores. A partir de ahí ya puedes concretar mejor:

• Usuario: el equipo operativo que gestiona las solicitudes y el cliente final que sufre las esperas.
• Valor esperado: pasar de 5 días a 24 horas y reducir retrabajo.
• Decisión: quizá antes de automatizar es recomendable eliminar validaciones redundantes, aclarar criterios y definir excepciones.

La necesidad de fondo no ha cambiado. Lo que cambia es la calidad de la decisión.

Producto es el compendio de propósito, usuario y valor

Cuando hablamos de producto, para mí hay tres elementos que no pueden faltar: propósito, usuario y valor. Si falta uno de estos tres, es fácil caer en una dinámica peligrosa donde trabajamos mucho pero con un impacto difuso.

• Sin usuario, el valor se vuelve abstracto: no sabemos para quién estamos mejorando algo ni qué cambio queremos provocar. Y esto aplica también cuando el usuario es interno. Que el usuario esté en Operaciones, Tecnología, Riesgos o Finanzas no cambia nada de fondo: también ahí hay que concretar quién es, qué fricción tiene y qué mejora sería realmente valiosa para esa persona.
• Sin valor, el usuario se queda en una descripción vacía. En este post no vamos a entrar en detalle en qué se entiende por valor, pero sí quiero aclarar que cuando hablo de valor, no me refiero solo a negocio. Puede aparecer en varias capas, ya sea:
  • Valor para el usuario: menos fricción, más claridad, menos esperas, menos errores.
  • Valor para el negocio: más adopción, menos coste, menos riesgo, mejor conversión.
  • Valor para el sistema de entrega: más calidad, más estabilidad, menos retrabajo, menos urgencias artificiales.
• Sin propósito, todo suena razonable, pero cuesta priorizar. Aquí hay una distinción que me parece útil y que conecta con el Círculo Dorado de Simon Sinek: no es lo mismo hablar del porqué que del para qué. El porqué habla del propósito de la iniciativa. El para qué aterriza ese propósito en impacto, en el cambio que queremos provocar.

Lo importante es que algo cambie de forma observable. Si no cambia nada visible, probablemente no estamos generando valor; únicamente estamos haciendo cosas.

Una buena pregunta para aterrizarlo es: ¿Qué mejora real se producirá para el usuario si esto funciona?

Cómo aterrizar esto en el día a día

1. Arrancar por problema y valor, no por entregable.

Antes de hablar de solución, deja claro qué dolor quieres resolver, para quién y qué mejora esperas ver. Herramientas como una Inception bien enfocada ayudan justo a eso: alinear propósito, usuario, valor y cómo sabremos si vamos bien.

Para ese arranque ayuda de forma sustancial dejar por escrito algo tan simple como:

• Nuestro objetivo: estamos aquí para...
• El problema actual: hoy en día pasa que...
• A quién afecta: esto afecta sobre todo a...
• Lo que esperamos: si todo va bien, debería cambiar...
• Cómo lo sabremos: lo notaremos porque veremos...

No lo veas como burocracia. Tómalo como una manera de alinear mejor y de evitar que el backlog se convierta en lista de tareas.

2. Conectar estrategia, foco y backlog.

Si una iniciativa no está conectada con una prioridad real, el backlog acaba lleno de trabajo, pero no necesariamente de valor. Por eso conviene enlazar bien estrategia, priorización y roadmap.

3. Traducir intención en seguimiento real.

Si dices que buscas impacto, luego tienes que revisarlo. Y ahí ayuda formular bien los objetivos y acompañarlos de resultados observables, sin confundir actividad con impacto. Para eso, puedes complementar bien con el uso de OKRs, prestando atención a sus anti-patrones.

En conclusión

Trabajar con mentalidad de producto va de tomar mejores decisiones desde el principio. La próxima vez que arranques una iniciativa, yo me pararía un minuto en estas tres preguntas:

• ¿Qué valor concreto queremos generar?
• ¿Para quién, exactamente?
• ¿Y cómo sabremos que lo estamos consiguiendo?

Porque el valor no aparece al final. Se decide desde el inicio y se revisa durante el camino.

Tu backlog no debería demostrar que trabajas. Debería demostrar que estás cambiando algo valioso para alguien. ¡Te leo en comentarios! 👇