Hace casi dos semanas publiqué el último artículo. Desde entonces recibí varios mensajes preguntándome si había abandonado la serie.

La respuesta es no. Simplemente me pasó algo curioso. Mientras no estaba escribiendo… estaba construyendo. No artículos. Prototipos. Experimentos. Ideas que terminaron siendo completamente distintas de como las imaginé al principio.

Y creo que eso terminó enseñándome mucho más de lo que habría aprendido escribiendo otro artículo.

Durante las últimas semanas me descubrí haciendo algo que hace un año probablemente no habría hecho.

Antes de abrir un documento… abría una herramienta para prototipar.

Antes de escribir un PRD… intentaba convertir la idea en algo que pudiera tocar.

No porque estuviera lista. Todo lo contrario. Porque justamente quería descubrir por qué todavía no estaba lista.

Y ahí fue donde entendí algo que me lleva rondando la cabeza desde hace tiempo.

Durante un buen tiempo pensé para construir. Hoy, cada vez más, construyo para pensar. Parece un juego de palabras jeje. No lo es.

Cuando una idea vive únicamente en tu cabeza, todo tiene sentido. Cuando vive únicamente en un documento, también. Es lógico.

El documento cuenta la historia exactamente como tú la imaginaste. Pero en el momento en que conviertes esa idea en algo tangible… empiezan a aparecer preguntas que nunca habías considerado.

¿Por qué este botón está aquí?

¿Y si el usuario no hace clic?

¿Realmente necesita este paso?

¿Por qué asumí que este flujo era el correcto?

Y, de pronto, te das cuenta de que el prototipo no estaba validando la solución.

Estaba validando tu forma de pensar.

Creo que aquí es donde muchos seguimos usando AI de forma muy limitada. La usamos para escribir. Para resumir reuniones. Para redactar historias de usuario. Para generar PRDs. Y no digo que esté mal. Yo también lo hago.

Pero donde más valor le encontré estas semanas fue en otro lugar. En usarla como un compañero de exploración. Como alguien que constantemente me obliga a preguntarme:

“¿Y si esta no fuera la mejor solución?”

“¿Qué otra forma existiría de resolver este problema?”

“¿Qué estoy dando por hecho sin evidencia?”

Curiosamente, las mejores conversaciones que tuve con AI no terminaron con una respuesta. Terminaron con una mejor pregunta. Y sospecho que ahí está una diferencia importante.

Cada vez escucho más que AI hará que los PMs sean más productivos… mi mente piensa en “claro, puede ser”. Pero esa ya no es la idea que más me interesa.

La pregunta que me hago ahora es otra. ¿Y si el verdadero valor de AI no fuera ayudarnos a producir más… sino ayudarnos a pensar mejor?

Porque producir más, sin razonar, ya vimos a dónde nos lleva.

• Más documentos (muchos más!).

• Más prototipos.

• Más funcionalidades.

• Más ruido.

Pensar mejor, en cambio, cambia completamente la calidad de las decisiones.

Estas dos semanas también me hicieron cambiar de opinión sobre los prototipos. Antes los veía como una herramienta para comunicar ideas. Hoy los veo como una herramienta para desafiar mis propias ideas.

Y esa diferencia, aunque parece sutil, cambia por completo la forma en la que trabajo. Ya no construyo un prototipo para convencer a un stakeholder. Lo construyo para encontrar todo aquello que todavía no entiendo. Porque prefiero descubrir mis errores en una tarde… que descubrirlos después de tres meses de desarrollo.

Quizá por eso siento que el rol de Product Manager está cambiando más rápido de lo que muchos imaginamos. No porque ahora tengamos nuevas herramientas.

Las herramientas cambian todos los años. Lo diferente esta vez es que cambió la forma en la que podemos pensar. Y cuando cambia la forma de pensar… termina cambiando también la forma de construir.

No sé si dentro de cinco años seguiremos escribiendo PRDs. No sé qué herramientas estaremos usando. Lo que sí sospecho es que habrá una diferencia muy clara entre dos tipos de PM.

Quienes usen AI para producir más. Y quienes la usen para pensar mejor.

Personalmente, cada vez tengo más claro de qué lado quiero estar.

Hace unas semanas Camila Galvan me invitó a formar parte de un equipo junto con mis compañeras Alma Buyoli y Karina Galindo de una hermosa comunidad llamada Productesas para participar en el Mind the Product: World Product Day Hackathon nos hicimos una pregunta bastante simple:

No es una pregunta técnica. Es una pregunta de producto. La mayoría de las herramientas de ahorro están diseñadas para adultos. Tienen gráficas, porcentajes, metas financieras y dashboards. Pero los niños no se despiertan pensando en optimizar su tasa de ahorro. El problema no es que no entiendan el concepto.

El problema es que todavía no tienen una razón emocional para interesarse.

Y ahí fue donde encontramos el insight que terminó guiando prácticamente todo el producto.

El insight que definió el diseño

Pensamos en los Tamagotchis. No porque fueran mascotas virtuales. Sino porque lograban algo muy difícil: generar apego. Cuando un Tamagotchi se enfermaba o moría, no sentías que habías perdido puntos. Sentías que habías fallado en cuidar algo importante. Eso es aversión a la pérdida en acción. Entonces nos hicimos una pregunta:

¿Qué pasaría si el ahorro estuviera conectado al bienestar de una mascota?

No a una barra de progreso. No a una gráfica. No a una racha. A una mascota que depende de ti. Así nació Quidy.

Una mascota virtual cuya salud está directamente relacionada con los hábitos de ahorro del niño.

Algunas decisiones de producto que marcaron la diferencia

1. Diseñar para la familia, no solo para el niño

Uno de los primeros problemas que encontramos durante la validación. Le di la app a uno de los hijos de mis mejores amigos y de pronto vi que en menos de 1 minuto la mascota ya era adulta ¿cómo lo hizo? Fácil, le puse que había ahorrado todo (se le hizo fácil)

Si un niño registra que ahorró dinero, ¿cómo sabemos que realmente ocurrió?

Por eso terminamos diseñando dos formas de validar ahorros:

• Evidencia mediante fotografía del dinero físico.

• Confirmación por parte de los padres mediante PIN.

Esto cambió el enfoque del producto.

Quidy dejó de ser una app para niños y se convirtió en una experiencia familiar donde el niño ahorra y los padres participan en el proceso.

2. La meta primero, el ahorro después

Muchas apps empiezan preguntando: “¿Cuánto quieres ahorrar por semana?” Pero para un niño esa pregunta no tiene contexto. Nosotros invertimos el flujo.

Primero preguntamos:

¿Qué quieres conseguir?

¿Una bicicleta? ¿Un videojuego? ¿Un juguete?

Después calculamos cuánto necesita ahorrar para llegar ahí. La motivación aparece antes que el cálculo.

3. Recompensar consistencia, no dinero

Creamos una economía interna basada en gems.

Las gems se obtienen ahorrando y permiten desbloquear personalizaciones para la mascota. No hay dinero real involucrado. La idea era reforzar un aprendizaje simple: La consistencia genera resultados. Y hacer visible ese comportamiento dentro del juego.

Cómo construimos el producto

Quidy nació durante el hackathon de Pendo × Mind the Product 2026. Aunque participé principalmente en la construcción técnica, el producto fue resultado de muchas conversaciones, ideas e iteraciones del equipo.

Y personalmente fue uno de los proyectos donde más sentí el impacto de usar IA como copiloto de desarrollo. No porque escribiera todo por mí. Sino porque redujo enormemente el tiempo entre una idea y una versión funcional que pudiéramos probar.

En lugar de pasar horas investigando cómo implementar algo, podía describir el comportamiento que buscábamos, generar una primera versión y después dedicar más tiempo a lo que realmente importa:

Tomar decisiones de producto. El stack terminó siendo React, TypeScript, Supabase, Tailwind, Framer Motion y Vercel. Pero si soy honesta, esa no fue la parte más interesante.

Lo más difícil no fue programar

Fue decidir. ¿Cuándo debe enfermarse la mascota? ¿Qué tan visible debe ser el impacto de no ahorrar? ¿Cómo explicas conceptos financieros a un niño sin convertir la experiencia en una clase?

Esas preguntas no tienen una respuesta correcta. No vienen en un framework. No aparecen en un curso. Se resuelven iterando, observando usuarios y ejerciendo criterio. Y esa fue probablemente la lección más importante del proyecto.

Los productos más memorables rara vez ganan porque explican mejor.

Normalmente ganan porque logran que las personas sientan algo.

Lo que descubrimos sobre el mercado

Durante el desarrollo entendimos que Quidy no es únicamente un producto para niños. Es un producto que funciona gracias a la colaboración entre niños y padres.

Los niños generan el hábito. Los padres validan y refuerzan el comportamiento. Esa relación terminó convirtiéndose en una de las partes más valiosas de la experiencia.

Y también nos hizo ver una oportunidad interesante. La educación financiera infantil sigue siendo un espacio poco explorado y con muchísimas oportunidades para innovar desde producto.

¿Qué sigue?

Quidy comenzó como un proyecto de hackathon.

Pero el feedback que hemos recibido nos dejó varias preguntas abiertas:

• ¿Cómo involucramos a maestros o escuelas?

• ¿Cómo diseñamos retos grupales de ahorro?

• ¿Qué sucede cuando un niño alcanza su meta?

