Un pago transfronterizo (o cross-border payment) es cualquier pago en el que quien envía y quien recibe están en países distintos. Puede ser una remesa, una compra en una tienda en línea extranjera o una empresa pagándole a un proveedor en otro país.

Suena sencillo: mandas dinero de aquí para allá. Pero en cuanto el dinero cruza una frontera, se vuelve más caro, más lento y mucho más complicado. ¿Por qué? ¿Quién se queda con la comisión? ¿Y qué decide un PM detrás de todo esto? Ahora sí, vamos por partes.

1. El caso: los $397 dólares de Don Jorge

Don Jorge trabaja en Chicago y cada mes le manda dinero a su mamá en Michoacán. No es un caso raro: en 2025 México recibió 61,791 millones de dólares en remesas, 4.6% menos que en 2024, con un envío promedio de 397 dólares. De hecho, según el Banco Mundial, México es el segundo país que más remesas recibe en el mundo, solo detrás de India.

Don Jorge abre su app, escribe el monto y en unos minutos su mamá recibe pesos. Para él fue un clic. Para el sistema fue un viaje con varias escalas.

2. ¿Cuáles son los tipos de pagos transfronterizos?

• Persona a persona (P2P): remesas como la de Don Jorge.

• Persona a negocio (P2B): cuando compras en una tienda de otro país con tu tarjeta.

• Negocio a negocio (B2B): una empresa que paga a proveedores o recibe pagos de clientes en el extranjero.

• Mayoristas: los pagos entre bancos e instituciones financieras, por montos enormes.

3. ¿Cómo funciona un pago transfronterizo, paso a paso?

Paso 1. El envío. Don Jorge manda el dinero desde su cuenta, tarjeta o en efectivo. Antes de que se mueva un solo dólar, el proveedor verifica quién es (KYC) y revisa que no esté en listas de sanciones ni haya señales de lavado de dinero (AML).

Paso 2. El cambio de moneda. Los dólares se convierten a pesos. Aquí vive uno de los costos más escondidos: el spread, la diferencia entre el tipo de cambio real y el que te dan. Muchas veces la comisión dice “$0”, pero el tipo de cambio te cobra por debajo de la mesa.

Paso 3. El viaje. El dinero puede tomar distintos caminos:

• Banca corresponsal: el camino tradicional. Los bancos tienen cuentas unos con otros en distintos países y se envían instrucciones por SWIFT. Ojo: SWIFT no mueve dinero, solo mensajes. Y si hay varios bancos intermediarios, cada uno puede cobrar su parte.

• Redes de remesadoras y fintechs: tienen dinero prefondeado (depositado por adelantado) en ambos países. Don Jorge paga en Estados Unidos y la fintech le paga a su mamá con dinero que ya tenía en México. El dinero en realidad no cruza en ese momento; se compensa después.

• Nuevas alternativas: conexiones entre sistemas de pagos inmediatos de distintos países y el uso de stablecoins están empezando a cambiar las reglas.

Paso 4. La última milla. La mamá de Don Jorge recibe el dinero en su cuenta (en México, normalmente vía SPEI), en una wallet o en efectivo en una tienda. Y no es un detalle menor: en 2025, el 99.1% de las remesas llegó por transferencia electrónica, pero casi la mitad (49.6%) se cobró en efectivo.

4. ¿Por qué son caros y lentos los pagos transfronterizos?

• Muchos intermediarios, y cada uno cobra.

• Cambio de moneda, con spreads poco transparentes.

• Cumplimiento regulatorio en dos o más países, cada uno con sus propias reglas.

• Horarios y husos horarios distintos: si el sistema de un país está cerrado, el pago espera.

• Capital atrapado: prefondear cuentas en varios países cuesta dinero.

Tan es así que el G20 se puso metas para mejorar esto, pero no van bien. La meta es que el costo promedio global no supere el 1% para 2027, pero en 2025 mandar $1,000 dólares de persona a persona seguía costando alrededor de 2.6%, igual que en 2023. El propio Consejo de Estabilidad Financiera reconoce que es poco probable alcanzar mejoras satisfactorias a nivel global en los tiempos de 2027.

