Por qué todos saltamos a las soluciones
Los stakeholders suelen llegar con peticiones perfectamente definidas: «necesitamos notificaciones push«, «hay que mejorar el dashboard«, «queremos un sistema de filtros avanzados». Como Product Manager, te puedes sentir tentado a desarrollarlas directamente.
Es fácil caer víctima del sesgo de solución. Nuestro cerebro prefiere pensar en soluciones porque son tangibles y dan sensación de progreso inmediato. A esto se suma el sesgo de acción: preferimos lanzar rápido (aunque sea subóptimo) que investigar.
Nos sentimos productivos porque lanzamos novedades, pero el producto no mejora realmente. ¿Cómo salimos de este bucle?
«Enamórate del problema, no de la solución.» – Uri Levine, co-fundador de Waze
Escapando la trampa de construir
Esto es lo que Melissa Perri llama «The Build Trap» (la trampa de construir): organizaciones atrapadas en un ciclo infinito de producción de funcionalidades nuevas, midiendo outputs (cuánto construyen) en lugar de outcomes (qué impacto logran).
Veámoslo con el ejemplo de los botones de redes sociales. Si tienes mentalidad de tareas, ejecutas lo que te piden. Reúnes al equipo, definís el alcance y desarrolláis la feature. Botones de Facebook, Twitter, LinkedIn, Instagram… Misión cumplida.
Con mentalidad de producto, empiezas preguntándote: «¿Por qué los usuarios quieren compartir? ¿Cómo lo están haciendo ahora?» Y pasas a hacer discovery (investigar con usuarios reales). Descubres algo revelador: muy pocos usuarios publican en redes sociales desde la app (menos del 5%). Pero muchos hacen captura de pantalla y la envían por WhatsApp, o copian la URL manualmente.
El problema real no es «faltan botones para publicar en redes sociales». El problema es que los usuarios necesitan enviar información rápido a contactos específicos, no publicar en su timeline. La solución cambia por completo: implementas un simple botón de «Compartir» que abre el menú nativo del sistema (WhatsApp, Telegram, copiar enlace…). Resuelve la necesidad real con menos complejidad técnica, sin necesidad de mantener integraciones con múltiples plataformas.
Eso es tener mentalidad de producto.
¿Qué pasa cuando las empresas no piensan así? Analicemos dos casos reales.
Instagram vs Snapchat: dos formas de pensar en producto
La historia del rediseño de Snapchat de 2017 es la demostración perfecta de cómo NO hacer producto. Su propuesta parecía sólida: separar las Stories de usuarios de las de famosos y marcas, mezclar Stories con chats, y añadir ordenamiento algorítmico para dar más visibilidad al contenido patrocinado. Todo perfectamente justificado desde la lógica del negocio.
¿El problema? Nadie validó si esto resolvía algún problema real de los usuarios. El resultado fue catastrófico. Más de 1.2 millones de usuarios firmaron una petición para volver al diseño anterior. Snapchat perdió $1.3 mil millones en valor bursátil. Intentando ser más atractivos para los anunciantes, construyeron algo que sus usuarios no querían.
Esta historia contrasta con el caso de éxito de Instagram Stories, lanzado apenas un año antes. Instagram inicialmente se resistió a copiar el formato de Snapchat. Su CEO llegó a declarar públicamente que «nunca tendrían Stories» porque no encajaba con su visión de feeds de imágenes curadas.
Pero el equipo se planteó una pregunta clave: ¿qué problema tienen nuestros usuarios que Snapchat está resolviendo? Descubrieron que las personas querían compartir contenido que no era lo suficientemente «perfecto» para el feed permanente. Necesitaban un espacio para ese contenido efímero, espontáneo, sin presión.
Según Marty Cagan, al menos la mitad de las ideas en cualquier roadmap no funcionarán, pero la mayoría de equipos las construyen sin validar primero. Snapchat construyó sin validar. Instagram validó antes de construir.
Las 3 preguntas que necesitas recordar
El trabajo del Product Manager no es entregar funcionalidades (outputs), sino generar impacto real (outcomes). Suena obvio, pero la mayoría de los PMs pasan sus primeros años midiendo cuánto construyen en lugar de qué logran.
Cambiar tu mentalidad solo requiere hacer las preguntas correctas antes de comprometerte con cualquier solución.
Imagina este brief: «Necesitamos implementar un chatbot con IA en la web». Con mentalidad de tareas, empiezas a evaluar proveedores, comparas ChatGPT con Claude, diseñas la interfaz del chat.
Con mentalidad de producto, haces tres preguntas:
- ¿Qué outcome buscamos? «Implementar un chatbot con IA» no es un outcome, es una solución ya definida. Profundizas y descubres el objetivo real: reducir el volumen de tickets de soporte en un 40% porque el equipo está colapsado.
- ¿Qué comportamiento del usuario necesita cambiar? Analizas los tickets y descubres que el 70% son sobre las mismas 5 preguntas básicas (resetear contraseña, cambiar método de pago, facturas, cancelación…). El comportamiento que necesitas cambiar: que los usuarios encuentren estas respuestas por sí mismos.
- ¿Qué hipótesis podemos validar antes de construir? Antes de invertir en IA, piensa qué puedes probar rápido y barato. Hipótesis: «Los usuarios escriben tickets porque no encuentran la información que buscan». Validación rápida: añadir una sección de preguntas frecuentes (FAQ) visible en la página de contacto con esos 5 temas.
Resultado: descubres que el 65% del problema se resuelve con un FAQ bien ubicado y un buscador mejorado. No necesitabas IA. Acabas de ahorrar meses de implementación, costes de API, y has logrado resolver el problema con una solución mucho más simple y mantenible.
Las preguntas correctas te llevan al problema real antes de perder tiempo y dinero. Y a veces, esa solución equivocada es la IA que todo el mundo está implementando solo porque está de moda.
Product mindset: tu nueva forma de trabajar
Cuando alguien te pida «añade esta funcionalidad al roadmap», tu respuesta automática debe ser: «Cuéntame qué problema estamos resolviendo». Es incómodo al principio, pero es lo que se espera de un buen Product Manager.
«Mata las malas ideas antes de que consuman demasiado tiempo y energía del equipo y antes de que te enganches a ellas. En su lugar, enamórate del problema que estás resolviendo.» — Melissa Perri, Escaping the Build Trap
¿Cómo sabes en qué modo estás trabajando?
Estás en modo tareas cuando:
- Ejecutas lo que te piden sin cuestionar
- Mides tu éxito por número de funcionalidades
- Nunca propones NO hacer algo
- Hablas más con stakeholders que con usuarios
Estás en modo producto cuando:
- Tu respuesta automática a cualquier petición es ‘cuéntame el problema’
- A veces concluyes que la mejor solución es no construir nada
- Mides el impacto real en la experiencia de los usuarios
- Propones soluciones completamente diferentes a lo que te han pedido
Ante tu próximo reto, haz una pausa. Antes de diseñar o desarrollar nada, pregunta: «¿Qué problema tienen los usuarios?». De verdad. Espera la respuesta. Si te dicen «la competencia lo tiene», sigue preguntando hasta llegar al problema real.
No te pagan por construir funcionalidades. Te pagan por resolver los problemas correctos. Y aquí está la parte que más cuesta aceptar: a veces, la mejor solución es no construir nada nuevo.