• ¿Cómo cerramos ese ciclo emocional de forma memorable?

Todavía no tenemos todas las respuestas. Pero justamente por eso construir productos sigue siendo tan interesante. Porque cada respuesta suele abrir tres preguntas nuevas.

Si tienes hijos, sobrinos o trabajas en temas de educación financiera, me encantaría conocer tu opinión sobre el concepto.. prueben la app aquí:

PROBAR QUIDY APP

Y si eres PM, me interesa especialmente saber qué decisiones habrías tomado diferente.

Una extensión de Google Chrome está auditando que verdaderamente yo esté escribiendo y no sea una IA que lo haga por mí.

Por ejemplo, voy a ir a copiar y pegar un texto a ver cómo me califica la aplicación:

¿Qué es Proof of Human?

Una iniciativa para certificar criptográficamente que tu contenido, código o diseño fue creado por esfuerzo cognitivo humano, no por IA.

Entra en: https://myproofofhuman.app/beta

Lo interesante de este proyecto es que verifica en tiempo real la velocidad con la que escribes, los movimientos del mouse así como aprende ciertos patrones para certificar que eres una persona real escribiendo.

Vamos a ponerlo a prueba, la siguiente parte del contenido de este post, la solicitaré a una IA (veamos si se da cuenta).

Aquí tienes el borrador completo, estructurado de principio a fin, listo para que solo tengas que copiar, pegar y publicar. Tiene ganchos visuales, un lenguaje muy claro y un cierre que invita a la conversación.

🤖 ¿Eres humano? El gran reto de la era de la IA

¿Alguna vez has tenido que resolver tres “captchas” seguidos en una página web para demostrar que no eres un robot? Da flojera, pero el problema de fondo es serio: con el avance de la Inteligencia Artificial, distinguir a un humano de un bot en internet se ha vuelto casi imposible.

Hoy en día, una IA puede escribir, diseñar y hablar exactamente como tú o como yo. Esto rompe la confianza en la red.

Por eso están naciendo las iniciativas de Proof of Humanity (Prueba de Humanidad). No buscan saber tu nombre, ni tus datos bancarios; solo quieren crear un “pasaporte digital” universal que certifique una sola cosa: “Detrás de esta pantalla hay una persona real”.

Aquí te cuento cuáles son las tres principales iniciativas que están compitiendo por lograrlo y cómo funciona cada una:

1. La vía biométrica: World ID (Worldcoin)

• ¿Cómo funciona? Usan un dispositivo físico llamado Orb para escanear el iris de tu ojo.

• La idea: El iris es una firma única en el mundo. Al escanearlo, el sistema genera un código numérico que demuestra que existes y que eres único, sin guardar tu nombre o tu identidad en una base de datos. Es la iniciativa más masiva y rápida, aunque también la que genera más debates sobre privacidad.

• Mira más en su página oficial: https://world.org/es-es

En México y gran parte de LATAM no existen “Orbs” para registrarte.

2. La vía de la comunidad: Proof of Humanity

• ¿Cómo funciona? Aquí no hay escáneres, hay humanos cuidando a humanos. Para registrarte, subes un video corto y dejas un depósito en garantía.

• La idea: Los usuarios que ya están verificados dentro de la plataforma revisan tu video y “votan” para confirmar que eres una persona de carne y hueso. Si la comunidad descubre que alguien intentó meter un bot o un video falso, esa cuenta se rechaza y se pierde el depósito. Es un modelo 100% comunitario y descentralizado.

Puedes ver más del proyecto aquí: https://proofofhumanity.id/

3. La vía del historial digital: Gitcoin Passport

• ¿Cómo funciona? No te pide videos ni escaneos de ojos. En su lugar, analiza tu comportamiento en internet.

• La idea: Conectas tus cuentas existentes (Google, LinkedIn, redes sociales o tus transacciones pasadas en la web). La plataforma junta todas estas piezas y te da una “puntuación de humanidad”. Entre más historial de uso real y legítimo tengas, más alta es tu puntuación.

Checa el proyecto por acá: https://gitcoin.co/blog/intro-to-passport

¿Por qué nos debería importar esto a todos?

Esto no es solo para expertos en tecnología; es el futuro de nuestro tiempo en internet:

• Para el día a día: Imagina un internet libre de spam masivo, donde sabes que el freelancer que contratas o el creador al que sigues es real.

• Para los negocios: Evita que miles de cuentas falsas (bots) arruinen sorteos, alteren votaciones de proyectos o saturen los canales de atención.

• Justicia digital: Permite que apoyos económicos, accesos globales o herramientas gratuitas lleguen a personas reales, asegurando una sola cuenta por humano y evitando fraudes masivos.

🚨 Fin del texto de la IA. Regreso yo, la humana.

Acabo de darle clic a “Finalizar Sesión” en el certificador. El sistema acaba de procesar mi flujo de trabajo, lo selló criptográficamente en la nube y este es el resultado real:

👉 Puedes ver mi certificado en vivo aquí: https://myproofofhuman.app/verify/391f2bc7-d526-41fb-9be4-bf9e01c16ff2

El veredicto: La aplicación detectó que pasé 8 minutos y 16 segundos escribiendo activamente, pero el total de la sesión fue de 10 min y 45 segundos. ¿Por qué? Porque detectó un espacio muerto de más de 2 minutos donde estuve fuera de la pestaña solicitándole el texto al LLM, seguido de un evento de Paste (pegado masivo) de caracteres sin tecleo previo. El sistema me penalizó el score justamente.

Para llevar el experimento al límite, hice un segundo post donde literalmente solo copié y pegué lo que hizo la IA de golpe, sin escribir una sola palabra.

👉 Miren cómo el certificado lo descubrió al instante en vivo: https://myproofofhuman.app/verify/0bd748fd-3cf3-422a-86ba-252c5498a137

Así es como identificó que “copie y pegue” el contenido.

Puedes ver el certificado en vivo aquí: https://myproofofhuman.app/verify/0bd748fd-3cf3-422a-86ba-252c5498a137

💡 Por qué construí esto (El Nacimiento de “My Proof of Human”)

Como Product Manager en el mundo Tech, veo este dolor todos los días: con la saturación de contenido e IA, la confianza digital se está colapsando. Las empresas ya no confían en lo que compran en las plataformas de freelancers, y los creadores o programadores premium están viendo sus tarifas destruidas porque los clientes asumen que todo lo hace ChatGPT en 5 segundos. Los detectores de IA tradicionales fallan y están llenos de falsos positivos.

Por eso creé My Proof of Human. Un software/SaaS ultra-ligero para profesionales que certifica el proceso, no el resultado.

• Para creadores y freelancers: Es el escudo definitivo para demostrar que tu esfuerzo cognitivo vale cada dólar y defender tus tarifas premium en Upwork, Fiverr o Substack.

• Para las empresas: Es la garantía de que están pagando por talento real e ideas originales, blindándose contra fraudes de bots o copy-pastes sin auditar.

🚀 ¡Únete a la BETA Cerrada Gratuita!

El MVP ya está listo y es una extensión de Chrome. Estoy abriendo una Beta Cerrada exclusiva para los primeros 50 early adopters (escritores, programadores, diseñadores en Canva/Photoshop y agencias) que quieran empezar a adjuntar sellos de flujo humano verificado a sus entregables.

Si quieres proteger el valor de tu tiempo y tu trabajo antes de que lancemos la versión de pago:

1. Entra a https://myproofofhuman.app/beta

2. Deja tu correo en la lista de espera o comenta directo este post!

El futuro de internet no pertenece a los bots, pertenece a los humanos que los dominan. ¿Te unes?

¿Te gustaría saber como desarrolle la extensión? ¿Qué elementos utilicé y como fue el proceso de construcción? Lo comparto en mi siguiente POST.

Hay algo que empezó a pasar desde que AI se volvió accesible para todos.

De repente, todo el mundo “construye”.

Mockups en minutos.
PRDs generados automáticamente.
Landing pages instantáneas.
Features saliendo más rápido que nunca.

Y al principio… eso se siente impresionante.

Hasta que empiezas a mirar con más atención.

Porque muchas de esas cosas:

• se ven bien

• se sienten rápidas

• parecen inteligentes

Pero en realidad… están vacías.

Hay una expresión que empezó a aparecer para describir esto:

👉 AI slop

Básicamente: cosas generadas rápido, con poca profundidad real.

Mucho output.
Poco pensamiento.

Y honestamente, creo que muchos PMs están cayendo ahí sin darse cuenta. Porque confundieron una herramienta de aceleración… con una herramienta de criterio.

AI puede ayudarte a producir más rápido. Pero no sabe automáticamente:

• qué problema vale la pena resolver

• qué edge cases importan

• qué experiencia realmente tiene sentido

• o qué decisión es correcta para tu producto

Y aquí es donde el rol se pone interesante. Porque mientras más fácil se vuelve construir… más importante se vuelve pensar bien.

Antes, el cuello de botella era ejecución. Hoy, cada vez más, el cuello de botella empieza a ser claridad. Piensa en esto. Hace algunos años, tener una idea y convertirla en algo visible requería bastante fricción. Entonces, naturalmente, la gente filtraba más antes de construir.

Ahora puedes generar algo funcional en minutos. Y eso tiene dos efectos:

El bueno:
👉 experimentas más rápido.

El peligroso:
👉 también puedes llenar todo de basura más rápido.