Y a esto súmale la regulación: desde el 1 de enero de 2026, las remesas enviadas desde Estados Unidos pagadas en efectivo, money orders o cheque de caja pagan un impuesto de 1%; las que salen de una cuenta bancaria o tarjeta quedan exentas.

5. ¿Qué decide un PM en un producto de pagos transfronterizos?

Aquí viene lo bueno. Detrás de ese clic de Don Jorge hay muchas decisiones de producto:

Qué camino usar para mover el dinero. Banca corresponsal es más simple de arrancar, pero más lenta y cara. Prefondear es más rápido, pero amarra capital. Velocidad contra costo, el trade-off de siempre.

1. Cómo cobrar y qué tan transparente ser. ¿Comisión fija, spread en el tipo de cambio o las dos? Mostrar el costo total desde el inicio genera confianza, pero también te compara directo con la competencia.

2. Cuánta fricción poner en cumplimiento. Pedir más datos reduce riesgo, pero si el registro es eterno, Don Jorge se va con otra app. En pagos transfronterizos el cumplimiento no es opcional: una falla puede costar multas o la operación completa.

3. Qué opciones de última milla ofrecer. Si casi la mitad de las remesas se cobra en efectivo, quitar esa opción puede dejar fuera a muchísimos usuarios, aunque lo digital sea más barato.

6. El aprendizaje para cualquier PM

Un pago transfronterizo nos recuerda algo que aplica a cualquier producto: lo que el usuario ve es solo la punta del iceberg. La app de Don Jorge puede ser hermosa, pero si el tipo de cambio es malo, el dinero tarda tres días o su mamá no puede cobrarlo cerca de casa, el producto falla.

En mi opinión, un buen PM de pagos no diseña pantallas, diseña el camino completo del dinero y decide conscientemente dónde gana y dónde cede.

🧠 Ejercicio para ti

Imagina que eres PM de una app de remesas entre Estados Unidos y México. Tu dirección quiere bajar costos eliminando el cobro en efectivo y dejando solo depósitos a cuenta.

¿Qué datos pedirías antes de decidir? ¿A qué usuarios afectaría más? ¿Qué harías para no perderlos? Cuéntame tu respuesta en los comentarios.

Preguntas frecuentes sobre pagos transfronterizos

¿Qué es un pago transfronterizo?
Es un pago en el que quien envía y quien recibe están en países diferentes, como una remesa, una compra internacional o un pago a un proveedor extranjero.

¿Cuál es la diferencia entre SWIFT y un pago transfronterizo?
SWIFT es una red de mensajería entre bancos: envía las instrucciones del pago, pero no mueve el dinero. El pago transfronterizo es la operación completa.

¿Por qué tarda días un pago internacional?
Por los intermediarios, la conversión de moneda, las revisiones de cumplimiento y los horarios distintos de los sistemas de pago de cada país.

¿Qué es el spread en un pago internacional?
Es la diferencia entre el tipo de cambio real y el que te aplica el proveedor. Es un costo que muchas veces no aparece como “comisión”.

¿Las remesas a México pagan impuesto en 2026?
Desde enero de 2026, Estados Unidos cobra 1% a las remesas pagadas en efectivo, money order o cheque de caja. Las enviadas desde cuenta bancaria o tarjeta están exentas.

En resumen

Un pago transfronterizo parece un clic, pero es una cadena de intermediarios, conversiones, reglas y decisiones. Y en cada eslabón hay un PM balanceando velocidad, costo, cumplimiento y experiencia.

El dinero no viaja solo: viaja por el camino que alguien decidió diseñar.

¿Quieres saber qué tanto sabes de pagos? Haz mi test de habilidades para Payments PM: Construí un Payments PM Skills Assessment.

Si conoces a alguien que está entrando al mundo de pagos o fintech, compártele este post. Y si todavía no te suscribes, ¿qué esperas? 😉

