👋 Hola!, Soy Zaira Zatarain y aquí te comparto lo que sé sobre Producto, tecnología e IA.
Si trabajas en Producto, seguro te han llegado con la solución ya diseñada: “Necesito un botón que haga esto”, “Agrégale un filtro aquí”, “Sácame un reporte en Excel”.
Y la tentación es enorme: está clarísimo, es rápido, el stakeholder se va feliz. ¿Qué podría salir mal?
Pues que unas semanas después nadie usa el botón, el reporte se queda en una carpeta y el problema sigue ahí. ¿Por qué pasa esto?
1. El caso: “Solo necesito un reporte”
Imagina esto: el equipo de operaciones te pide un reporte diario en Excel con todos los pagos del día. Fácil, ¿no? Una consulta, un archivo, listo.
Pero antes de mandarlo a desarrollo, haces una pregunta sencilla: “¿Qué vas a hacer con ese reporte?”.
La respuesta: “Lo reviso todas las mañanas para encontrar los pagos que fallaron y avisarle a los clientes antes de que se quejen”.
Ah. Entonces el problema no es “no tengo un reporte”. El problema es “me entero tarde de los pagos fallidos y los clientes se enojan”.
2. El problema real: la petición es una solución disfrazada
Aquí está la clave: una petición es la solución que alguien ya se imaginó. Una necesidad es el problema que quiere resolver.
Las personas no piden problemas, piden soluciones, porque es lo natural. Nadie llega diciendo “tengo un problema de detección temprana de fallos”. Llegan diciendo “dame un Excel”.
Y no es que la petición esté mal. Es que está limitada por lo que esa persona conoce. Si lo único que ha visto es Excel, va a pedir Excel.
3. Cómo razona un PM
Cuando llega una petición, un PM con criterio no dice “sí” ni “no” de inmediato. Primero escarba:
¿Qué vas a hacer con esto? La pregunta más poderosa de todas.
¿Qué pasa hoy si no lo tienes? Te dice qué tan grave es el dolor.
¿Cada cuánto pasa? Un problema diario no se resuelve igual que uno de cada trimestre.
¿Cómo sabremos que se resolvió? Si no hay forma de medirlo, quizá no es tan claro el problema.
En nuestro caso, con esas preguntas descubres que operaciones pasa una hora diaria revisando filas, que los fallos se detectan hasta el día siguiente y que muchos clientes ya se quejaron antes de que alguien los contacte.
4. La decisión (y el trade-off)
Con la necesidad clara, aparecen opciones que el Excel nunca hubiera permitido:
Una alerta automática cuando un pago falla, en el momento.
Un mensaje al cliente con los pasos para reintentar, sin que nadie tenga que buscarlo.
Un tablero con solo los pagos fallidos, no los miles que salieron bien.
¿Y el trade-off? La alerta toma más tiempo de construir que el reporte. Así que una salida razonable es entregar primero una versión sencilla (aunque sea el Excel, pero solo con los fallidos) y trabajar en la alerta como siguiente paso.
Fíjate: a veces sí terminas entregando algo parecido a lo que pidieron, pero ahora sabes por qué y hacia dónde va. Esa es la diferencia.
5. El aprendizaje para cualquier PM
Escucha la petición, pero trabaja la necesidad. La petición es el punto de partida, no la especificación.
Pregunta “¿para qué?” antes que “¿para cuándo?”. El “para cuándo” sin el “para qué” te convierte en tomador de pedidos.
No disminuyas la petición. Decir “eso que pides está mal” cierra la conversación. Decir “ayúdame a entender qué quieres lograr” la abre.
Valida que la necesidad sea real. A veces escarbas y descubres que el problema no es tan grande, y eso también es valioso: te ahorraste construir algo innecesario.
En mi opinión, la diferencia entre un PM que ejecuta y uno que piensa no está en lo que construye, sino en las preguntas que hace antes de construir.
🧠 Ejercicio para ti
Toma la última petición que te llegó (un botón, un reporte, un filtro, lo que sea) y hazle estas tres preguntas a quien la pidió:
¿Qué vas a hacer con esto?
¿Qué pasa hoy si no lo tienes?
¿Cómo sabremos que se resolvió?
Luego escribe la necesidad en una sola frase, sin mencionar la solución. Cuéntame en los comentarios si cambió lo que ibas a construir.
En resumen
Las peticiones son soluciones disfrazadas. Si construyes lo que te piden sin entender para qué, puedes entregar exactamente lo solicitado y aun así no resolver nada. El trabajo del PM es escarbar hasta la necesidad, explorar opciones y decidir con criterio.
No construyas lo que te piden. Construye lo que necesitan.
🚀 Ya abrió TPP Academy, el manual que nadie te dio para ser Product Manager. Ahí practicamos justo esto: hacer las preguntas correctas antes de construir, manejar stakeholders y decidir con datos.
Clases grabadas, a tu ritmo y sin relleno. Y si eliges el plan anual, tienes un precio especial por ser fundador solo durante noviembre 👇
https://www.skool.com/the-pro-producto-4548/about
Si conoces a alguien que siempre recibe peticiones de “solo un botón”, compártele este post. Y si todavía no te suscribes, ¿qué esperas? 😉