Y sí, suena duro decirlo así. Pero creo que es importante decirlo. Porque estamos entrando a una etapa donde:

• hacer algo rápido ya no impresiona tanto

• generar output ya no es suficiente

• y “verse productivo” ya no significa pensar bien

Aquí es donde muchos PMs se van a perder. Porque van a usar AI para:

• producir más documentos

• generar más pantallas

• lanzar más cosas

Pero sin mejorar realmente la calidad de las decisiones. Y eso eventualmente se nota.

En productos confusos.
Experiencias infladas.
Features que nadie usa.
Flujos que “se ven modernos” pero resuelven poco.

Porque AI acelera lo que ya existe. Si el pensamiento es mediocre… la velocidad solo amplifica el problema Por eso siento que el verdadero valor del PM empieza a moverse hacia otro lugar No hacia:

• escribir más

• producir más

• coordinar más reuniones

Sino hacia:

👉 pensar con más claridad
👉 detectar problemas antes
👉 hacer mejores preguntas
👉 saber qué NO construir

Porque cuando cualquiera puede generar algo rápido… la ventaja deja de estar en generar. Y empieza a estar en discernir.

Aquí es donde creo que AI sí cambia profundamente el rol. No reemplazando PMs. Sino separando muchísimo más a:

• quienes solo producen output
  de

• quienes realmente entienden producto.

Y curiosamente, creo que los mejores PMs van a usar AI menos como “máquina de contenido”… y más como:

• sparring de ideas

• herramienta de exploración

• forma de reducir incertidumbre rápido

No para evitar pensar. Sino para pensar mejor.

En el siguiente artículo quiero entrar a algo todavía más importante:

👉 cómo usar prototipos y AI para realmente tomar mejores decisiones… no solo producir cosas más rápido.

Suscríbete ahora

Porque ahí está la diferencia que empieza a importar de verdad.

Si llegaste hasta aquí y pensaste: “ok… quizá estoy produciendo demasiado y pensando poco” Bienvenid@. Creo que esa conversación apenas está empezando.

Hay algo curioso cuando hablas de prototipos con muchos Product Managers.

La mayoría responde algo como:

“Sí, estaría increíble prototipar más… pero no tengo tiempo”
“No sé diseño”
“Eso le toca al designer”
“Yo no soy técnico”

Y honestamente… durante mucho tiempo tenían razón.

Porque prototipar antes sí era complicado.

No era algo que abrías y resolvías en una tarde. Requería herramientas especializadas, bastante tiempo y, muchas veces, suficiente conocimiento técnico para convertir una idea en algo mínimamente interactivo.

Entonces los equipos se adaptaron.

Los PMs escribían.
Los diseñadores diseñaban.
Los developers construían.

Y el sistema funcionó así durante años.

El problema es que el entorno cambió… pero muchos siguen operando igual.

Hoy puedes construir un flujo funcional, una simulación o incluso una experiencia interactiva usando lenguaje natural y herramientas con AI. Cosas que antes requerían días o semanas, ahora pueden existir en minutos.

Y eso rompe algo importante:

👉 la barrera para construir.

Porque antes el problema era:

“No puedo prototipar aunque quiera”

Ahora muchas veces el problema es:

“No he cambiado mi forma de trabajar”

Y esas son conversaciones muy distintas.

Aquí es donde empieza a aparecer una oportunidad enorme para PMs.

No porque ahora deban convertirse en expertos de diseño o desarrollo, sino porque pueden empezar a pensar con más claridad usando construcción rápida como parte del proceso.

Y sí, eso cambia muchísimo cómo trabajas.

Piensa en esto.

Antes, validar una idea podía tomar:

• juntas

• documentos

• alineaciones

• handoffs

• feedback tardío

Ahora puedes poner algo enfrente del equipo muchísimo antes.

Y cuando eso pasa, aparecen preguntas más útiles:

• “esto se siente raro”

• “este paso sobra”

• “aquí el usuario se perdería”

Ese tipo de feedback casi nunca aparece leyendo un documento.

Y honestamente, creo que aquí muchos PMs todavía están subestimando lo que viene.

Porque siguen viendo prototipos como:

• algo visual

• algo “nice to have”

• algo de diseño

Cuando en realidad empiezan a convertirse en una herramienta de claridad.

No para reemplazar pensamiento.

Sino para acelerarlo.

Y aquí quiero aclarar algo importante.

Construir rápido no significa construir bien automáticamente.

De hecho, aquí aparece otro problema nuevo:

👉 hacer cosas rápidas… pero vacías.

Flujos que se ven bien.
Pantallas bonitas.
Experiencias “impresionantes”.

Pero sin profundidad real.

(Aquí es donde empieza el famoso AI slop del que quiero hablar más adelante).

Porque AI puede ayudarte a construir más rápido.

Pero no puede pensar por ti.

Todavía.

Entonces el valor del PM empieza a moverse.

Ya no solo hacia:

• coordinar

• documentar

• priorizar

Sino hacia algo más importante:

👉 saber qué vale la pena construir
👉 detectar problemas antes
👉 convertir ambigüedad en claridad

Y los prototipos ayudan muchísimo en eso.

No porque sean “bonitos”.

Sino porque vuelven visibles ideas que antes vivían solo en la cabeza o en documentos.

Creo que estamos entrando a una etapa donde los PMs que aprendan a construir rápido van a aprender más rápido también.

Y en producto…

aprender más rápido casi siempre termina siendo ventaja.

En el siguiente artículo quiero hablar de algo importante:

👉 por qué muchos PMs están usando AI mal… y cómo terminaron creando puro “AI slop”.

Porque sí, construir rápido ayuda.

Pero construir sin criterio… puede empeorar las cosas muchísimo.

Si llegaste hasta aquí y pensaste:

“ok… quizá ya no tengo tantas excusas para no prototipar”

Exacto.

Ese es el punto.

Este es el cuarto de una serie de 10 artículos donde desarmo este cambio:

👉 Cómo pasar de depender de contexto incompleto

Suscríbete ahora

👉 A construir claridad usando estructura + AI

Suscríbete ahora y no te pierdas los siguientes artículos :)

Hubo un tiempo donde prototipar era algo “extra”.

Algo que hacía diseño.
Algo bonito para presentaciones.
Algo que aparecía ya muy adelante en el proceso.

Y honestamente… tenía sentido.

Hacer prototipos antes era lento, costoso y hasta un poco frustrante. Necesitabas herramientas complejas, bastante tiempo y, muchas veces, depender completamente de alguien más para convertir una idea en algo interactivo.

Entonces la mayoría de PMs hacía lo lógico:

explicar.

PRDs, documentos, tickets, diagramas. Y listo. Si la idea estaba bien escrita, el equipo se encargaba del resto.

Pero algo empezó a cambiar.

Hoy puedes pasar de una idea a algo tangible en cuestión de minutos. No perfecto, no listo para producción, pero sí lo suficientemente real como para entender si tiene sentido o no. Y eso cambia muchísimo más de lo que parece.

Porque cuando puedes construir rápido, empiezas a pensar diferente.

Antes, muchas decisiones se tomaban imaginando cómo se sentiría algo. Ahora puedes verlo. Probarlo. Romperlo. Cambiarlo. Y descubrir problemas mucho antes de que lleguen a desarrollo.

Ahí está el verdadero valor de los prototipos.

No es “hacer mockups”.

Es reducir incertidumbre.

Y aquí viene algo interesante.

Muchos PMs todavía ven los prototipos como una herramienta de comunicación. Algo para mostrarle al equipo o a stakeholders. Pero los PMs que realmente están evolucionando empiezan a usarlos como herramienta de pensamiento.

Porque construir algo, aunque sea simple, te obliga a enfrentar preguntas que normalmente no aparecen en un documento.

• ¿Qué pasa después de este paso?

• ¿Esto realmente tiene sentido para el usuario?

• ¿Qué información falta aquí?

• ¿Esto resuelve el problema… o solo se ve bien?

Y esas preguntas cambian la calidad de las decisiones.

Por eso siento que el rol está entrando en una transición rara.

Todavía hay equipos operando como si el PM solo necesitara escribir y coordinar. Pero al mismo tiempo, están apareciendo PMs que ya construyen prototipos, validan flujos y usan AI para iterar ideas muchísimo más rápido.

Y la distancia entre esos dos perfiles se va a notar cada vez más.

No porque uno “trabaje más”.

Sino porque uno aprende más rápido.

Aquí es importante aclarar algo.

Esto no significa que ahora todos los PMs tengan que convertirse en diseñadores o developers.

Ese no es el punto.

El punto es que la barrera para construir bajó muchísimo.

Y cuando la fricción baja, el comportamiento cambia.

Piensa en esto.

Si puedes convertir una idea en algo visible en 20 minutos…

¿realmente tiene sentido esperar semanas para descubrir si estaba mal planteada?

Ese es el cambio.

Antes, prototipar era una etapa.
Ahora empieza a convertirse en parte del pensamiento.

Y honestamente, creo que aquí muchos PMs se van a quedar atorados.

Porque siguen viendo AI como una herramienta para producir más documentación, cuando en realidad la oportunidad más grande está en reducir el tiempo entre:

idea → visualización → feedback → decisión

No para moverte más rápido por moverte más rápido.

Sino para reducir incertidumbre antes de comprometer recursos reales.

El PM que solo documenta depende demasiado de interpretación.

El PM que prototipa empieza a crear claridad.