Suscríbete ahora

Sources:

• FSB: G20 Roadmap consolidated progress report 2025

• The Paypers: Understanding the G20 cross-border payments targets

• Municipios Puebla: Banxico confirma caída de remesas

• UDG TV: Remesas en México 2025 caen según Banxico

• BBVA Research: 2026 inicia con el nuevo impuesto a las remesas

👋 Hola !, Soy Zaira Zatarain y aquí te comparto lo que voy aprendiendo sobre Producto, tecnología e IA.

Puedes saberte todos los frameworks, dominar Jira, Amplitude y Figma, y aun así quedarte en blanco con una sola pregunta de entrevista. ¿Por qué? Porque esa pregunta no mide herramientas, mide criterio.

¿Y qué es el criterio? Es ese “algo” que te dice por dónde va la respuesta correcta, incluso cuando no tienes toda la información. Mira, te lo cuento.

1. La pregunta

Parece sencilla, ¿verdad? Las tres suenan importantes y las tres tienen a alguien pidiéndolas. Justo ahí está la trampa.

2. La respuesta mala

“Usaría RICE para priorizar, haría una encuesta a los usuarios y elegiría el onboarding, porque el usuario siempre es primero.”

¿Qué tiene de malo? En papel, nada. Menciona un framework, habla de usuarios y suena muy “de producto”.

Pero fíjate: decidió sin un solo dato. Eligió la iniciativa que suena más bonita, y el framework está de adorno. “Los usuarios dicen que es largo” es una queja, no un problema cuantificado. ¿Cuántos abandonan? ¿Cuánto nos cuesta? Nadie sabe.

3. La respuesta buena

“Antes de decidir, necesito algunos datos: cuántos usuarios abandonan el onboarding, cuál es nuestra tasa de rechazo de pagos y cuánto tiempo y errores le cuesta hoy a operaciones conciliar a mano.

Con esa información, estimaría el impacto de cada una. Por ejemplo, si procesamos 100,000 intentos de pago al mes con un ticket promedio de $1,000 y rechazamos el 12%, estamos dejando pasar $12 millones al mes. Si integramos wallets como Apple Pay o Google Pay, que suelen tener mejores tasas de aprobación, y recuperamos aunque sea 2 puntos, son $2 millones al mes.

El onboarding podría ganar si los datos muestran un abandono alto en un paso específico, pero hoy solo tenemos una queja. Y la herramienta interna ahorra horas, pero habría que ver si los errores de conciliación nos están haciendo perder dinero o poniendo en riesgo alguna auditoría.

Con lo que sé, priorizaría los pagos rechazados, empezando por wallets. Mediría el éxito con la tasa de aprobación y el monto recuperado al mes.”

¿Notas la diferencia? No es que sepa más herramientas. Es que sabe hacia dónde mirar.

4. La regla de oro: sigue el dinero

En fintech, y en casi cualquier negocio, la respuesta correcta suele ser la que nos lleva a ganar más dinero o a perder menos dinero. Suena frío, pero tiene todo el sentido: son negocios basados en finanzas.

Ojo, esto no significa que el usuario no importe. Significa que el usuario es el camino al dinero, no algo que compite con él. El PM con criterio traduce el dolor del usuario a impacto de negocio: “los usuarios se quejan de rechazos” se convierte en “estamos perdiendo $12 millones al mes”.

5. Lo que tiene una respuesta con criterio

• Pregunta antes de responder. Pide contexto: volumen, métricas actuales, restricciones. Decidir sin datos es opinar.

• Estima, aunque sea en servilleta. No necesitas el número exacto, pero sí el orden de magnitud. Eso separa una opinión de una decisión.

• Considera el riesgo. En fintech, perder dinero también puede ser una multa, una auditoría fallida o poner en riesgo la operación. A veces lo prioritario no es lo que más gana, sino lo que evita perder el negocio.

• Piensa en el costo de oportunidad. Elegir una iniciativa es decirle que no a las otras dos. El impacto siempre se compara contra el esfuerzo y contra lo que dejas de hacer.

