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á 👇🏻:

Si eres Product Manager y te interesa el mundo fintech, es muy probable que en algún punto hayas pensado en especializarte en payments.

Y también es muy probable que, cuando empezaste a investigar, te pasara esto:

• Demasiados conceptos nuevos

• Siglas por todos lados (PSP, acquiring, issuing, settlement…)

• Recursos técnicos sin contexto

• Y cero claridad sobre por dónde empezar.

El problema no es la falta de información.

El problema es la falta de estructura.

El error más común: aprender payments “en desorden”

Muchos PMs intentan entrar a payments así:

• Consumen artículos sueltos

• Ven charlas muy técnicas

• Aprenden conceptos aislados

• Intentan memorizar términos

El resultado suele ser frustración.

Saben “cosas”, pero no saben cómo se conectan, ni cómo eso se traduce en decisiones de producto.

Payments no es un tema difícil.

Es un ecosistema.

Qué cambia cuando un PM se mueve a payments

Pasar de PM generalista a PM de pagos no significa volverte técnico de la noche a la mañana.

Significa cambiar el tipo de preguntas que haces:

• ¿Dónde ocurre el error en el flujo?

• ¿Quién es responsable de qué parte?

• ¿Qué métricas importan realmente?

• ¿Qué decisiones de producto tienen impacto regulatorio o financiero?

Un PM de pagos no necesita saber programar el sistema.

Necesita entender cómo funciona.

Las habilidades que realmente importan

Antes de pensar en herramientas o certificaciones, hay bloques clave:

1. Entender el ecosistema de pagos Actores, flujos, responsabilidades, riesgos.

2. Comunicar claramente con equipos técnicos y negocio Payments vive en el punto medio.

3. Priorizar con contexto financiero, riesgo, fraude y regulatorio. No todo es UX o features.

4. Pensar en flujos end-to-end Desde el usuario hasta la conciliación.

5. Unit economics, ya que impactan directamente al negocio.

Por qué tener un roadmap hace la diferencia

El mayor bloqueo para muchos PMs no es la capacidad.

Es no saber qué aprender primero.

Un roadmap te da:

• Orden

• Enfoque

• Criterio para filtrar ruido

• Y expectativas realistas

No te convierte en experto en semanas.

Pero evita que pierdas meses aprendiendo cosas que no necesitas aún.

Mi recomendación si estás considerando este cambio

Si hoy estás:

• Explorando fintech

• Pensando en especializarte

• O ya trabajando cerca de pagos pero con dudas

Empieza por entender el mapa completo, no los detalles sueltos.

Por eso armé un roadmap práctico para Product Managers que quieren entrar al mundo de pagos, con foco en qué aprender, en qué orden y por qué.

👉 Aquí puedes ver el Roadmap para convertirte en Product Manager de Pagos

Para cerrar

Payments puede parecer complejo desde fuera. Pero con estructura, se vuelve entendible.

Y cuando entiendes el sistema, tomas mejores decisiones de producto.

Mención especial a mis Productesas 🩷 quienes me inspiran todos los días a compartir.

🗣️ Si lo tomas, cuéntame qué parte te sorprendió o qué te gustaría profundizar. Tu feedback me ayuda un montón.👇

hashtag#ProductManagement hashtag#Pagos hashtag#Fintech hashtag#Riesgo hashtag#Fraude hashtag#Compliance hashtag#Checkout hashtag#PMSkills hashtag#ProductManager

El rol de Product Manager de Pagos (Payments Product Manager) es uno de los más demandados en fintech, ecommerce y SaaS, pero también uno de los menos explicados.

Muchos Product Managers llegan al área de pagos “por accidente” y descubren demasiado tarde que:

• ❌ No es un PM tradicional

• ⚙️ Es un rol más técnico y con alta carga de contexto

• 💸 Impacta directamente revenue, fraude y cumplimiento (y equivocarse sale caro)

Si estás considerando especializarte en pagos —o ya trabajas cerca de este mundo— necesitas algo más que teoría suelta.

Conozco a muchos Product Managers que, en algún punto de su carrera, voltean a ver payments y piensan algo parecido a esto:

“Se ve interesante… pero no sé por dónde empezar.”

Y no es porque payments sea inaccesible.
Es una mezcla rara de conceptos, siglas, reglas, flujos y decisiones que nadie te explica en orden. La mayoría aprende entrando al rol, preguntando, equivocándose y armando el rompecabezas sobre la marcha.

Este post no es para enseñarte algo en detalle. Es para ayudarte a entender el mapa completo, antes de perderte en los caminos.