Y esa diferencia se vuelve enorme en equipos modernos.

En el siguiente artículo quiero hablar de algo importante:

👉 por qué casi nadie prototipaba antes… y por qué eso ya dejó de ser excusa.

Porque entender eso ayuda muchísimo a entender hacia dónde se mueve el rol.

Si llegaste hasta aquí y pensaste:

“ok… quizá debería empezar a construir más cosas aunque no estén perfectas”

Sí.

Probablemente sí.

Este es el tercero de una serie de 10 artículos donde desarmo este cambio:

👉 Cómo pasar de depender de contexto incompleto

👉 A construir claridad usando estructura + AI

Suscríbete ahora y no te pierdas los siguientes artículos :)

Hay algo que durante mucho tiempo definió a un buen Product Manager: escribir bien. PRDs claros, contexto bien documentado, historias bien pensadas. Y durante años, eso funcionó. Si sabías escribir, pensabas bien. Si pensabas bien, el equipo construía mejor. Ese era el juego.

Pero hay un problema. Ese modelo asumía algo que hoy ya no es cierto: que la mejor forma de alinear es explicando.

Y aquí es donde empieza el quiebre.

Explicar suena bien en teoría… hasta que lo ves en la práctica. Lees un PRD y todo parece lógico. En la junta, todos asienten. El equipo empieza a trabajar. Y días después empiezan las dudas. “Oye, esto no lo había entendido así”, “creo que esto no estaba contemplado”, “¿qué pasa en este caso?”. No porque el PRD esté mal escrito, sino porque hay algo que el documento no puede resolver: la interpretación.

Cada persona completa los vacíos a su manera. Y eso introduce fricción.

¿Qué cambia?

Durante años, lo aceptamos como parte del proceso. Más claridad implicaba más documentación. Más documentación implicaba mejor alineación. Pero eso tiene un límite. Llega un punto donde escribes más, detallas más, explicas mejor… y aun así la ejecución no mejora en la misma proporción. Porque el problema ya no es cuánto explicas. Es que estás usando el medio equivocado.

Hoy tienes algo que antes no existía: la posibilidad de mostrar la idea. No en slides, no en texto, sino en algo que se puede ver, tocar e interactuar. Un flujo, un prototipo, una simulación. Y cuando eso aparece, cambia la conversación. La ambigüedad baja, las preguntas se vuelven más concretas y las decisiones se aceleran. Ya no es “¿entendiste lo que quise decir?”, ahora es “¿ves esto? ¿funciona o no?”.

Entonces no, los PRDs no desaparecen. Siguen siendo útiles. Pero dejan de ser el centro. Pasan a ser soporte, contexto, documentación. La claridad real empieza antes, cuando construyes algo, aunque sea imperfecto.

Entonces, ¿qué más se requiere hacer?

Aquí es donde muchos se equivocan. Intentan usar AI para hacer lo mismo de siempre, pero más rápido: PRDs más completos, mejor redacción, más output. Pero siguen jugando el mismo juego. Y eso genera una ilusión peligrosa: “esto se ve bien… entonces debe estar bien”. No necesariamente. Escribir mejor no elimina la ambigüedad, solo la disfraza mejor.

El cambio real no es escribir mejor. Es cambiar el orden.

Antes: entender → escribir → ejecutar.
Ahora: construir → alinear → ejecutar.

Y en ese “construir” pasan cosas importantes. Descubres edge cases antes, detectas huecos en la lógica y tomas decisiones con algo tangible. No necesitas alta fidelidad, necesitas algo que haga visible la idea.

Pasa a la acción con la IA

Piensa en esto. En lugar de escribir “el usuario podrá completar el flujo de registro en 3 pasos…”, construyes un flujo básico. En minutos alguien te dice: “esto no tiene sentido en el paso 2”. Ese insight no sale del documento. Sale de ver algo.

El problema no es que estés escribiendo PRDs. Es que estás dependiendo de ellos más de lo que deberías. El rol no se trata de explicar mejor, se trata de hacer las ideas más claras. Y hoy, la forma más rápida de hacer eso no es escribiendo. Es mostrando.

En el siguiente artículo vamos a ir un paso más allá: prototipos como habilidad. No como algo “nice to have”, sino como algo que empieza a definir a los PMs que realmente avanzan.

Si alguna vez pensaste “pero esto ya lo habíamos definido…”, probablemente lo habían escrito. No necesariamente lo habían entendido.

¿Cómo lo hago?

Te recomiendo herramientas como Claude Code, Codex (ChatGPT) y/o Cursor. En este post no entraré en un tutorial de como hacerlo, pero ya existe contenido en internet para que puedas seguir paso a paso como volver tu PRD un prototipo y de eso hablaremos en el siguiente post.

Un PM promedio intenta entender todo antes de actuar.

Un PM que evoluciona empieza a construir para entender.

(Cambia sutilmente… pero lo cambia todo).

Si quieres saber en detalle cómo hago para ejecutar el Piensas → construyes → entiendes mejor → decides.. mantente pendiente de mis próximos artículos.

Saludos!

Hay algo curioso del rol de Product Manager.

Pocas veces alguien te lo explica.
y nadie te advierte lo complicado.
Y, por alguna razón, todos actúan como si fuera obvio.

(Spoiler: no lo es).

Imagina esto. Llegas a un nuevo equipo. Te dan acceso a herramientas. A documentos. A Slack. A juntas (muchas juntas). Y alguien —con toda la tranquilidad del mundo— espera que en cuestión de días:

entiendas el producto,
priorices correctamente,
y tomes decisiones con impacto.

Así. Es nuestra realidad como Product Managers 🤭. Ahora, lo interesante no es eso. Lo interesante es lo que pasa en tu cabeza mientras tanto.

Porque tú estás ahí, viendo todo… y pensando:

“Siento que debería tener esto más claro”

Pero no lo tienes. No porque seas malo, o porque te falte talento, ni siquiera porque no estés poniendo esfuerzo, es otra cosa. Es esa sensación constante de estar operando con piezas incompletas.

Documentos que no cuentan toda la historia. Decisiones que alguien tomó… pero no sabes por qué. Prioridades que cambian, pero nadie explica con claridad el criterio que se tomó. Y después de todo tú, intentando conectar puntos que nadie se tomó el tiempo de ordenar.

Desde afuera, todo parece funcionar.

Las cosas salen.
El equipo avanza.
El producto “vive”.

Pero por dentro… la experiencia es distinta. Es como entrar a una conversación que empezó hace meses. Todos entienden el contexto. Todos siguen el hilo. Y tú… estás tratando de no quedarte atrás mientras descifras de qué están hablando.

Es que estás intentando operar el rol con una forma de trabajar…
que ya cambió.

El problema no es solo la falta de claridad

Es que el rol de PM ya no es el mismo. Pero no te lo han dicho. Durante años, el juego era este:

• Entender el problema

• Escribir un PRD

• Alinear al equipo

• Ejecutar

Y listo.

Si escribías bien, pensabas bien. Hoy… eso ya no es suficiente. Porque mientras tú estás intentando entender todo… la forma de construir producto ya cambió.

Ahora puedes con ayuda de la IA:

• Generar flujos en minutos

• Crear prototipos funcionales sin código

• Validar ideas antes de escribir una sola línea de PRD

Y eso cambia todo.

Porque ya no se trata solo de explicar una idea. Se trata de mostrarla.

Y aquí es donde empieza la fricción

Porque tú sigues intentando ganar claridad leyendo. Pero el nuevo entorno te exige claridad construyendo.

Entonces pasa algo interesante:

• Lees documentos que no terminan de explicar nada

• Entras a juntas donde todo suena lógico… pero abstracto

• Tomas decisiones con información incompleta

El error más común hoy

Pensar que AI viene a ayudarte a escribir más rápido.

Entonces:

• Generas PRDs con ChatGPT

• Documentas mejor

• Produces más

Pero sigues con el mismo problema:

👉 No tienes claridad real

Porque escribir mejor ≠ entender mejor

Y peor aún… empiezas a generar cosas que “se ven bien” pero no necesariamente están bien pensadas.

(A esto algunos ya le llaman AI slop).

Lo que pasa realmente

Estás en medio de un cambio de paradigma.

Antes:

👉 Pensabas → escribías → construías

Ahora:

👉 Piensas → construyes → entiendes mejor → decides

Ese orden cambia todo.

Porque la claridad ya no viene solo de analizar. Viene de interactuar con lo que estás creando.

El verdadero problema invisible

No es que no tengas contexto. No es que no sepas lo suficiente. Es que no tienes un sistema para:

• estructurar lo que sabes

• identificar lo que no sabes

• y usar construcción (prototipos, AI) para cerrar ese gap

Entonces operas así:

• reaccionando

• ajustando

• intentando “ponerte al día”

Y eso genera la sensación que todos conocemos:

👉 “Siento que voy atrás”

(Aunque no lo estés).

Entonces… ¿qué hacer distinto en la práctica?

Si hoy estás operando como la mayoría de PMs: lees documentos para entender, escribes PRDs para alinear y tomas decisiones con la información disponible.

Ahora compáralo con este pequeño cambio:

En lugar de intentar entender todo primero, empiezas a construir algo simple lo antes posible. Puede ser un flujo básico, un prototipo rápido o incluso una simulación con AI. No para que esté perfecto, sino para responder algo muy específico: ¿esto tiene sentido o no?