• Usa frameworks como medio, no como respuesta. RICE te ayuda a ordenar ideas, pero no decide por ti. La herramienta no tiene criterio, tú sí.

• Cierra con la métrica de éxito. Decir cómo sabrás que funcionó demuestra que piensas en resultados, no en entregables.

En resumen

Las herramientas se aprenden en un curso. El criterio se construye entendiendo el negocio, preguntando antes de decidir y siguiendo el dinero.

La próxima vez que te hagan una pregunta de priorización, no busques la respuesta que suena bonita. Busca la que puedes defender con números. Porque en producto, lo que no puedes cuantificar, no lo puedes priorizar.

¿Quieres saber qué tanto sabes de pagos? Haz mi test de habilidades para Payments PM y descúbrelo: Construí un Payments PM Skills Assessment.

Si conoces a alguien que se está preparando para entrevistas de producto, compártele este post. Y si todavía no te suscribes, ¿qué esperas? 😉

Compartir

👋 Hola!, Soy Zaira Zatarain y aquí te comparto lo que voy aprendiendo sobre Producto, tecnología e IA.

Pagas tu café con tarjeta, esperas un par de segundos y listo: “Aprobado”. Parece magia, pero en esos 2 segundos tu pago viajó por al menos cinco empresas distintas, pasó por revisiones de fraude y alguien decidió si confiaba en ti o no.

¿Quiénes participan? ¿Qué pasa en cada paso? ¿Y qué tiene que ver un Product Manager con todo esto? Ahora sí, vamos por partes.

Primero, los personajes

Antes de entrar al flujo, conoce a quienes participan (spoiler: son más de los que crees):

• Tarjetahabiente: tú, con antojo de café.

• Comercio: la cafetería, o la tienda en línea.

• Pasarela de pagos (gateway): la puerta de entrada que recibe los datos de la tarjeta de forma segura.

• Procesador y adquirente: el banco o empresa que trabaja del lado del comercio y le paga.

• Red o marca: Visa, Mastercard o American Express. Son la carretera por donde viaja la información.

• Emisor: el banco que te dio la tarjeta y que decide si aprueba o no.

1. El checkout: donde todo empieza

Qué pasa: ingresas los datos de tu tarjeta o eliges una guardada. La pasarela los recibe y los tokeniza, o sea, cambia el número real por un código que no sirve si alguien lo roba.

Qué decide el PM: qué métodos de pago ofrecer, cuántos pasos tiene el checkout y si se guardan tarjetas para la próxima. Cada campo extra es una oportunidad para que el usuario se arrepienta, así que aquí se juega mucha conversión.

2. La revisión de fraude

Qué pasa: antes de salir a la red, el pago pasa por reglas y modelos que evalúan el riesgo. ¿El usuario compró desde otro país hace 5 minutos? ¿Es un monto muy raro para su perfil?

Qué decide el PM: qué tan estrictas son las reglas y cuándo pedir autenticación extra, como 3D Secure (ese código que te llega por SMS o a tu app del banco). Aquí está uno de los trade-offs más importantes en pagos: más seguridad significa más fricción, y más fricción significa menos ventas. Si bloqueas de más, pierdes clientes buenos. Si bloqueas de menos, pagas el fraude.

3. El viaje por la red

Qué pasa: el adquirente envía la solicitud de autorización a la red (Visa, Mastercard, etc.), y la red la enruta al banco emisor de tu tarjeta.

Qué decide el PM: con qué adquirentes trabajar y cómo enrutar cada pago. Hay empresas que usan varios adquirentes y mandan cada transacción por el camino con mejor tasa de aprobación o menor costo. A esto se le llama orquestación de pagos, y es todo un mundo.

4. El emisor decide

Qué pasa: tu banco revisa si tienes saldo o línea disponible, si la tarjeta está activa y si el pago le parece sospechoso. Luego responde con un código: aprobado, rechazado por fondos insuficientes, por sospecha de fraude, etc.

