Si empezamos por una idea, la defendemos. Si empezamos por un problema, aprendemos.
Esa frase parece sencilla, casi evidente. Pero cuando la miras de cerca, explica una parte enorme de por qué tantos equipos se quedan atrapados en la velocidad aparente y les cuesta alcanzar la velocidad real. No habla de metodología, habla de cómo pensamos, y de cómo el contexto de una empresa puede amplificar sesgos hasta convertirlos en una forma de trabajar. En este artículo voy a desgranar esa idea con calma.
Por qué empezar por la idea nos lleva a defender
Empezar por la idea tiene algo seductor. Reduce incertidumbre, ofrece un camino rápido y da sensación de acción. En muchos entornos, además, encaja con lo que se espera de ti. Se premia “traer soluciones”, se valora tener respuesta, y se interpreta el “todavía no lo sé” como falta de control. Así que, aunque la intención del equipo sea buena, el punto de partida se desplaza sin que nadie lo decida explícitamente. Se empieza por una propuesta y, sin darse cuenta, la conversación ya no va de entender, va de justificar.
Aquí se juntan dos fuerzas. Una es cognitiva y la otra es cultural. Por un lado, nuestra mente intenta cerrar cuanto antes la incertidumbre. Por otro, el entorno empuja para que esa necesidad de cierre se convierta en rutina. Esa combinación hace que empezar por una idea sea tan frecuente, incluso en equipos que ya trabajan con objetivos y hablan de resultados.
Los sesgos que empujan hacia la solución y hacia la defensa
Hay varios mecanismos psicológicos que aparecen con frecuencia en estas situaciones. Uno es la necesidad de cierre. La ambigüedad incomoda, y un problema abierto genera tensión. Una solución, aunque sea provisional, reduce esa tensión y devuelve sensación de control. Otro es la fusión entre idea e identidad. Una iniciativa rara vez se vive como algo neutral. Se vive como “mi idea”, y cuestionarla se siente como cuestionar a la persona, aunque nadie lo pretenda. También aparece el sesgo de confirmación, que empuja a buscar pruebas que validen la solución que ya se ha dicho en voz alta, incluso cuando el equipo cree que está “analizando”. Y por último está la ilusión de productividad. Idear iniciativas se percibe como avanzar. Entender el problema, en cambio, parece lento, y lo lento se interpreta como pérdida de tiempo.
Si lo tuviéramos que resumir, solemos caer en la solución rápida cuando:
- La incertidumbre pesa más que la curiosidad.
- La reputación pesa más que el aprendizaje.
- La acción visible pesa más que la comprensión.
- El entorno castiga la duda y premia la seguridad.
Todo esto es humano. Es normal. El problema aparece cuando confundimos esa sensación de movimiento con el impacto real que buscamos.
No es solo la mente. También es la presión del contexto
Es tentador explicarlo todo como un sesgo individual, como si la solución fuera “cambia tu mentalidad”. Pero muchas veces el problema está también en el sistema. Cuando una organización exige velocidad y mide sobre todo entregables, es lógico que el equipo busque lo que más rápido produce señales visibles de avance.
En la práctica, esta presión suele aparecer con señales muy reconocibles:
- Se pide un plan antes de haber entendido el problema.
- Se premia la respuesta rápida más que la pregunta incómoda.
- Se penaliza el “todavía no lo sé”, aunque sea honesto.
- Se mide el progreso por entregas, no por aprendizaje o impacto.
En esos entornos, la idea deja de ser solo una posibilidad. Se convierte en un compromiso. Y cuanto más compromiso hay, más cuesta abrir de nuevo la conversación para aprender.
Velocidad aparente y velocidad real
En producto, moverse no es lo mismo que avanzar. La velocidad aparente es la que se ve desde fuera. Hay backlog, hay sprints, hay entregas, hay un roadmap que se actualiza. La velocidad real, en cambio, es la que mide si estás consiguiendo el impacto que buscas. Es la capacidad de acercarte a una solución que mejora de verdad la experiencia del usuario y mueve una métrica relevante del negocio.
Dicho de forma simple, la velocidad aparente responde a “¿cuánto estamos haciendo?” y la velocidad real responde a “¿cuánto estamos consiguiendo?”.
una forma visual de entender eSTA SITUACIÓN
Imagina una diana. En el centro está la solución que realmente necesita el usuario, la que cuando la encuentras genera impacto de verdad. Ahora imagina que ante un objetivo el equipo lanza un dardo. Si el dardo cae cerca del centro, iterar funciona. Cada versión te permite acercarte un poco más, porque el punto de partida era razonable. La iteración refina, y el esfuerzo acumulado se traduce en progreso real.
Pero si el dardo cae lejos, la historia cambia. No porque iterar sea malo, sino porque los recursos son finitos. No vas a iterar eternamente. Vas a poder iterar unas cuantas veces antes de que el equipo se quede sin tiempo o sin margen político. Y si empiezas muy lejos, aunque mejores la solución en cada iteración, es probable que sigas orbitando alrededor de un punto que no era el centro. Desde fuera se ve actividad. Desde dentro sientes que te acercas, sí, pero partes de demasiado lejos como para llegar a tiempo.
Esto suele verse en patrones típicos:
- Cambios pequeños sobre una dirección equivocada.
- Mejoras incrementales que no mueven la métrica clave.
- Iteraciones que “pulen” pero no transforman.
- Roadmaps llenos de ajustes que no resuelven el fondo.
Aquí la metáfora aterriza una idea importante. El problema no es iterar. El problema es empezar con mala puntería.
Entender bien el problema no garantiza acertar, pero mejora la puntería
Cuando un equipo no consigue resultados, es habitual pensar que “la solución era mala”. Y a veces lo es. Pero muchas otras veces el fallo es anterior. El fallo es que el equipo estaba trabajando con una comprensión superficial del problema. Había un enunciado, pero no había profundidad. Había un objetivo, pero no había claridad sobre lo que estaba ocurriendo realmente en la vida del usuario.
Entender bien el problema no te garantiza acertar a la primera. Pero aumenta enormemente la probabilidad de que la primera idea caiga cerca del centro. Eso es lo que transforma la velocidad aparente en velocidad real. Puede parecer más lento al principio, porque exige sostener preguntas abiertas, pero evita invertir tiempo valioso en una dirección equivocada.
El error silencioso, confundir el enunciado con la comprensión
Aquí aparece uno de los fallos más frecuentes. Definimos el problema en una frase y creemos que ya lo hemos entendido. “Tenemos baja activación”, “los usuarios no usan esta funcionalidad”, “hay mucho churn”. Son frases útiles para nombrar un síntoma, pero no son comprensión. Son el titular.
La comprensión empieza cuando miras debajo del titular y te acercas a la realidad del usuario. No solo quién es o con qué frecuencia ocurre, sino en qué contexto, qué intenta hacer, qué esperaba, qué le frustra, qué alternativa utiliza, qué le obliga a abandonar, qué tensión aparece entre lo que el negocio quiere y lo que el usuario necesita en ese momento.
Si quieres verlo como una checklist mental, una frase rara vez responde a:
- Qué está viviendo el usuario cuando ocurre el síntoma.
- Qué intenta conseguir y por qué le importa.
- Qué obstáculos encuentra, y cuáles son percibidos como “coste”.
- Qué señales le faltan para seguir avanzando.
- Qué factores del contexto influyen (tiempo, dispositivo, urgencia, entorno, expectativas).
- Qué trade-offs hay entre experiencia de usuario y objetivos de negocio.
Mientras no entiendas esa realidad, el equipo está tomando decisiones sobre una simplificación. Y cuanto más simplificado está el problema, más probable es que la idea caiga lejos.
Si empezamos por el problema, aprendemos
Aprender no significa eternizar el análisis. Significa elevar la comprensión antes de fijar una dirección. Y la herramienta más simple y más poderosa para lograrlo son las preguntas. No las preguntas como checklist, sino como entrenamiento mental.
Las preguntas tienen dos funciones clave. La primera es que te obligan a anclarte en el problema antes de saltar a la solución. La segunda es que te revelan lo que no sabes, y reconocer lo que no sabes es lo que permite investigar, contrastar y apuntar mejor.
En Haz Producto propongo un conjunto de preguntas como punto de partida. No porque sean únicas, sino porque ayudan a romper el patrón automático de saltar a la solución. Y lo importante es este matiz. El verdadero valor no está en la lista, está en el ejercicio de practicar, adaptar, refinar, y aprender cuáles son las preguntas que, en tu contexto, separan un enunciado de una comprensión real.
De hecho, con equipos que ya son maduros, lo más habitual es que ocurra lo contrario de lo que muchos esperan. No usan mis preguntas “tal cual”. Las usan como trampolín. Empiezan con una guía y terminan desarrollando un set propio, más preciso, más conectado con su producto, su mercado y sus tipos de usuarios.
Lo que cambia cuando haces esto
Cuando empiezas por una idea, el equipo se organiza alrededor de una solución. Cuando empiezas por el problema, el equipo se organiza alrededor de una comprensión compartida. Y esa comprensión cambia la conversación con stakeholders, cambia la forma de priorizar y cambia el tipo de decisiones que se pueden sostener con confianza. Ya no estás defendiendo “mi idea”. Estás defendiendo una realidad mejor entendida.
En un mundo de recursos finitos, esa diferencia es enorme. Porque no siempre tendrás tiempo para iterar hasta dar con el centro. Pero sí puedes aumentar la probabilidad de empezar cerca. Y eso es lo que, a la larga, separa a un equipo que construye mucho de un equipo que genera impacto real.