Y aquí pasa algo interesante.

Cuando construyes, detectas vacíos más rápido, ves inconsistencias que no estaban en el documento y tomas decisiones con menos suposición.

Es decir, dejas de depender solo de información… y empiezas a generar claridad activamente.

No es más trabajo. Es un orden diferente.

Antes: entender → escribir → ejecutar.
Ahora: construir → entender mejor → decidir.

Cuando introduces estructura + construcción:

• Dejas de depender solo de documentos

• Empiezas a validar ideas más rápido

• Tomas decisiones con menos incertidumbre

No porque ahora tengas más información. Sino porque estás usando mejor el proceso.

Un PM promedio intenta entender todo antes de actuar.

Un PM que evoluciona empieza a construir para entender.

(Cambia sutilmente… pero lo cambia todo).

Si quieres saber en detalle cómo hago para ejecutar el Piensas → construyes → entiendes mejor → decides.. mantente pendiente de mis próximos artículos.

Saludos!

Seré directa.

La mayoría de los PMs hablan de “estar cerca del cliente” como si fuera una virtud. Pero cuando les preguntas cuándo fue la última vez que leyeron feedback de verdad, la respuesta es algo así como “mmm… el mes pasado, creo, o quizá antes”.

No es flojera. Es que el proceso es brutalmente caro.

Una ronda de entrevistas con usuarios: semanas. Una encuesta NPS bien analizada: días, varios involucrados y mucha paciencia. Y cuando todo eso termina, tienes insights… para ese proyecto. El siguiente proyecto empieza desde cero.

La IA cambió esa ecuación. Y si eres PM y todavía no la estás usando para generar customer insights, te estás perdiendo de la herramienta más poderosa que ha llegado a nuestro rol en años.

¿Qué son los customer insights y por qué importan tanto?

No son lo mismo que el feedback del cliente ni que la investigación. Los customer insights son las piezas de información únicas y accionables que te ayudan a entender mejor a tu usuario y a construir mejores productos.

Se usan de dos formas: directo en el roadmap, o de manera indirecta para entrenar tu intuición de producto. Y esa segunda parte es más importante de lo que parece, porque la realidad es que la gran mayoría de micro-decisiones que tomas como PM todos los días las guía tu intuición, no un documento de research.

Cuantos más insights consumes, mejor se vuelve esa intuición.

Y aquí es donde entra la IA.

Caso 1: Analiza tu encuesta NPS en minutos

Antes, procesar 2,000 respuestas de NPS requería: un analista calculando scores, alguien de marketing leyendo cada verbatim, tú revisando las categorías, otra vuelta de recategorización… semanas de trabajo de al menos cuatro personas.

Hoy, subes tu CSV a Claude y usas este prompt:

“Eres un investigador experto en análisis de encuestas NPS. Analiza los resultados adjuntos y: calcula el NPS general, calcula el NPS mensual en tabla, grafícalo con línea de tendencia.”

Después le pides los temas cualitativos:

“Analiza los verbatims y dime los top 5 temas de lo que la gente ama del producto. Incluye hasta 5 ejemplos por tema. Preséntalo en bullets.”

Y finalmente:

“Con base en las áreas de mejora y los features más solicitados, propón un roadmap potencial.”

Lo que antes tardaba semanas, ahora tarda una tarde. Y lo puedes hacer mensualmente en lugar de trimestralmente.

Caso 2: Prepara mejores entrevistas con usuarios

El problema con las entrevistas no es hacerlas. El problema es hacerlas bien.

La mayoría de las preguntas que usamos en entrevistas están mal. Le preguntamos a la gente si les gustaría algo en lugar de preguntarles qué hacen hoy. Validamos nuestras hipótesis en lugar de buscar contradicciones.

Hay un libro que se llama The Mom Test de Rob Fitzpatrick cuya premisa es sencilla: si puedes hacerle esas preguntas a tu mamá y ella no puede mentirte, estás preguntando bien.

Con IA puedes pedirle que aplique esa metodología a tu contexto específico:

“Eres un investigador UX experto. Voy a entrevistar a [perfil de usuario] sobre [problema]. Genera una guía de entrevista usando las mejores prácticas de The Mom Test. Mis objetivos de investigación son: [lista aquí].”

Lo que antes requería una UX researcher dedicada, ahora puedes hacerlo tú con un buen prompt y contexto suficiente.

Caso 3: El feedback river

Este es el que más me gusta y el que menos gente tiene.

Un feedback river es un sistema que consolida todas tus fuentes de feedback en un solo canal, generalmente Slack. NPS, encuestas de cancelación, reseñas en tiendas de apps, menciones en redes, tickets de soporte, todo en un solo lugar.

El problema que resuelve es real: la mayoría de los PMs tienen una relación de pull con el feedback. Tienes que acordarte de ir a buscarlo, entrar a cada sistema, jalar los datos. Como nadie tiene tiempo, terminas mirando feedback de vez en cuando y solo de algunas fuentes.

El feedback river lo convierte en push: el feedback llega a ti, todos los días, de todas las fuentes.

Con IA encima, ese river también te resume los temas más frecuentes, te dice qué está subiendo o bajando, y te deja hacer preguntas directamente al repositorio.

Herramientas que puedes usar hoy para montarlo: Reforge Insight Analytics, Enterpret, Kraftful, Unwrap.

La conclusión incómoda

Hay PMs que toman decisiones de producto basándose en lo que les dijo alguien en una junta hace tres semanas. O en lo que se les ocurrió en la regadera. O en lo que dijo el CEO.

Y hay PMs que tienen un sistema continuo de insights que los hace mejores cada semana, porque su intuición se entrena constantemente con datos reales de usuarios reales.

La IA puede eliminar casi toda la fricción que te impide consumir más feedback, más seguido, de más fuentes.

Y esa diferencia, con el tiempo, es la que separa a los buenos PMs de los grandes.

¿Te ha gustado el artículo?, dime qué opinas en los comentarios

Aprovechando que hace 2 días fue 8 de marzo, día internacional de la mujer, hice algo que quizá debí haber hecho antes: busqué cuántas mujeres hay con el rol de “Product Manager” en LinkedIn.

Tomé una muestra de 189 perfiles de Product Managers en México. Sin filtros raros, sin metodología académica. Solo busqué, fui copiando resultados y los analicé uno por uno.

El resultado: 65% hombres. 35% mujeres.

Y eso me hizo pensar.

Porque el trabajo de un PM no es escribir código ni levantar pesas. Es entender personas. Conectar equipos que no se hablan. Tomar decisiones con información incompleta y sin tener todas las respuestas. Comunicar hacia arriba, hacia abajo y hacia los lados al mismo tiempo. Navegar en la ambigüedad sin perder el norte.

¿A quién conozco que haga todo eso naturalmente?

A las mujeres.

No es un cliché. Es que el perfil del buen PM —empatía, escucha activa, comunicación clara, gestión de la incertidumbre, visión sistémica— resulta que son exactamente las habilidades que muchas mujeres han desarrollado y afinado a lo largo de su vida, en contextos muy distintos al trabajo.

Comunicar: Las mujeres tienden a adaptar su mensaje según la audiencia con una naturalidad que en producto es oro puro. Hablarle al equipo de ingeniería distinto que al CEO distinto que al cliente, sin perder el hilo, es una habilidad central del rol.

Navegar en la ambigüedad: El PM vive en un estado permanente de “no tengo toda la información pero igual tengo que decidir”. Esa tolerancia a la incertidumbre, ese saber avanzar sin que todo esté definido, es algo que las mujeres ejercitan constantemente.

Unir equipos: Producto es el rol que no manda a nadie pero necesita que todos trabajen parejo. Diseño, ingeniería, negocio, datos. Lograr que equipos con objetivos distintos encuentren un punto común requiere inteligencia emocional y habilidad política. Dos cosas en las que las mujeres destacan sin que nadie se los haya pedido formalmente.

Así que si estás leyendo esto y eres mujer y alguna vez pensaste en entrarle al mundo de producto: este rol tiene tu nombre escrito. No necesitas tener todo claro antes de empezar. No necesitas el perfil perfecto. Necesitas exactamente lo que ya tienes.

En producto te estamos esperando. 🚀

Me he inspirado en este artículo de Lenny de 2025, para compartirte un análisis del mercado laboral en producto y tecnología.

En 2025 las tendencias relacionadas eran:

• Las vacantes de PM y de ingeniería iban en aumento

• Los roles en AI estaban explotando

• El trabajo remoto disminuyendo

• Los layoffs iban bajando

¿Cómo vamos en 2026?

Para este análisis he tomado información global de TrueUp ya que cuenta una base de datos sobre empleos en tecnología, gracias a que escanean constantemente roles en big tech / startups y los categorizan.

Ahora sí, vamos a los datos.

1. El volumen de ofertas / vacantes para PM se mantienen

En los últimos 2 años, las ofertas de trabajo a nivel general en tecnología se han mantenido. Si bien hay un aumento del 71.5% vs 2023, esto no significa necesariamente que exista un alza en la demanda. En mi opinión, se mantiene estable el mercado laboral para los Product Managers.

Hoy hay más de 7,000 roles abiertos de Product Manager a nivel global. Esto es el número más alto en más de dos años.

Los roles más buscados son Senior (56.3%), Entry & Mid-Level (35.2%) y Director / VP (6.2%). Los sectores donde más demanda tienen los PM son Consumer, B2B SaaS, Fintech y AI y las habilidades más demandadas son: SQL, LLM, AWS, Jira y Python.