Qué decide el PM: el emisor no está en sus manos, pero sí qué hacer con la respuesta. ¿Reintentar el cobro? ¿Cuándo? ¿Qué mensaje ver el usuario? No es lo mismo “Tu pago fue rechazado” que “Tu banco rechazó el pago, prueba con otra tarjeta”. Un buen manejo de rechazos puede recuperar muchas ventas.

5. La respuesta regresa

Qué pasa: la respuesta hace el camino de vuelta: emisor, red, adquirente, pasarela, comercio. Y tú ves “Aprobado”. Todo esto en uno o dos segundos.

Qué decide el PM: qué pasa si la respuesta tarda o nunca llega (sí, pasa). ¿Se cancela? ¿Se consulta el estatus? Aquí se definen los timeouts y cómo evitar cobros duplicados, que son de las quejas que más duelen.

6. Plot twist: el pago todavía no termina

Aquí viene lo interesante: lo que pasó en esos 2 segundos fue una autorización, no el cobro final. El dinero todavía no se mueve.

Qué pasa después:

• Captura: el comercio confirma que sí quiere cobrar. A veces es inmediata y otras se hace después, como en los hoteles que “apartan” un monto.

• Compensación y liquidación: en los días siguientes, los bancos intercambian la información y el dinero llega al comercio, ya con las comisiones descontadas.

• Conciliación: el comercio verifica que lo que le pagaron cuadre con lo que vendió.

Qué decide el PM: cuándo capturar, cómo conciliar sin volverse loco en Excel y cómo mostrarle al comercio cuándo le llega su dinero.

7. El después: reembolsos y contracargos

Qué pasa: a veces el cliente pide su dinero de regreso. Si lo pide al comercio, es un reembolso. Si lo pide directamente a su banco porque no reconoce el cargo o no recibió su producto, es un contracargo, y ahí el comercio tiene que demostrar que el cobro fue legítimo.

Qué decide el PM: cómo automatizar reembolsos, qué evidencia guardar para defender contracargos y cómo detectar patrones de abuso. Los contracargos cuestan dinero, tiempo y, si se acumulan, hasta la relación con la red.

Las métricas que un PM de pagos no pierde de vista

• Tasa de aprobación: de cada 100 intentos de pago, cuántos se aprueban.

• Tasa de fraude: cuánto se pierde por pagos fraudulentos.

• Tasa de contracargos: cuántos pagos terminan en disputa.

• Costo por transacción: cuánto se paga en comisiones.

• Latencia: cuánto tarda la respuesta. Nadie quiere esperar 10 segundos con la fila atrás.

En resumen

Un pago con tarjeta parece un solo clic, pero es una cadena de decisiones entre muchas empresas. Y en casi cada eslabón hay un PM decidiendo entre conversión, seguridad, costo y experiencia.

Si estás empezando en fintech o en pagos, mi consejo es que no te quedes con la pantalla de “Aprobado”. Dibuja el flujo completo, entiende quién participa en cada paso y pregúntate qué pasa cuando algo falla. Porque en pagos, el diseño no está en el camino feliz, está en todo lo que puede salir mal.

La próxima vez que pagues tu café, ya sabes todo lo que pasó en esos 2 segundos. ☕

Si conoces a alguien que está entrando al mundo de pagos o fintech, compártele este post. Y si todavía no te suscribes, ¿qué esperas?

Compartir 🌀 TPP - The Pro Producto

Si hace 15 años me hubieran dicho que iba a trabajar en una fintech, entre pagos, contracargos y prevención de lavado de dinero, me hubiera quedado sin palabras. Yo iba para el gobierno.

Hoy soy Sr. Product Manager en una Top Fintech mexicana, y no llegué de un salto: llegué a pasitos.

¿Se puede llegar a Producto sin venir de ingeniería? ¿Sin haber escuchado la palabra backlog en la universidad? Aquí te cuento cómo le hice yo. Vamos por partes.

Todo empezó resolviendo problemas (públicos)