¿Qué significa realmente trabajar en pagos?

Payments no es solo cobrar.

Trabajar en pagos implica moverte en un espacio donde:

• el dinero sí importa (y mucho)

• los errores cuestan

• la experiencia del usuario compite con el riesgo

• y la regulación nunca está del todo lejos

Como Product Manager, no necesitas saber programar integraciones ni memorizar estándares, pero sí necesitas criterio. Y ese criterio se construye entendiendo el panorama general.

Por eso tener una guía ayuda. Por cierto, ¿te gustaría hacer un assesment o diágnostico sobre cuánto conocimiento tienes sobre el tema? Ingresa acá que he dejado uno listo para ti 👇🏻:

Una guía general para PMs de pagos

Quiero compartirte en este post una guía de que etapas o temas debes considerar aprender, estudiar o indagar para entender el panorama general de un gerente de producto especializado en pagos o un product manager payments.

1. Fundamentos

Todo empieza aquí.

Lo importante o lo que tienes que entender es:

• cómo funciona el ecosistema de pagos

• quién participa en una transacción

• qué tipos de pagos existen

• cómo se mueve el dinero de inicio a fin

Sin estos básicos, cualquier conversación de payments se siente ajena, como si siempre llegaras tarde a la junta.

2. Habilidades

Después viene algo menos obvio.

Payments no se trata solo de conocimiento, sino de cómo piensas como PM:

• cómo analizas impacto

• cómo tomas decisiones con información incompleta

• cómo explicas problemas complejos de forma simple

Aquí empiezas a notar que no todos los PMs de payments hacen lo mismo, pero sí comparten ciertos criterios.

3. Riesgo, fraude y cumplimiento

Este punto es el que conlleva más profundidad y contexto.

Esto, porque nadie quiere hablar de fraude cuando todo va bien. No ves el riesgo hasta que ya esta materializado. Y a nadie le gusta reunirse con Legal / Cumplimiento. Por eso, es tan importante no perder foco de estos tres gigantes.

Entender riesgo, fraude y cumplimiento no te vuelve paranoico o una máquina invensible; te vuelve realista. Te ayuda a diseñar productos que sobreviven cuando algo falla.

4. Experiencia y casos

Hasta aquí, muchas cosas son teoría. Básicamente mi sugerencia para este tema es que te documentes de casos de uso reales y/o busques alguien que te comparta su experiencia enfrentando un caso real.

No es lo mismo un happy path vs una compañía o empresa que ya opera y donde una decisión equivocada llevará a bajar el 20% en la conversión / pago.

Ver casos reales —buenos y malos— cambia la forma en que entiendes los pagos:

• decisiones que parecían obvias ya no lo son

• trade-offs que no habías considerado aparecen

• empiezas a reconocer patrones

Esta área de aprendizaje recomiendo no saltártela.

5. Entrevistas

Algo que no vas a ver en cursos generalizados es como tomar y actuar en entrevistas para roles de Product Manager de Pagos.

• cómo hablar de payments en una entrevista

• qué preguntas hacen la diferencia

• qué detalles suelen importar más de lo que parece

Para este punto, te recomiendo visitar páginas que contienen ejercicios de entrevistas para Product Managers, que te servirán de referencia:

• Exponent

• HelloPM

6. Coaching

Si algo he aprendido es que el mundo de pagos siempre genera dudas.

Tener un espacio para ordenar preguntas, aclarar conceptos y cerrar ciclos mentales es parte del proceso. A veces avanzar no es aprender algo nuevo, sino entender mejor lo que ya sabías.

Si esta en tus posibilidades, te recomiendo acercarte a expertos en el mundo del pago, quienes te podrán proporcionar atajos y resolución a dudas de esquemas y problemas complejos.

Para ir más a fondo

Este post es intencionalmente general.

Si lo que quieres es saber con más detalle qué aprender en cada etapa,
en qué enfocarte primero,
y cómo profundizar sin perderte,

preparé un Roadmap de Payments para Product Managers en formato práctico, con las etapas desglosadas, notas y recursos para cada una.

👉🏼 Acceder al Roadmap de payments para Product Managers

No es un curso. Es una guía para cuando quieres avanzar con más claridad que improvisación.

El roadmap es una PPT que incluye en cada una de las etapas conceptos claros y precisos que te orientarán en tu aprendizaje con un orden (del 1 al 6). Adicionalmente y por tiempo límitado, la compra del roadmap incluye el acceso a un grupo de WhatsApp para resolver dudas sobre el contenido.