3. Las vacantes en ingeniería y diseño

Ingeniería muestra un patrón igual de mantenerse el mismo número de vacantes, resaltando que casi por cada 1 PM hay 9 ingenieros. Lo que total hace sentido. Los roles más buscados son Senior (52.2%), Entry Mid Level (44.3%) y Director / VP (0.8%). Las habilidades más demandadas en ingeniería son Python, AWS, Kubernetes, Java y C++.

Del lado de diseño UX/UI, el patrón de vacantes se ha mantenido igual por los últimos tres años. A diferencia del punto más bajo con ingeniería, en diseño solo se han aumentado un 25% las vacantes, desde el punto más bajo en 2024. Las habilidades más requeridas en el sector es saber utilizar Figma, Photoshop y CSS. Los roles más contratados son Senior (53.3%), Entry & Mid Level (36%) y Director (4.6%).

4. Las ofertas laborales en IA siguen en alza

Si revisamos solo roles de IA para PM (tanto en empresas de AI como en roles de AI dentro de empresas tradicionales), el crecimiento es impresionante.

Hoy en febrero 2026, hay 33,604 ofertas roles abiertos en IA y de esos 14,118 (42%) son en ingeniería de software, 8,933 (26.5%) en Inteligencia Artificial, 2,422 (7.2%) en Data. Quedando 1,099 (3.2%) para Product Managers y no apareciendo alguno relacionado con Diseño UX/UI.

Si hay una tendencia clara en tecnología / tech ahora mismo, es esta.

5. El trabajo remoto está bajando

La proporción de roles remotos ha seguido cayendo. No cae en picada, ha tenido un leve aumento en los últimos meses, pero tendremos que esperar para ver una tendencia clara a cierres del año 2026. Pareciera que hemos llegado a una línea base. Un punto de equilibrio entre la oferta presencial vs remota.

6. ¿y LATAM?

Respecto a Latinoamérica, la proporción total de trabajos en tecnología apenas llega a 6,246 empleos vs 81,420 vacantes en Estados Unidos y Canadá, 50,854 ofertas en Asia y 30,246 en Europa.

Ofertas de por rol en tecnología LATAM (feb, 2026)

• Product Managers: 89 ofertas

• Ingenieros de software: 1,434 vacantes

• Diseño UX/UI: 120 ofertas

• IA: 706 ofertas

• Data: 313 vacantes

• QA: 39 vacantes

• Investigación: 24 ofertas

7. Los layoffs siguen ocurriendo

Aunque se esperaba que los layoffs disminuyeran durante 2025, la realidad es que se mantuvieron casi en el mismo nivel.

Durante 2025, 246k empleados en tecnología fueron despedidos o “dejados ir”. Solo llevamos 2 meses y ya han ocurrido 44k despidos. Lo que hace parecer que la tendencia es esperar al menos otras 220k personas despedidas durante 2026. Por lo que, en mi opinión se esperan aún más recortes.

En resumen

El mercado no está en crisis, pero tampoco es el mismo de antes. Hay más oportunidades, especialmente en AI. Algo importante también, es que las ofertas o vacantes en su mayoría están enfocadas en perfiles Senior y en ciertas herramientas o habilidades. Por lo que, si no dominas alguna en tu rol, es momento de comenzar a tomarte tiempo para educarte en ella.

En Latinoamérica hay una menor concentración en ofertas de trabajo, por lo que también es importante destacar el idioma inglés como ventaja competitiva, e incluso en algunos casos como un “Must have”.

No es momento de pánico — es momento de adaptarse y moverse con intención.

Fuentes consultadas:

Un gran agradecimiento nuevamente a TrueUp, de donde obtuve todos los datos e información relacionada con las vacantes en el mundo de la tecnología.

“El banco está mal.”

Y aunque a veces es cierto, culpar al banco es la forma más rápida de dejar de pensar como PM.

Un decline no es una respuesta binaria.
Es una señal.
Y casi nunca explica una sola cosa.

Si cada decline lo lees como “el banco bloqueó el pago”, te estás perdiendo el 80% del problema… y de las decisiones importantes.

Un decline es un síntoma, no un culpable

Antes de apuntar al emisor, un PM debería preguntarse:

• ¿En qué momento del flujo ocurrió el rechazo?

• ¿Es consistente por monto, canal, MCC, BIN o país?

• ¿Cambia según dispositivo, red o horario?

• ¿Afecta a nuevos usuarios o a recurrentes?

• ¿Es un patrón… o ruido?

Muchos declines no vienen de “un banco malo”, sino de:

• reglas de riesgo demasiado agresivas

• datos inconsistentes o mal formateados

• fricción innecesaria en autenticación

• decisiones internas que nadie volvió a cuestionar

El banco solo es una pieza más del sistema.

El error más común: analizar el decline aislado

Ver un código de rechazo y sacar conclusiones es cómodo, pero peligroso.

Un PM fuerte no pregunta:

“¿Por qué el banco rechazó esto?”

Pregunta:

“¿Qué está intentando proteger el sistema y por qué este pago parece sospechoso?”

Ahí cambia todo:

• Pasas de buscar culpables a entender incentivos

• De pelearte con partners a ajustar el producto

• De reaccionar a diseñar mejores decisiones

Leer declines es leer comportamiento

Un decline bien leído te habla de:

• confianza (o falta de ella)

• contexto del usuario

• fricciones ocultas

• deuda técnica disfrazada de “tema externo”

Y sí, a veces el banco falla.
Pero cuando todo es culpa del banco, normalmente el problema está en casa.

Pensar como PM en pagos no es saber códigos

Es saber interpretar señales incompletas y decidir con criterio.

Si quieres productos más robustos, empieza por dejar de preguntar
“¿quién falló?”
y empieza a preguntar
“¿qué me está diciendo el sistema?”

Ahí es donde se nota quién ejecuta…
y quién genera confianza.

Escrito por una PM Senior en Empresa TOP Fintech con experiencia en +50 millones de transacciones

Lees.
Escuchas podcasts.
Guardas frameworks.
Tomas notas.

Y aún así, cuando llega el momento de decidir, sientes que estás improvisando.

No porque te falte ganas.
Sino porque nadie te enseñó a construir criterio.

A casi todos nos tocó aprender así:
a punta de prueba, error y alguna que otra cicatriz profesional.

Hace tiempo empecé a preguntarme:

¿Cómo sería empezar en Producto si desde el día uno alguien te explicara las bases con claridad?

Sin humo.
Sin frases elegantes.
Sin teoría imposible de aplicar.

Solo entender:

• cómo piensa un buen PM

• por qué toma ciertas decisiones

• qué mira primero

• cómo se mueve cuando el terreno es gris

Así que me puse a trabajar en algo.

Preparé un curso de fundamentos de Product Management con el tipo de material que a mí me habría ahorrado años.

Tomé inspiración de programas tipo Harvard, revisé muchísimo contenido bueno que normalmente solo encuentras en inglés, y me dediqué a traducirlo, ordenarlo y aterrizarlo a la vida real.

A lo que pasa en el trabajo.
En las reuniones.
Con el equipo.
Con negocio.

La idea nunca fue hacerlo perfecto.

Fue hacerlo útil.

Y decidí algo importante:

👉 no quería que el acceso fuera una barrera.

Por eso el curso está disponible gratis dentro de la comunidad que estoy construyendo.

Un lugar donde, además del contenido, podamos conversar sobre Producto como realmente se vive.

Si estás intentando entrar al rol,
o si ya estás dentro pero sientes que te faltan bases firmes,

creo que te puede servir mucho.

Puedes acceder aquí:
👉 LINK

Si te ayuda aunque sea a evitar un par de errores que muchos cometimos al empezar, ya valió la pena haberlo construido.

Nos vemos dentro.

Hay una frase que escucho demasiado en reviews de pagos:

“Nuestra acceptance rate está baja, hay que hablar con el banco”.

Spoiler: muchas veces ni siquiera están hablando de la métrica correcta.

Authorization rate y acceptance rate no son sinónimos, aunque suenen parecido y ambos se vean “verdes o rojos” en el dashboard. Mezclarlas es uno de esos errores silenciosos que te delatan como PM poco senior.

Vamos por partes.

1️⃣ Authorization rate: ¿el banco dijo sí o no?

Authorization rate responde a una sola pregunta:

De todas las transacciones enviadas al banco,
¿cuántas fueron autorizadas?

Aquí el protagonista es el emisor (issuer):

• Fondos insuficientes

• Tarjeta bloqueada

• Sospecha de fraude

• Límites diarios

• Reglas internas del banco

Como PM, esto importa porque:

• No todo es “culpa del banco”

• No todo se arregla renegociando tasas

• Muchas decisiones antes del banco afectan este número

Ejemplo clásico:

Mandas transacciones duplicadas, con montos raros o sin datos suficientes.
El banco hace lo correcto: rechaza.

La authorization rate cae…
pero el problema empezó en tu producto.

2️⃣ Acceptance rate: ¿qué tan bien diseñas tu funnel de pago?

La acceptance rate mira el sistema completo, no solo al banco.

Normalmente incluye:

• Transacciones autorizadas

• Pagos correctamente capturados

• Flujos sin errores técnicos

• Reintentos bien hechos

Es una métrica más “incómoda”, porque:

• Expone decisiones de UX

• Expone lógica de reintentos

• Expone reglas antifraude demasiado agresivas

• Expone integraciones mal hechas

Dos equipos pueden tener la misma authorization rate
y acceptance rates totalmente distintas.

¿Por qué?
Porque uno sabe qué mandar, cuándo mandar y cuándo no insistir.

3️⃣ El error típico de PM junior

PM junior:

“El banco está rechazando mucho, hay que escalar”.

PM senior:

“¿Qué estamos mandando al banco, en qué contexto y con qué señal?”

La diferencia no es semántica.
Es responsabilidad sobre el sistema.

Un PM senior sabe que:

• Subir acceptance rate no siempre implica subir authorization rate

• A veces mejoras la conversión pagando menos rechazos inútiles

• A veces la mejor decisión es no enviar la transacción

Sí, no enviar también es una decisión de producto.

4️⃣ Preguntas que te hacen sonar senior (de verdad)

Si quieres elevar la conversación, cambia las frases:

❌ “¿Por qué baja la acceptance?”

• ✅ ¿Qué porcentaje de rechazos eran evitables?

• ✅ ¿Cuántos rechazos vienen de reglas nuestras vs del issuer?

• ✅ ¿Qué pasa en el primer intento vs el segundo?

• ✅ ¿Estamos castigando clientes buenos por miedo al fraude?

Esto cambia la discusión de:

“el banco no sirve”

a

“nuestro sistema está mal calibrado”.

5️⃣ La idea clave

Authorization rate mide al banco.
Acceptance rate te mide a ti como PM.

Confundirlas es normal.
No saber explicarlas no.

Y si estás liderando pagos, riesgo o conversión,
esa diferencia ya no es técnica:
es criterio.

Durante años, en producto hablamos de pagos como un problema de conversión.
Este estudio deja claro que en América Latina el problema ya es otro: control, velocidad y confianza.

Los pagos instantáneos (Pix, SPEI, Transferencias 3.0, Yape, Bre-B) ya no son “alternativa”. Están redefiniendo quién captura valor en el ecosistema.

Insight clave #1: el efectivo ya perdió — y la tarjeta también empieza a hacerlo

Según el estudio, los pagos digitales (wallets, QR, pagos en tiempo real) ya representan 60% del gasto del consumidor en LATAM.

Pero el dato interesante no es ese.

Lo importante es que los pagos cuenta a cuenta (A2A) están creciendo más rápido que las tarjetas, porque:

• liquidan en tiempo real

• reducen costos para el comercio

• eliminan intermediarios

Para un PM, esto no es UX.
Es estructura de negocio.

Insight clave #2: los países avanzan a velocidades muy distintas (y eso importa)

Fuente: PCMI Global E-Commerce Data Library

La gráfica de adopción A2A del estudio muestra algo incómodo:

• Chile, Argentina y Brasil ya operan en lógica A2A

• México va a mitad del camino

• Colombia aún está en transición

• Perú va a convertir A2A en dominante antes de 2030

Eso significa que copiar decisiones de pagos entre países es un error de junior.

El mismo método de pago no juega el mismo rol estratégico en cada mercado.

Insight clave #3: instantáneo ≠ simple (el fraude es el verdadero costo)

El estudio es muy claro en algo que muchos decks ignoran:

En pagos instantáneos, no hay marcha atrás.

Eso cambia completamente el riesgo:

• identidades sintéticas

• account takeover

• ingeniería social

Cuando el dinero se mueve en segundos, la prevención reemplaza al recovery.

Como PM, esto implica una decisión incómoda:

• o metes fricción antes

• o pagas fraude después

No es un trade-off técnico.
Es una decisión de producto.

Insight clave #4: pagos instantáneos cambian qué productos ganan

Los verticales que más se benefician no son sorpresa, pero sí la razón:

• Retail & e-commerce → cashflow inmediato

• Fintechs → adquisición + inclusión

• Gig economy → retención por liquidez

• Gaming → confianza vía retiros rápidos

• Gobierno → trazabilidad y reducción de fraude

El patrón es claro:
gana quien reduce el tiempo entre acción y recompensa.

Mi lectura como PM

Este estudio no dice “implementa pagos instantáneos”.

Dice algo más incómodo:

Si tu producto sigue optimizando solo checkout con tarjeta, estás peleando la guerra anterior.

La pregunta ya no es:

¿Qué método convierte más?

La pregunta real es:

¿Qué método redistribuye poder en mi producto?

Y esa es la diferencia entre ejecutar features y diseñar estrategia.

Fuentes

• Pagos instantáneos en América Latina: comprensión de oportunidades y riesgos — Jumio & Latam Fintech Hub, 2025 (checa el estudio)

• World Economic Forum (citado en el estudio)

• PCMI Global E-Commerce Data Library (gráfica A2A por país)

Descarga el estudio

Hay una frase que se repite en muchos equipos de producto:

“Tarjeta convierte más.”

Y sí. En muchos contextos es verdad.
Pero repetirla sin entender por qué —o cuándo deja de ser cierta— es una de las formas más rápidas de parecer junior, aunque lleves años en el rol.

Vamos por partes.

Por qué sí convierten más (la parte obvia… pero incompleta)

Los pagos con tarjeta suelen mejorar la conversión porque reducen fricción en tres niveles clave:

1. Cognitivo
El usuario no “piensa” el pago.
No calcula, no compara saldos, no abre otra app. Simplemente continúa.

2. Temporal
La decisión y la ejecución ocurren en el mismo momento.
No hay “luego lo hago”, que en la práctica suele significar nunca.

3. Emocional
La tarjeta desacopla el dolor del pago del momento del consumo.
Especialmente en compras impulsivas, digitales o de bajo monto.

Hasta aquí, todo bien.
Pero esto no es criterio. Es manual.

El error común de muchos PMs

El error no es usar tarjeta.
El error es asumir que más conversión siempre es mejor producto.

Porque conversión no es el único outcome que importa.

Y aquí es donde empiezan las malas decisiones.

Cuándo no deberías priorizar tarjeta (aunque convierta más)

1. Cuando el problema real no es pagar, sino confiar

En verticales donde hay riesgo percibido —fraude, contracargos, entregables intangibles, onboarding largo— la tarjeta puede cerrar el pago…
pero abrir problemas después.

Más disputas
Más soporte
Más churn silencioso

La conversión sube, pero la calidad del revenue baja.

2. Cuando el monto exige deliberación

Pagos altos + tarjeta = falsa victoria.

El usuario paga rápido…
y se arrepiente lento.

Aquí métodos como transferencias o wallets con saldo funcionan como filtro natural:
quien paga, está más convencido.

Menos conversión upfront.
Mejor retención downstream.

3. Cuando optimizas el funnel equivocado

He visto equipos obsesionados con subir el CVR del checkout
mientras ignoran:

• tasa de aprobación real

• costos por contracargo

• impacto en cashflow

• dependencia del adquirente

Tarjeta convierte más…
hasta que el negocio empieza a sangrar por otro lado.

El criterio que separa a un PM ejecutor de uno confiable

Un PM junior pregunta:

“¿Qué método convierte más?”

Un PM con criterio pregunta:

“¿Qué comportamiento estoy incentivando con este método de pago?”

Porque los métodos de pago no solo cierran transacciones.
Diseñan el tipo de cliente que atraes.

Entonces, ¿qué deberías hacer como PM?

No elegir el método ganador.
Elegir la combinación correcta según contexto:

• Tarjeta para rapidez y baja fricción

• Transferencia para intención fuerte

• Wallets para recurrencia y control

• Reglas claras para no mezclar señales

Y, sobre todo, explicar la decisión en términos de trade-offs, no de modas.

Eso es lo que genera confianza.
En tu equipo.
Y en quienes deciden si te dan más responsabilidad… o no.

Durante años, la biblia del Product Manager ha tenido un mandamiento sagrado: “Eliminarás los clics por sobre todas las cosas”.

Nos obsesionamos con el One-Click Checkout. Medimos el éxito por la velocidad con la que un usuario llega al botón de “Pagar”. Pero en la industria Fintech, seguir este dogma a ciegas es una forma muy eficiente de quebrar una empresa.

El mercado ha cambiado. Ya no estamos en la era del crecimiento a toda costa, sino en la era de la rentabilidad. Y en esta era, la fricción no siempre es el enemigo; a veces, es tu mejor aliada financiera.

La mentira del UX fluido

Si tu flujo de pago es tan suave que hasta un bot o un estafador con una base de datos robada pueden completarlo en 3 segundos, no tienes un producto “amigable”, tienes un producto vulnerable.

Cada transacción fraudulenta que dejas pasar por no “molestar” al usuario con un paso extra tiene un costo real:

1. El contracargo (Chargeback): Pierdes el producto o servicio.

2. La comisión operativa: El procesador te cobra igual.

3. La penalización de la red: Si tu tasa de fraude sube, Visa o Mastercard te ponen en la “lista negra”, aumentando tus costos de procesamiento para siempre.

¿Qué es la Fricción Rentable?

La Fricción Rentable es la introducción estratégica de pasos de verificación que filtran la calidad del usuario y la legitimidad de la transacción. No se trata de poner obstáculos por gusto, sino de optimizar el Margen de Contribución por encima de la Tasa de Conversión bruta.

Aquí es donde el PM deja de ser un diseñador de flujos y se convierte en un estratega de capital.