Estudié Administración Gubernamental y Políticas Públicas Locales en la Universidad de Guadalajara. Fui de la segunda generación de la carrera, donde lo que se esperaba era que trabajaras en gobierno al salir.

Las políticas públicas son, en pocas palabras, la ciencia de resolver problemas públicos. Así que desde ahí ya me gustaba estar metida en problemas y buscarles solución (los públicos, los personales ya son otro tema).

Después hice una maestría en Gestión y Generación de la Innovación, y la semillita creció todavía más, porque innovar va muy de la mano de buscar soluciones, solo que de formas nuevas.

1. Aprender a ordenar el caos (2010)

Mi primer trabajo fue en la universidad, en el equipo de asesores del Rector General. Ahí aprendí algo que uso todos los días: analizar, investigar y organizar información.

Luego me invitaron a un proyecto de la universidad con el gobierno federal, donde lideré el equipo de documentación. Escribir y comunicar siempre ha sido lo mío, y ese proyecto me lo confirmó.

2. De project manager a product owner (2014)

Después llegó la invitación a ser project manager en un proyecto donde construíamos sistemas de gestión para administrar grandes volúmenes de información.

Ahí todo hizo clic: la tecnología se volvió la herramienta perfecta para lo que siempre me había gustado, resolver problemas, pero a escala.

Con el tiempo empezamos a trabajar con Scrum y tomé el rol de product owner en la creación de un CRM a la medida.

Y ahí, al paso de las semanas, me cayó el veinte: si iba a darles requerimientos a los ingenieros, tenía que entender su idioma. Así que me puse a tomar cursos de Java, PHP, HTML y CSS. No para volverme developer, sino para saber qué estaba pidiendo y por qué algo “sencillito” a veces no era tan inmediato.

3. El día que LinkedIn le puso nombre a lo que hacía

Un día, scrolleando en LinkedIn, me topé con el concepto de product manager. Y puff, se me iluminó el mundo.

Resulta que yo no solo gestionaba el proyecto ni solo definía tareas para desarrollo. También veía la parte estratégica: qué necesitaban los usuarios y cómo resolver necesidades internas con automatizaciones. Ya hacía producto, solo que no sabía que se llamaba así.

Me puse a investigar y, en aquellos años, la información de producto más a la vanguardia estaba prácticamente solo en inglés. De ahí nació mi misión: compartir conocimiento global y cerrar la brecha de acceso a información sobre producto en español.

4. Construir desde cero en la SEP (2019)

Luego llegué a la Secretaría de Educación Pública como subdirectora de tecnología, donde teníamos varios sistemas que se construyeron desde cero.

El título decía “subdirectora”, pero en la práctica hacía producto: me entrevistaba con usuarios para entender sus necesidades, definía requerimientos, acompañaba el desarrollo con el equipo técnico, lanzábamos y medíamos cómo funcionaba para volver a mejorar. El ciclo de producto completo, aunque nadie le llamara así.

5. Predial, cuentas contables y el arte de decir “sí, pero no así” (2021)

Después me invitaron a mi primera empresa privada, una compañía que construía un producto para controlar cobros de predial (y otros) en municipios. Mi experiencia en el sector público fue clave para llegar ahí.

Todo el sistema estaba hecho a la medida, así que mi reto era lograr que funcionara para otros clientes también. Si alguna vez te ha tocado decirle a un cliente “sí, pero no así”, sabes de lo que hablo.

Ahí aprendí muchísimo de cuentas contables y a pensar mucho en la experiencia del cliente. Sin saberlo, me estaba preparando para lo que venía.

6. El salto a fintech (2021)

Ese mismo año llegué a Mobilender, mi primera fintech. ¿Qué les llamó la atención? Una combinación rara pero poderosa: mi background contable de la carrera, lo que aprendí en el producto anterior, y mi experiencia con equipos de desarrollo y conocimiento técnico.

Lo más difícil fue entender la Importancia del KYC (Know Your Customer, o sea, cómo verificar quién es tu cliente). Es un mundo muy específico, con sus propias reglas, y es uno de los pilares de cualquier fintech. Si no lo entiendes, no entiendes el negocio.

7. Las oportunidades traen cambios y aprendizajes (2022–hoy)

Llevo más de 4 años en el equipo Kueski, y me he quedado porque ha sido una oportunidad enorme de aprender y crecer (además de que es una de las mejores compañías en México, justo hoy Kueski ha sido reconocida como el 3er lugar en el 𝗥𝗮𝗻𝗸𝗶𝗻𝗴 𝗱𝗲 𝗘́𝘁𝗶𝗰𝗮 𝗱𝗲 𝗘𝗺𝗽𝗿𝗲𝘀𝗮𝘀 𝗺𝗮́𝘀 𝗘́𝘁𝗶𝗰𝗮𝘀® 𝟮𝟬𝟮𝟲!

Kueski cuenta con dos productos financieros crédito personal y un BNPL (compra ahora, paga después). En cualquier producto de crédito, hay muchas piezas moviéndose al mismo tiempo, y me ha tocado definir producto en varias: pagos, contracargos, reembolsos, dispersiones, compliance y PLD (prevención de lavado de dinero), entre otros.

Y aquí viene lo curioso: empecé estudiando cómo resolver problemas públicos y terminé haciendo producto para cumplir con la regulación. Cerré el círculo sin darme cuenta.

Lo que aprendí por mi cuenta (que fue casi todo)

En su momento en 2018 hice la certificación de PMP (Project Management Professional del Product Management Institute) asi como me certifiqué en Scrum como Product Owner en 2019.

Pero, en mi opinión, lo que más me ha redituado es aprender por mi cuenta. Me fui armando mi propio plan de estudios con cursos de Platzi, Exponent, Product School, Mind the Product y Hustle Badger, entre otros, muchos de ellos en inglés. Y ahora con la IA, ser autodidacta se volvió casi obligatorio: cursos, pruebas, errores y más cursos.

En resumen

No hubo un momento mágico en el que decidí “voy a ser Product Manager”. Hubo una serie de pasos donde cada trabajo me dio una pieza: resolver problemas, ordenar información, entender a los ingenieros, pensar en el cliente, aprender de contabilidad, de flujos, procesos, autorizaciones, etc.

Por lo que, si estás pensando en moverte a Producto o a fintech, estos son los consejos que me hubiera gustado escuchar antes:

• Entiende de ingeniería. No necesitas programar, pero saber cómo funciona la parte técnica te da muchísima ventaja.

• Entiende el contexto de tu industria. En fintech, por ejemplo, tienes que hablar de riesgo, fraude, compliance y pagos. El producto no vive aislado de su negocio.

• Trabaja tu inteligencia emocional. Los stakeholders son personas, y un porcentaje importante del trabajo es entenderlos y negociar con ellos.

• Organízate como si tu vida dependiera de ello. Un PM a veces tiene 40 frentes abiertos, y sin orden te pierdes en el segundo.

• Pon al cliente al frente. No olvides que construir un producto es para resolver un problema que “alguien tiene” y ese alguien es el cliente.

Y sobre todo, revisa lo que ya haces. Es probable que ya tengas más experiencia de producto de la que crees, solo que con otro nombre.

Si conoces a alguien que está pensando en moverse a Producto o a fintech, compártele este post y dile que se suscriba. Y si todavía no te suscribes TU, ¿qué esperas? 😉

Una de las cosas que más me ha costado de la maternidad es aceptar que un buen plan no necesariamente hace que las cosas salgan como esperabas.

Antes de tener a la bebé, hacer planes era bastante sencillo. Si quería salir un sábado, decidía a dónde ir, a qué hora salir y cuánto tiempo quería estar fuera. Había imprevistos, claro, pero normalmente podía resolverlos sobre la marcha sin que cambiaran demasiado el día.

Ahora hasta algo tan sencillo como salir el fin de semana requiere un poco más de planeación. Hay que considerar horarios de comida, siestas, cuánto tiempo llevamos fuera, qué llevamos en la pañalera y qué tan lejos estamos de casa. Y aun haciendo todo eso, muchas veces el día no sale como lo imaginé. La bebé puede dormir más de lo esperado o no dormir nada. Puede tener hambre antes de tiempo. Podemos estar muy a gusto en algún lugar y de pronto decidir que ya fue suficiente.

Durante un tiempo, mi reacción era intentar hacer que el plan volviera a funcionar. Si algo se movía, trataba de acomodar lo demás para regresar al horario que había pensado originalmente.

Hasta que empecé a entender que quizá el problema no era el plan. Era que estaba esperando que la realidad se adaptara a él.

Y eso me hizo pensar mucho en cómo hacemos planes en el trabajo.

Como Product Managers nos gusta tener claridad. Construimos roadmaps, priorizamos iniciativas, definimos fechas y tratamos de anticipar dependencias. Todo eso es necesario. El problema aparece cuando empezamos a tratar ese plan como si fuera una predicción de lo que necesariamente va a ocurrir.

En producto sabemos que eso no funciona así. Mientras ejecutamos aparecen nuevas necesidades de clientes, cambian las prioridades del negocio, descubrimos restricciones técnicas y aprendemos cosas que simplemente no podíamos saber cuando construimos el roadmap. La realidad nos da información nueva todo el tiempo.

Por eso cada vez me hace más sentido pensar que un buen plan no es el que intenta contemplar absolutamente todo. Es el que tiene suficiente estructura para orientarnos y suficiente espacio para adaptarse.

Y esto no aplica solamente a un roadmap. Creo que aplica a casi cualquier cosa que diseñamos como PMs: procesos, proyectos, experimentos, equipos e incluso nuestras propias formas de trabajar.

Cuatro formas de diseñar para la adaptabilidad

1. Define primero qué quieres conseguir. Cuando tienes claro el resultado, puedes cambiar la ruta sin perder la dirección. Un roadmap que dice “reducir el abandono en el proceso de pago” deja mucho más espacio para aprender y cambiar que uno que simplemente dice “construir funcionalidad X”. La solución que imaginamos hoy puede no ser la que terminemos construyendo después de hablar con clientes.

2. No utilices el 100% de tu capacidad. Dejar espacio no significa que no tengas trabajo suficiente. Significa reconocer que van a aparecer cosas que todavía no conoces. Si todo el equipo está comprometido al límite, cualquier imprevisto se convierte en una crisis. Un poco de capacidad disponible puede ser justamente lo que permite absorber un cambio sin tener que deshacer todo lo demás.

3. Define cuándo vas a volver a evaluar tus decisiones. No todo tiene que quedar decidido desde el principio. Algunas iniciativas necesitan primero investigación, un experimento o conversaciones con clientes. En lugar de convertirlas inmediatamente en compromisos, puedes definir qué necesitas aprender y cuándo volverás a tomar la decisión. Así el roadmap se convierte menos en una lista de promesas y más en una herramienta para tomar decisiones.

4. Separa lo que no puede cambiar de lo que sí. No todo tiene el mismo nivel de flexibilidad. Puede haber un objetivo que no cambia, una restricción que debemos respetar y, al mismo tiempo, una solución, fecha o iniciativa que sí puede modificarse. Tener esa distinción clara hace que cambiar de dirección no se sienta como perder el control.

Quizá esto es lo que más estoy aprendiendo con la maternidad. No puedo controlar todo lo que va a pasar durante un día con la bebé, y tampoco necesito hacerlo. Puedo prepararme, tener una idea de lo que quiero hacer, llevar lo necesario y después ajustar cuando la realidad me pida otra cosa.

Y creo que eso también aplica al trabajo.

Durante mucho tiempo asocié la buena planeación con tener todo definido. Hoy creo que tiene más que ver con entender qué necesitas mantener estable y dónde necesitas dejar espacio para cambiar.

Porque un plan no se vuelve mejor porque contemple todos los escenarios posibles.

Se vuelve mejor cuando puede recibir un imprevisto sin dejar de ser útil.

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)