3 Escenarios donde la fricción “paga”

1. El umbral del High-Ticket No es lo mismo comprar un café que una laptop de $1,500 USD. Pedir una biometría facial o un segundo factor (2FA) en montos altos no solo previene fraude; curiosamente, genera confianza. El usuario de alto valor quiere sentir que su dinero está protegido. Aquí, la fricción aumenta el LTV.

2. El cambio de “Hardware Persona” Si un usuario que siempre transacciona desde un iPhone en CDMX de repente intenta pagar desde un dispositivo Android en otra ciudad, debes frenarlo. Introducir un paso de validación en este punto exacto salva miles de dólares en Account Takeover.

3. El “Step-up Authentication” dinámico La verdadera inteligencia de producto no es poner 3DS a todos, sino usar fricción dinámica. Si tu motor de riesgo detecta una señal sospechosa, lanzas el reto. Si no, dejas pasar. Esto es optimizar el ROI de cada clic.

El ROI de la seguridad: Menos es Más

Bajar tu tasa de fraude apenas un 0.5% puede impactar el EBITDA de una Fintech de manera más agresiva que duplicar el presupuesto de marketing. El marketing trae usuarios; la fricción rentable protege el dinero que esos usuarios generan.

Conclusión: El PM que sabe de dinero

El PM del futuro no busca el flujo más corto; busca el flujo más rentable. Si tu única métrica de éxito es la velocidad de conversión, estás viendo solo la mitad de la película. La otra mitad se cuenta en el estado de resultados (P&L).

Estoy convencida de que el equilibrio perfecto entre UX y Rentabilidad es la ventaja competitiva definitiva.

PD: Encontrar este punto de equilibrio es imposible si no ves tus métricas en tiempo real. Pronto compartiremos una herramienta diseñada específicamente para que dejes de adivinar dónde poner la fricción y empieces a medir su impacto en tu margen.

Y sin embargo, la mayoría de los negocios eligen así:

“Pon tarjeta porque todos usan tarjeta.”
“SPEI porque es más barato.”
“Wallet porque está de moda.”

Resultado:
– Margen erosionado
– Fricción innecesaria
– Clientes que abandonan sin que sepas por qué

La verdad incómoda es esta:
no existe el mejor método de pago universal.
Existe el método correcto para TU caso de uso.

El error común: pensar en pagos como un feature

Muchos PMs y founders ven los pagos como:

“Algo que tiene que funcionar.”

Pero los pagos son en realidad:

• Un driver de conversión

• Un centro de costos

• Un mecanismo de control de riesgo

• Un acelerador (o freno) del cash flow

Elegir mal el método de pago puede costarte más que una mala campaña de marketing.

Tarjeta: fricción mínima, costo máximo

Cuándo tiene sentido usar tarjeta

Tarjeta funciona mejor cuando:

• El cliente espera inmediatez

• El ticket es medio o bajo

• La experiencia importa más que el costo

• Hay recurrencia o pagos impulsivos

Ejemplos típicos:

• Ecommerce

• Suscripciones

• Apps B2C

• SaaS self-serve

Lo que casi nadie te dice

Tarjeta:

• Cobra fees visibles… y ocultos

• Introduce riesgo de:

  • Fraude

  • Chargebacks

  • Disputas

• Puede volverse inviable en márgenes pequeños

👉 Si tu margen es del 10% y tu fee total es 4–6%, ya estás jugando en contra.

SPEI: barato, poderoso… y mal usado

Cuándo SPEI es una ventaja real

SPEI brilla cuando:

• El ticket es alto

• El cliente no necesita confirmación instantánea

• Tu margen es sensible al fee

• Operas en México (clave)

Ejemplos:

• B2B

• Servicios profesionales

• Pagos únicos de alto valor

• Recargas, prepago, balance top-up

El gran error con SPEI

SPEI falla cuando:

• No confirmas en tiempo real

• No automatizas conciliación

• El usuario no sabe qué hacer después de pagar

Resultado típico:

“Ya pagué”
“No me aparece”
“Mándame el comprobante por WhatsApp”

👉 SPEI sin UX y backend sólido es fricción pura.

Wallets: menos pagos, más estrategia

Las wallets no son solo un método de pago.
Son una estrategia de retención.

Cuándo una wallet tiene sentido

Wallets funcionan cuando:

• Hay pagos frecuentes

• Quieres reducir fees por transacción

• Buscas lock-in del usuario

• Puedes justificar el saldo prepago

Ejemplos:

• Marketplaces

• Apps de movilidad

• Plataformas con consumo recurrente

• Ecosistemas cerrados

La verdad incómoda

Una wallet:

• Complica regulación

• Exige controles operativos

• Requiere volumen para valer la pena

👉 Si no tienes recurrencia real, una wallet es sobreingeniería.

Cómo elegir el método correcto (framework rápido)

Antes de elegir, responde esto:

1. ¿Quién paga?
   B2C impulsivo ≠ B2B racional

2. ¿Cuánto paga?
   $200 ≠ $20,000

3. ¿Cada cuánto paga?
   Una vez ≠ todos los meses

4. ¿Qué duele más?
   – Fee
   – Fricción
   – Riesgo
   – Operación

5. ¿Qué puedes automatizar hoy?
   El mejor método mal operado es el peor.

Spoiler de PM: casi nunca es uno solo

Los productos maduros no eligen un método.
Diseñan una estrategia de pagos:

• Tarjeta para conversión

• SPEI para eficiencia

• Wallet para retención

El error no es ofrecer varios métodos.
El error es no saber para qué sirve cada uno.

Cierre

Pagos no es “infraestructura invisible”.
Es palanca de negocio.

Si estás eligiendo métodos de pago solo por costo o moda,
ya estás perdiendo dinero…
solo que aún no lo ves en el dashboard.

Payments no es solo “un feature más”: es un sistema complejo, con impacto directo en ingresos, riesgo, experiencia de usuario y operación.

En este artículo te explico qué hace un Product Manager Payments, qué habilidades necesita y cómo empezar si hoy eres un PM generalista.

¿Qué es un Product Manager Payments?

Un Product Manager Payments es responsable de diseñar, optimizar y escalar la forma en que un producto cobra, procesa y gestiona pagos.

Su trabajo va mucho más allá del checkout.

Normalmente involucra:

• Flujos de pago (online y/o físicos)

• Integraciones con proveedores de pago

• Manejo de fallos, rechazos y conciliaciones

• Optimización de conversión y costos

• Cumplimiento regulatorio y riesgo

Es un rol altamente transversal, donde producto se cruza con ingeniería, legal, finanzas y operaciones.

¿Qué hace un Product Manager Payments en el día a día?

Aunque varía según la empresa, un PM de pagos suele trabajar en:

1. Experiencia de pago

• Diseñar flujos de checkout claros y confiables

• Reducir fricción sin comprometer seguridad

• Manejar escenarios de error y recuperación

2. Métricas e impacto en negocio

• Tasa de aprobación

• Conversión en pagos

• Costos por transacción

• Impacto en ingresos y churn

En payments, una pequeña mejora puede tener impacto directo en revenue.

3. Integraciones y ecosistema

Un Product Manager Payments no “programa”, pero sí debe entender:

• Cómo funcionan los PSPs (payment service providers)

• Diferencias entre tarjetas, transferencias, wallets, etc.

• Qué implica agregar o cambiar un proveedor de pago

4. Riesgo y cumplimiento

Dependiendo del contexto:

• Prevención de fraude

• Cumplimiento regulatorio

• Manejo de disputas y contracargos

Aquí es donde muchos PMs se sienten inseguros, porque no es conocimiento tradicional de producto.

Habilidades clave de un Product Manager Payments

Este rol no se basa solo en frameworks genéricos de producto.

Algunas habilidades clave son:

• Pensamiento sistémico

• Capacidad de entender flujos end-to-end

• Comodidad con conceptos técnicos y financieros

• Toma de decisiones basada en métricas

• Comunicación clara con equipos técnicos y no técnicos

No necesitas saberlo todo desde el inicio, pero sí saber qué aprender y en qué orden.

¿Cómo pasar de PM generalista a Product Manager Payments?

Uno de los errores más comunes es intentar aprender todo al mismo tiempo:

• regulación

• fraude

• tarjetas

• transferencias

• wallets

• adquirentes

• emisores

Eso genera parálisis.

Una mejor aproximación es:

1. Entender el ecosistema general de pagos

2. Aprender los conceptos base que más se repiten

3. Profundizar según el tipo de empresa (fintech, SaaS, marketplace)

4. Construir criterio práctico, no solo teoría

Tener un roadmap claro marca una diferencia enorme.

¿Vale la pena especializarse como Product Manager Payments?

Para muchos PMs, sí.

Payments suele ofrecer:

• Alta demanda

• Roles bien valorados

• Impacto directo en negocio

• Aprendizaje profundo y transferible

Eso sí: no es un rol “ligero”. Requiere paciencia, curiosidad y ganas de entender sistemas complejos.

Cómo empezar de forma estructurada

Si te interesa este camino, lo más importante no es consumir más contenido, sino seguir una ruta clara.

Por eso armé un roadmap práctico para Product Managers que quieren entrar al mundo de pagos, enfocado en:

• qué aprender

• en qué orden

• con foco en carrera y aplicación real

Si te ha gustadi este artículo, deja tus comentarios por acá 👇🏻: