• Hoy leerás lo siguiente:

  • Vivir y escribir, algo que muchas veces no es compatible.

  • Algo que podía liquidarse en 6 meses se extendió más de dos años.

  • Cómo fui desbloqueando las trabas.

  • Las increíbles similitudes entre escribir un libro y hacer producto digital.

  • Qué aprendí en el proceso.

El jueves pasado mi editora me pasó el draft final de mi libro. Cuando le hagamos los dos o tres toques que falten, Las Aventuras de un Product Manager estará listo para publicarse.

Es mi segundo libro. Desde que lancé “Challenging: cómo hacer producto en un banco digital y construir las finanzas del mañana” allá por 2022, andaba con ganas de hacerlo de nuevo. Sin embargo, la vida me estaba pasando por encima.

La vida me pasó por encima

Lancé Challenging durante unas vacaciones en Nueva York. En ese momento estaba recién mudado a Barcelona, y con mi esposa vivíamos una vida de descubrimientos y libertad en nuestra nueva ciudad.

No era todo fácil. De hecho, pocas cosas lo eran. Los trámites y la incertidumbre en esa nueva realidad hacían todo un poco desgastante. Pero encontrábamos momentos para disfrutar aquello por lo que tanto habiamos peleado.

No lo sabía, pero lo que vendría después fue, sin dudas, la época más dura de mi vida.

Al poco tiempo empezó la mala: las tasas de interés en Estados Unidos empezaron a subir, dejando al mundo startup sin fondeo. Las contrataciones se congelaron y todo el futuro de la industria en la cual yo me movía se empezaba a poner en duda.

En ese momento estaba trabajando desde europa para una fintech de Latam (Ualá). Luego de un año de trabajar en un horario de locos, decidí irme a buscar un futuro más europeo. Sin embargo, por el contexto, esto parecía muy difícil.

Entones tuve una idea que, al día de hoy, sigo preguntándome cuan inteligente fue: emprender.

Funde Upper Academy, la academia fintech, para enseñar cursos de crédito, pagos, open finance. Durante un tiempo tuvimos bastante éxito. Armábamos cursos donde participaban algunos de los mayores referentes de la industria fintech de Latam, y de a poco nos íbamos metiendo en capacitar empresas.

Pero las ganas no pagan las cuentas. En paralelo me empecé a dedicar a la consultoría, y fui arañando algunos euros mientras veía que mi academia no podía escalar como yo me había imaginado.

Un día de 2023, mi esposa viene una mañana, se me sienta en mis rodillas y me dice: “creo que estoy embarazada”.

Y ahí todo se dio vuelta. La realidad me golpeó la cara: ya no éramos nosotros dos, y tenía que tomar las riendas del asunto de una manera mucho más seria. Sin embargo, el mercado allí seguía parado.

Un amigo me ofreció trabajar en su startup. Bueno… ex amigo: trabajé tres meses para el armándole un producto de crédito, me pagó solo uno. Me fui, obvio, estaba en serios problemas.

Hasta que Influur, una empresa americana a la cual le daba una consultoría, decide contratarme como Head of Product para liderar su equipo de producto en formación. Y ahí todo se empezó a acomodar.

Fue un año y algunos meses increíbles. Realmente dimos vuelta el equipo y la cultura de trabajo. Y en ese momento, volviendo a liderar un equipo de producto, contratando y haciendo crecer la plataforma, es que se me prendió la lamparita:

¿Y si vuelvo a intentarlo?

Era 2024. Elena ya había nacido. Nada era fácil, pero el contexto y la experiencia me inspiraban. Así que decidí bajar algunas cosas a la hoja.

Al principio, empecé a escribir un manuscrito sobre la importancia de la gestión de relaciones para un PM. Era un tema poco abordado por los libros de Product Management, y para mi uno de los más importantes. Sin embargo, al poco tiempo fui perdiendo el entusiasmo. Me costaba darle estructura a la obra, y no me parecía que daba para un libro entero.

Un día estaba hablando con mis padres, recordando algunas enseñanzas que había tenido durante mi MBA cuando todavía vivía en Buenos Aires. En ese momento, me acordé de uno de los libros que más me habían gustado: “The adventures of an IT leader”. Una novela sobre un ejecutivo del área comercial que lo nombran CIO (CTO) de una empresa de tecnología. Capitulo a capitulo, el va a ir aprendiendo el oficio, enfrentándose a distintos desafíos típicos del rol.

Y pensé: ¿por qué no hago lo mismo, pero para Product Management?

Se hizo la luz

A los pocos días le había dado vida a David. Un ambicioso joven de 28 años que trabajaba en un banco, gestionando un producto de crédito. Está cómodo, quizá demasiado cómodo. Siente que se esta perdiendo de algo.

Su jefe es más un político que un líder. David lo admira en muchos sentidos, pero siente que no lo ayuda a crecer. Así que hace tiempo está buscando trabajo, sin demasiado éxito. Hasta que le llega la oferta de DreamFi, una pequeña fintech que ofrece tarjetas de crédito.

El shock es evidente. Los primeros días David siente un tremendo síndrome del impostor, y empieza a aprender a los golpes.

Con él, fueron naciendo otros personajes que lo rodean:

• Esteban, el CPO de DreamFi, quien será su mentor y guía.

• Valentina, la analista de producto, multitasking y con mucho sentido del humor.

• Sergio, el líder técnico que lo acompaña. Al principio mucha desconfianza, terminan siendo carne y uña.

• Lara, la pareja de David. Su sostén emocional.

• Soquetes, su gato (tiene un rol muy especial).

• Mónica, emprendedora exitosa e implacable CEO de DreamFi.

Y así llegué al capitulo 6. Y todo se durmió de nuevo.

La rutina, de nuevo

En ese momento me fui de Influur a dLocal. Volví a fintech y a los pagos con el objetivo de armar el equipo de medios de pago y aprender un aspecto mucho más técnico del Product Management. El problema era que dLocal trabajaba 24 x 7. Cuando me levantaba a las 8 am ya me esperaban los mensajes de los comerciales chinos. Cuando cerraba el computador a la tarde de ese día, Brasil y México estaban en medio del día. Era imposible compaginar la escritura, la paternidad y un empleo sumamente demandante.

David quedó esperándome en un google docs.

Cada tanto lo abría y leía las páginas que había escrito con el objetivo de empezar de nuevo. Pero mantener el ritmo era sencillamente imposible.

Cada vez que me frustraba por falta de tiempo, recordaba lo que me había funcionado para escribir mi libro anterior: entusiasmo y escribir mucho durante poco tiempo. Si ese proceso se corta por cualquier cosa, retomarlo requiere releer todo, y eso hace que el desanimo se retroalimente, forzando un nuevo abandono.

Lo que me funciona es escribir mucho y rápido, y luego con más calma, empezar a pulir.

Así que me busque el tiempo para poder hacerlo. Me di cuenta que si quería lograr que el libro viera la luz, la única manera era dandole foco durante al menos dos meses. Lamentablemente, el único momento que me podía funcionar era después de las 10 de la noche, cuando Elena dormía y el trabajo podía ser ignorado.

Así que lo hice. Era duro. La hora no era la mejor. A veces no estaba inspirado. Muchas veces se me iba el poco rato que tenía y no llegaba a terminar una escena.

Pero seguí. Metí un sprint de escritura furioso durante el invierno del hemisferio norte. Y luego de 154 tés de manzanilla y varias decenas de noches acostándome más tarde de lo que debía, tenía 20 capítulos. No listos, pero era suficiente para empezar a refinar.

Finalmente, a los pocos meses y con el entusiasmo renovado, el libro estaba listo. Le hice 3 auditorías exhaustivas con IA, corrigiendo todas las incongruencias de la historia, los estilos, y cadencia.

Pero esto no era suficiente. A mi me encantaba: lo había leído y releído infinidad de veces, y en cada pasada reescribía escenas o pulía detalles. Pero ¿era suficientemente bueno? Seguramente estaba sesgado.

Así que hace unas semanas le pasé el libro a mi amiga Laura. Lo leyó.

No voy a poner los detalles que me marcó para no spoilearte, pero le dimos varias vueltas, con ella y con otros beta readers. De repente mi cerebro tomó consciencia: tengo algo bueno entre manos, y era hora de darle profesionalismo al tema.

Así que llegó el momento de la edición.

Contacté a Marti, la editora de Challenging que no hablaba hace 4 años, y le pedí ayuda para armar el arte de tapa + todo el interior.

Y la semana que viene ya estará listo para publicar en Amazon.

Mirá que lindo cover que va a tener (es un draft):

Que aprendí

Este libro me tomó mucho más trabajo que el anterior. No solo porque quiero que sea radicalmente mejor, sino porque sé que el contexto fue extremadamente desafiante.

Sin embargo lo logré. O estoy a punto de lograrlo. En cada vez que daba un paso importante me había dado cuenta de que había podido desbloquear algo en mi que me permitía avanzar.

Cada desbloqueo me enseñaba algo. Así que intentaré resumir esos aprendizajes:

Escribir, como cualquier otro proyecto personal, no tiene deadline, por lo que es muy fácil procrastinarlo

Como dice Elon Musk, cuando una tarea tiene una fecha límite indefinida en el tiempo, esa tarea se extiende indefinidamente. No tener un objetivo temporal y un por qué detrás de uno de los factores que más dificultan avanzar.

Todo empezó a caminar cuando me dije y me convencí de que quería lanzar el libro para después del verano europeo.

Para ilustrar este problema te dejo esta famosísima charla TED que explica de manera extraordinaria este problema:

Escribir toma mucho tiempo. Paradójicamente, no es lo más placentero

Antes de escribir, piensas que poner tu cabeza y arte en cada párrafo es la parte más linda. Algunas personas la disfrutan más que otras, pero no es mi caso.

Yo quería poder leer la obra terminada, porque en mi cabeza ya tenía medianamente construido cada capítulo. Hasta probe IA para acelerar el proceso de creación para después pulir, pero el resultado era mediocre.

Entonces traté de liquidar el “construir el esqueleto” lo antes posible, y sin demasiadas vueltas. Luego iteré durante meses, dandole forma y vida a lo que había construido antes. Exactamente como se hace un producto digital.

Claude no es un gran escritor…

Me vi tentado a escribir con Claude. Hice algunas pruebas, y obviamente iban apareciendo formas de escribir típicas de IA. Fui mejorando y agregándole “Antipatrones de IA” para evitar. Funcionaba, pero todo parecía escrito por otra persona.

Así que lo fui usando pero muy criteriosamente. Tomando la escena, rearmándola y enriqueciéndola. Pero bajo ningún concepto dejando todo como estaba.

Al final desistí. Me di cuenta que me tomaba igual o más tiempo arreglar lo que creaba Claude que escribirlo por mi cuenta. El trabajo mental era mayor, pero el resultado también.

… pero sí es un gran auditor

Pasé la obra por Claude tres veces. Creo que hay incongruencias, reglas o estilos que a mi y a mi editora se nos hubiesen pasado por alto si no fuera por la IA.

Obviamente presté muchísima atención a promptearlo bien, no tirándole un “revisa esto y dime si está bien” super genérico.

Si tuviera que resumir el proceso

Primero: ten claro cuál es el objetivo del libro que quieres decir.

Después de eso, arma el indice. Luego lo cambiarás. Pero hacerlo te da una suerte de roadmap mental de lo que debes construir. Dejas de improvisar.

Luego escribe. Escribe sin miedo y sin perfección. Escribe todo el libro, rápido y como te salga. Es como montar el edificio: todavía te falta mucho trabajo por dentro, pro ya tienes el esqueleto hecho, y verás que la obra tiene vida.

Luego viene el trabajo más largo: pulir, refinar, reescribir, releer. Esta es la parte que más me gusta. Otros lo odian. Depende de cada uno.

Cuando tengas algo medianamente bueno, busca alguien que lo lea. No tiene que ser el final. ¡Ah! Y no tengas miedo de compartirlo, nadie te lo va a robar.

Y los dos consejos más importantes: escribir toma tiempo y trabajo. Asi que:
- Escribe algo que te guste y te apasione. Sino lo abandonarás. Y si lo logras, la calidad probablemente no será la mejor.
- Create espacios en tu rutina y compagínalo con tu vida personal. Si empieza a haber fricción entre tu vida y tus momentos para escribir, no lo lograrás. A veces tendrás que hacer sacrificios, pero es importante que sea sostenible. No sirve de nada hacer un gran esfuerzo por dos o tres sesiones de escritura. Mejor hacer micro-sacrificios que te permitan sostenerlo en el tiempo.

Por último

Las Aventuras de un Product Manager estará disponible en Amazon a mediados de septiembre, tanto en papel como digital. Espero que les guste y lo disfruten tanto como yo (a veces) disfruté escribiéndolo.

Ale Scasserra

• Hoy leerás lo siguiente:

  • Un jueves a la noche, solo, con FOMO y una computadora.

  • Por qué las predicciones catastróficas son negocios excelentes.

  • Lo que yo escuché vs la realidad.

  • Qué está cambiando de verdad en el rol y qué no.

  • Cómo saber si la empresa donde trabajas te está quitando futuro.

La noche que casi pierdo la cabeza

Era jueves a la noche. Estaba en casa, tranquilo, sin nada urgente, que es exactamente la peor condición posible para ponerse a pensar en la propia carrera.

Aunque admito que lo hago a menudo.

Venía hacía semanas con una molestia difícil de nombrar. Leía a colegas contando cómo habían rearmado su forma de trabajar con IA, veía demos de gente construyendo en una tarde cosas que a mí me habrían llevado un trimestre entero, y yo seguía trabajando más o menos igual que siempre. No era envidia. Era la sensación fea de estar llegando tarde.

Más conocido como FOMO.

Así que me senté frente a la computadora con una intención bastante modesta: entender cómo meter estas herramientas dentro de mi propio flujo de trabajo.

Encontré otra cosa.

Lenny Rachitsky, el del newsletter que todos conocemos, había organizado un evento con varios oradores. Entre ellos estaba Claire Vo, que por entonces dirigía producto en LaunchDarkly. El título de su charla era este:

“Product Management Is Dead, So What Are We Doing Instead?”

Product management está muerto.

Hermoso.

Me quedé mirando esa pantalla bastante más tiempo del que me gustaría admitir.

Yo amo lo que hago. Y no lo digo como frase de perfil de LinkedIn: llevo más de una década metido en esto, doy clases de esto, escribo un newsletter entero sobre esto. Ahí estaba, un jueves a la noche, leyendo que la cosa a la que le había dedicado la carrera entera se había terminado, y que la conversación seria ya era otra.

Aquello no me inspiró. Me dio miedo. Y ansiedad.

¿Suena familiar?

La ola

Lo que hice a continuación es la parte que menos me gusta contar.

Durante las semanas siguientes me convertí en un consumidor compulsivo de contenido sobre IA. Newsletters, hilos, charlas grabadas, cursos, gente en LinkedIn explicando el mundo nuevo con una seguridad que a mí me faltaba por completo. Abría veinte pestañas y cerraba diecinueve sin leerlas. Guardaba links que no volvía a abrir. Empecé cosas que no terminé.

Tengo un grupo conmigo mismo que se llama “Yo” lleno de links de cosas de IA que jamás abrí ni abriré.

La idea que me movía era simple y bastante infantil: si corro lo suficientemente rápido, agarro la ola.

No la agarré. No la iba a agarrar nunca. Se publicaba más material por día del que yo podía leer en una semana, y cada pieza nueva venía con la misma temperatura emocional que la anterior. Lo interesante es lo que pasó después: en algún momento mi cabeza dejó de correr y empezó a negar. Me descubrí evitando el tema. Salteando el artículo. Cambiando de conversación cuando alguien lo sacaba en una comida.

Miedo, después saturación, después negación. Es una secuencia bastante común y no tiene absolutamente nada de heroico.

Me llevó meses salir de ahí. Y lo que me sacó no fue una herramienta nueva ni un curso: fue volver al principio, a esa misma charla, y hacer algo que no había hecho la primera vez. Escucharla completa.

Lo que dijo en realidad

Claire Vo nunca dijo que el Product Manager desaparece.

Su argumento, cuando uno lo sigue hasta el final, es bastante más medido que el cartel de la entrada. Dice que el product management tal como lo conocemos se termina, que la IA está desarmando partes del rol más rápido de lo que muchos esperábamos, y después aclara el punto que a mí se me había pasado por completo: la IA reemplaza tareas, no trabajos enteros. Su conclusión es que hay que automatizar lo repetitivo, sumar oficio de las disciplinas de al lado y multiplicar el impacto del equipo enseñando lo que uno aprende.

Es un consejo profesional razonable. Es, de hecho, más o menos lo que yo mismo le diría a alguien que me viene a preguntar.

Ahora fijate lo que pasó en el medio.

El contenido decía “adaptate”. El título decía “está muerto”. Y lo único que me llegó a mí, aquel jueves a la noche, fue el título.

No es culpa de ella (¿o si?). Un buen título hace su trabajo, y ese lo hizo increíblemente bien: aquí estoy yo, escribiendo sobre esa charla casi dos años después. Pero en esa distancia entre el cartel y el contenido hay algo que conviene mirar de frente, porque explica buena parte de lo que estás leyendo estos días sobre tu propia profesión.

Por qué el miedo paga

Hoy no hay nada más escaso que la atención. Y de todas las emociones disponibles para capturarla, el miedo es de lejos la más eficiente. Le gana a la curiosidad, le gana al entusiasmo y le gana por varios cuerpos al matiz.

Esto no es una teoría mía sobre gente malintencionada. Es una descripción de incentivos.

Cuando el máximo responsable de una empresa de IA sale a decir que su tecnología va a borrar categorías enteras de empleo, está diciendo dos cosas a la vez. Una es una predicción sobre el mundo. La otra, que es la que de verdad importa, es una declaración sobre el poder de su propio producto: esto que construimos es tan grande que puede romper la sociedad. Ese enunciado ha ayudado a levantar algunas de las rondas de capital más grandes que se hayan visto. El miedo, ahí, no es un efecto colateral del discurso. Es parte del pitch.

Y el mecanismo baja perfecto hasta nuestro nivel. Quien publica “el rol de Product Manager desaparece” consigue en un día lo que otro no consigue en tres meses de artículos sensatos sobre discovery. Se instaló, además, una regla no escrita bastante tramposa: si no estás anunciando la desaparición de tu propia profesión, es que no entendiste hacia dónde va el mundo. Quedas como el señor que defiende el fax.

Lo perverso del asunto es que el incentivo premia siempre la versión más extrema de cualquier idea razonable. “Conviene que los PMs aprendan a construir prototipos” es un consejo útil que no lee nadie. “El PM que no programa está terminado” es el mismo consejo pasado por una picadora, y ese sí viaja. El matiz no se pierde por ignorancia: se pierde porque el matiz no se comparte.

Y quien está del otro lado de la pantalla, un jueves a la noche y con la guardia baja, no recibe un análisis. Recibe una sentencia sobre su vida laboral.

Yo compré esa regla durante un tiempo. Por eso escribo esto.

Full-stack builders

La versión más concreta del asunto es la del rol único.

El CEO de Microsoft, Satya Nadella, contó en un video que circuló muchísimo estos días que en LinkedIn (que pertenece a Microsoft) ya no hablan de Product Managers sino de “full-stack builders”: el ingeniero, el diseñador y el PM colapsados en una sola figura que hace todo apoyada en IA. La idea corrió como reguero de pólvora y aterrizó, como aterrizan siempre estas cosas, en forma de pregunta difícil dentro de reuniones de empresas que no se parecen en nada a Microsoft.

Andá a cag*r Nadella.

Mi posición aquí no está en ninguno de los dos bandos (ni el que cree que no pasa nada, ni en los que creen que todo se terminó), así que la digo entera.

Programar con ayuda de IA cambió de verdad lo que puede hacer un equipo, y cambió sobre todo lo que puede hacer una persona sola. En una empresa de tres personas que todavía está buscando su primer producto, el rol único no es una moda: es aritmética. No hay plata para tres perfiles y alguien tiene que hacer las tres cosas.

En una compañía con recorrido, con clientes que pagan, deuda técnica, regulación y una docena de áreas internas opinando, colapsar el trío de producto en una sola persona es una manera muy elegante de perder criterio, disfrazada de eficiencia. Entender el negocio, diseñar la experiencia y construir el sistema siguen siendo tres oficios que necesitan cabezas distintas discutiendo entre sí, porque esa discusión es literalmente el lugar donde aparece el producto. El que hace las tres cosas solo no discute con nadie, y eso se nota bastante rápido en lo que sale.

Ahora bien, que no aplique como norma general no significa que haya que ignorarlo. Al contrario: es el experimento más interesante que tenemos disponible en años.

¡Ey! Te cuento que a mediados de septiembre sale mi nuevo libro: “Las Aventuras de un Product Manager”. Mi primera novela que cuenta la historia de David, un jóven PM con el desafío de construir y escalar un nuevo producto en una pequeña startup.

Si querés que te avisemos antes que nadie que ya está disponible en Amazon, súmate a la waitlist.

Lo que veo

Los números que circulan sobre esto hay que agarrarlos con pinzas, porque casi todos vienen de alguien que tiene interés en venderte algo. Aun así, cuando uno cruza varias fuentes distintas la foto es bastante consistente y bastante aburrida: la cantidad de posiciones abiertas de producto creció respecto de hace dos o tres años, y alrededor de seis de cada diez búsquedas piden hoy alguna experiencia demostrable con IA.

Eso es exactamente lo contrario de una profesión que desaparece. Es una profesión a la que le cambiaron los requisitos.

Y coincide con lo que veo desde adentro. Trabajo en fintech en Europa, asesoro y capacito equipos en España y en Latinoamérica, y doy clases a gente que recién está entrando al rubro. Las empresas con las que hablo siguen contratando perfiles de producto, igual o más que hace unos años. Lo que cambió es la entrevista. Antes querían saber cómo priorizabas. Ahora quieren saber, además, qué construiste el mes pasado sin pedirle permiso ni recursos a nadie.

Mi apuesta, y es una apuesta y no una profecía: en los próximos diez años estos roles no se funden en uno.

Y por suerte no soy el único que piensa así → Ravi Mehta y Matthew Mamet también.

Qué haría yo

Si estás en el medio de este ruido, esto es lo que me habría servido escuchar aquel jueves a la noche:

• Separá el título del contenido. Cada vez que leas un anuncio sobre la muerte de tu rol, andá hasta el final del argumento antes de asustarte. Casi siempre el final dice “aprendé a usar esto”, que es una cosa bastante distinta de “te quedaste sin oficio”.

• No intentes agarrar la ola entera. Es imposible y el intento agota. Elegí una sola cosa de tu semana laboral, la más repetitiva y la que menos te gusta, y automatizala de punta a punta. Después la siguiente.

• Construí algo, aunque sea feo y no lo vea nadie. La diferencia entre el PM que usa estas herramientas y el que habla de estas herramientas se nota en treinta segundos de conversación.

• Si lideras un equipo, armá una célula aparte: un PM, un ingeniero y un diseñador trabajando con IA al máximo, con permiso explícito para romper el proceso y sin la obligación de sostener el roadmap del trimestre. Un experimento acotado, con fecha de revisión y con alguien mirando qué aprendimos. Eso es muy distinto de reorganizar la compañía entera porque lo hizo alguien en California.

• Mirá dónde trabajas. Esta es la más importante de todas y merece su propio párrafo.

Para finalizar

Hay una sola parte de todo este discurso que sí me parece que hay que tomarse en serio, y no es justamente la que grita más fuerte.

Si trabajas en una empresa que ni siquiera está intentando ponerse al día con esto, esa empresa te está quitando empleabilidad futura. No hace falta que lo consiga. Hace falta que lo intente: que haya presupuesto, que haya alguien empujando, que se pruebe y se fracase a la vista de todos. Porque el día que salgas a buscar trabajo, ya no van a preguntarte solamente cómo priorizas. Van a preguntarte qué hiciste con estas herramientas, y vas a estar compitiendo contra alguien que tuvo dos años para practicar mientras tú mirabas el tema de lejos.

Ese, sin drama y sin anuncios apocalípticos, es el riesgo real. El problema nunca fue que el rol se muriera: es quedarse quieto en el único lugar del mercado donde efectivamente se congeló.

Volvé a leer el título de aquella charla. “Product management is dead.” Casi dos años después sigo aquí, sigo haciendo esto, y las empresas que conozco siguen contratando gente que lo haga.

No compres el discurso. Compra los datos, y sobre todo mirá con atención lo que hace la gente que tienes al lado.

Ale Scasserra

• Hoy leerás lo siguiente:

  • La historia del lavaplatos que terminó fundando Nvidia.

  • Un mensaje de Daniel, años después de Bogotá.

  • Por qué tener contactos y tener un buen pasado son cosas distintas.

  • Lo que la gente recuerda de ti cuando ya no trabajan juntos.

  • Cómo irse de un trabajo.

Denny’s

Jensen Huang tenía quince años y trabajaba en un Denny’s de Portland. Lavaplatos, busboy, mozo. Lo cuenta él mismo, con un orgullo que no termina de ser una broma: “Nadie puede cargar más tazas de café que yo”.

Antes de eso, en un internado en Kentucky adonde sus padres lo habían mandado desde Taiwán, limpiaba los baños. Muchos años después, siendo ya el CEO de una de las empresas más valiosas del mundo, lo dijo delante de una sala llena de gente: “He limpiado más inodoros que todos ustedes juntos”.

En 1993 se sentó en otro Denny’s, este en Silicon Valley, con Chris Malachowsky y Curtis Priem. Eligieron el lugar por una razón poco épica: había café ilimitado y nadie los echaba. De esa mesa salió Nvidia.

Huang repite que aquellos años le dieron el carácter. En una charla en Stanford lo dijo sin anestesia: “La grandeza no es inteligencia. La grandeza viene del carácter. Y el carácter no se forma en la gente inteligente, se forma en la gente que sufrió”. Después les deseó a los alumnos abundantes dosis de dolor y sufrimiento, que es una cosa rarísima para decirle a un auditorio de Stanford, y probablemente lo más útil que escucharon ese año.

Hasta ahí la historia que todo el mundo conoce. Hay un detalle que casi nadie menciona, y es justamente el que a mí me importa.

Malachowsky y Priem no eran compañeros de facultad de Huang. Eran colegas. Gente con la que se había cruzado trabajando en el mundo de los chips, cuando ninguno de los tres era nadie todavía.

Nvidia la fundaron tres tipos que se conocieron en un trabajo anterior.

Yo no soy Jensen Huang. Él es taiwanés y canoso. Fuera de eso, calcados.

Pero hay algo que comprobé, y no una sola vez: tu pasado es uno de los activos más valiosos que tienes como profesional. Y casi nadie lo administra como tal.

Un mensaje

Hace un tiempo me llegó un mensaje.

“¿Podés hablar en estos días? ¿Estás haciendo consultorías?”

Era Daniel (enseguida te cuento quién es Daniel).

Le contesté enseguida. “Sí, es un tema que me encanta”.

Al día siguiente me llamó. Hablamos un rato de nada, de cómo andaba cada uno, y en algún momento fue al punto:

“Mi esposa trabaja en una empresa de aquí, de Miami. Me preguntó si conocía alguien crack en Producto, así que pensé en ti.”

De esa llamada salió mi primer trabajo como Head of Product.

Bogotá

Con Daniel trabajamos juntos el lanzamiento de Ualá en Colombia. Yo en Producto, él en Business Development.

Fueron meses largos y duros. Ualá era una empresa exigente y ese proyecto lo era todavía más: estábamos por abrirle un banco digital a cincuenta y dos millones de personas y el margen para el error era bastante fino. Trabajamos mucho y trabajamos pegados, de esa forma en la que terminas sabiendo a qué hora almuerza el otro y qué cara pone cuando algo se va a caer.

El día del lanzamiento, en Bogotá, cuando el CEO subió al escenario, nos emocionamos los dos. No es una manera de decir. Estábamos ahí parados y se nos escapó (bueno, a mi un poco más, soy un poco sensible).

Después el proyecto terminó, cada uno siguió su camino, y pasaron años.

Y un día, el mensaje.

Lo que me quedó dando vueltas no fue la oportunidad. Fue darme cuenta de que yo no había hecho absolutamente nada para que ese mensaje existiera. No hubo estrategia, ni plan de contactos, ni una hoja de cálculo con seguimientos trimestrales. Lo único que había hecho, años antes, era trabajar bien al lado de esa persona.

La lista

Ese día hice un ejercicio. Me senté a ordenar cómo había conseguido en realidad cada uno de los trabajos importantes de mi carrera.

A Ualá entré porque Marcelo, el CPO, me encontró en un grupo de WhatsApp de gente de producto en fintech y alguien le había hablado de lo que yo estaba haciendo en Wilobank.

A Influur entré por Daniel.

Las consultorías y capacitaciones que doy hoy salieron, casi todas, de gente con la que ya había trabajado antes. De Ualá, de dLocal, de Upper Academy, de Influur (todas empresas donde trabajé).

Mi carrera está construida sobre referidos. No sobre postulaciones.

Durante años creí que esto se construía hacia adelante: el próximo curso, la próxima certificación, el próximo título en el perfil de LinkedIn. Dediqué a eso una cantidad de energía que hoy me da un poco de vergüenza. Escribí un newsletter entero preguntándome si sirven los másters. Y mientras tanto, lo que efectivamente me movió de un lugar a otro fue siempre gente que había visto de cerca cómo trabajaba.

Estaba puliendo el escaparate. La venta venía de otro lado.

Influur

Entré a Influur, una startup americana de influencer marketing, e hice lo imposible por hacer las cosas de la mejor manera que sabía.

No lo cuento como mérito moral. Lo cuento porque tuvo consecuencias medibles. De esa etapa me quedaron relaciones que siguen abiertas, y varias personas de esa empresa me llamaron después, en momentos distintos, para consultorías y capacitaciones.

Pero a veces no es tan lineal, y este es el caso que más me gusta.

Hace unos días me escribió un ex compañero de otra empresa para que lo ayude a capacitar a su equipo en unos temas muy específicos. No somos amigos. Nunca lo fuimos. No nos escribimos para los cumpleaños ni tenemos un chiste interno.

Lo que hay entre nosotros es admiración profesional y el recuerdo de haber trabajado muy bien juntos.

Con eso alcanzó.

Networking

Tener contactos y tener un buen pasado son dos cosas distintas, y se construyen en lugares distintos.

Los contactos se acumulan. Vas a un evento, hablas con doce personas, te llevas doce perfiles nuevos y ninguno de esos doce te vio nunca tomar una decisión difícil. Sumas gente que no tiene la menor idea de cómo eres cuando el proyecto se complica y hay que dar la cara.

El buen pasado funciona al revés. No lo construyes conociendo gente nueva, lo construyes con la que ya tienes al lado. Y no se construye en el evento del jueves: se construye un martes a las cuatro de la tarde, cuando algo se rompió y hay que decidir quién se queda a arreglarlo.

Fijate que curioso. Nadie te va a recomendar para un puesto por lo simpático que estuviste en un afterwork. Te va a recomendar porque una vez, hace tres años, se quedó tranquilo cuando te dejó algo importante en las manos.

Hay además una asimetría que conviene entender bien. Cuando alguien te recomienda no te está haciendo un favor gratis: está poniendo su propio nombre encima del tuyo. Si sales mal, el que queda expuesto es él, delante de su jefe, de su cliente o de su esposa. Por eso la gente recomienda poco y recomienda con miedo. Y por eso el filtro real no es cuánto te aprecian, sino cuánta tranquilidad les das.

Por supuesto que conocer gente sirve. Pero es la capa de arriba. Debajo tiene que haber algo que valga la pena recordar.

Lo que la gente recuerda

Cuando alguien piensa en ti cuatro años después no está evaluando tu currículum. Está recuperando un puñado de impresiones bastante toscas. Estas son las que, por lo que he visto, sobreviven al tiempo:

• Cómo te comportaste cuando las cosas se rompieron. Nadie recuerda tu desempeño en el trimestre tranquilo.

• Si podían dejarte algo y olvidarse del tema. La confiabilidad es aburrida y es lo primero que se recuerda.

• Si contestabas los mensajes. Suena menor y no lo es en absoluto.

• Si te colgaste medallas ajenas. Esto la gente lo registra en el momento exacto en que ocurre, y no lo olvida nunca.

• Si te hiciste cargo cuando salió mal. Sobre todo si salió mal por tu culpa.

• Cómo trataste a la gente que no te servía para nada. Al becario, al proveedor, al que atiende soporte. Aquí es donde de verdad se ve quién eres.

• Cómo te fuiste.

Ninguna de esas cosas aparece en un currículum. No se certifican, no se estudian y no se miden en una evaluación de desempeño. Y son exactamente las que deciden si tu teléfono suena dentro de cuatro años.

Ese último punto merece su propia sección.

Cómo irse

Casi toda la gente que conozco que quemó un puente lo quemó en sus últimas tres semanas, no en los tres años anteriores.

Algunas cosas que aprendí, varias por las malas:

• Avisa con tiempo y con la cara, no por mail. La conversación va a ser incómoda diez minutos y te va a durar bien diez años.

• Entrega el trabajo ordenado y documenta lo que solo sabes tú. Es lo único que la gente que se queda va a recordar de tu salida.

• No uses la entrevista de salida para descargarte. No sirve para cambiar la empresa, y sí sirve para definir cómo te recuerdan.

• No te lleves al equipo por despecho.

• No cuentes tu versión de los conflictos en las despedidas. La industria de producto en español es mucho más chica de lo que crees. Trabajé en Argentina, Colombia y España, y te aseguro que el mundo es un pañuelo.

• Escribe a las personas concretas con las que trabajaste bien. Una por una, no un mensaje masivo. Dos líneas. Esa es toda la gestión de contactos que vas a necesitar en tu vida.

Y una que no es sobre irse sino sobre quedarse: si estás incómodo, resuélvelo ahora, hablando. La gente que se va enojada casi siempre se calló durante meses.

Para finalizar

Huang volvió a aquel Denny’s en 2023, ya con Nvidia valiendo más de un billón de dólares, y le dijo al CEO de la cadena que ahí hacían los mejores panqueques. Me gusta esa historia por lo que no dice. Nadie planifica que el peor trabajo de tu vida y la mesa donde fundas tu empresa terminen siendo el mismo mostrador.

Tú no sabes cuál de las personas que hoy tienes al lado te va a llamar dentro de cuatro años. No hay manera de saberlo y no sirve de nada intentar adivinarlo. El único movimiento disponible es hacer bien el trabajo de hoy y tratar bien a la gente de hoy.

Yo no tenía la menor idea, aquel día en Bogotá, de que el tipo emocionado que estaba a mi lado me iba a conseguir mi primer puesto de Head of Product.

Tu presente es el pasado de alguien más.

Trabaja como si te fueran a llamar.

¡Ey!

Cuando empecé en Producto tuve mentores, pero a veces tuve que descubrir solo cuál era el camino correcto, y eso fue duro. Si quieres trabajar algún tema en particular, como entrenar para entrevistas de trabajo, aprender a gestionar stakeholders complicados, hacer buenas preguntas, o leer un P&L, no te olvides que hago mentorías. Puedes escribirme por privado.

• Hoy leerás lo siguiente:

  • La noche en que un ATM me cambió la vida, por suerte

  • Un modelo de sepsis que funcionaba exactamente como fue diseñado: mal

  • De dónde salió el manual de producto que usamos todos

  • Por qué la regulación y sensibilidad del producto es la excusa perfecta para no experimentar

  • Cómo experimentar en serio cuando no puedes fallar barato

Un cajero, un saldo en cero

Hace unos años estaba en la calle con mi novia de entonces, a doscientos metros de su casa. Llevábamos cuatro años juntos y las cosas ya venían mal.

Me dijo que necesitaba pasar por un cajero automático (ATM). Entramos al primero que encontramos, puso la clave y la pantalla le devolvió saldo cero. Había cobrado el sueldo el día anterior.

Volvió a probar. Cero otra vez.

Yo ya trabajaba en servicios financieros, así que hice lo que hace alguien que conoce: le expliqué que probablemente fuera un error de consulta de saldo en la red, que revisara los movimientos para ver si aparecía algún débito, que el dinero seguramente estaba. Todo eso era cierto.

No sirvió absolutamente nada. Estaba fuera de sí.

La acompañé hasta la casa (fue hace unos 10 años, no tenía el banco en el teléfono), entró a la computadora, ingresó a la web del banco y ahí estaba el sueldo, entero, intacto. Una hora más tarde habíamos terminado la relación.

No por el cajero, claro. Pero el cajero pero la discusión posterior derivó en eso.

Prioridad baja

Pensemos qué clase de defecto fue ese, en el vocabulario que usamos todos los días.

No hubo pérdida de datos. No se movió un peso. La transacción ni siquiera existió: fue una consulta de lectura que devolvió un valor equivocado. El error se resolvió solo, sin intervención, en cuestión de minutos. El impacto financiero para el banco fue cero y para la clienta también.

En cualquier matriz de severidad que hayas usado en tu carrera, eso es de prioridad baja, a menos que le esté pasando a una cantidad muy grande de usuarios. Es decir, es un ticket que entra al backlog, se prioriza en algún sprint futuro y probablemente nunca se cierra.

Para la persona parada frente a esa pantalla es su sueldo entero había desaparecido.

El modelo que nunca falló

Hay un caso en salud que lleva esta idea más lejos, porque ahí ni siquiera hubo un bug.

Epic, el sistema de historia clínica electrónica más usado en Estados Unidos, incluye un modelo que predice sepsis y alerta al equipo médico (para los que no saben, sepsis es una respuesta inmune del cuerpo que ataca a tus propios órganos. Es una emergencia que debe ser tratada de inmediato).

Se implementó en cientos de hospitales antes de que existiera evidencia externa sobre su capacidad predictiva. En 2021, un equipo de la Universidad de Michigan publicó en JAMA Internal Medicine (un reconocido períodico de medicina) una validación con casi 40.000 hospitalizaciones: valor predictivo positivo del 12%. Es decir, de cada cien alertas, unas doce correspondían a un paciente que efectivamente estaba desarrollando sepsis.

Una validación posterior en dos servicios de urgencias fue todavía peor: casi todas las alertas se daban luego de que el equipo médico ya había intervenido, sin necesidad de la tecnología.

Ahora, lo importante: el sistema nunca se cayó. No hubo incidente, no hubo downtime, no hubo un solo ticket de severidad alta. Todos los componentes hicieron exactamente lo que estaban diseñados para hacer. La página cargaba, el modelo devolvía un score, la alerta se disparaba.

El daño fue de otro tipo: profesionales de la salud entrenándose durante meses a ignorar una alerta que casi siempre estaba equivocada, en un contexto donde ignorar la alerta correcta mata gente.

De dónde viene el manual

El playbook que usamos casi todos —iterar rápido, testear en producción, lanzar y aprender, fallar barato— se formalizó en el software de consumo masivo de los últimos veinte años. Redes sociales, e-commerce, streaming, herramientas de productividad.

No tengo nada en contra de él. Pero está construido sobre un supuesto perfectamente razonable para esos productos: el peor caso de un error es una mala experiencia y, en el extremo, un usuario que se va.

Si tu feed carga contenido irrelevante, lo cerrás y listo. Si el buscador de una tienda te trae resultados raros, te frustras y te vas. Si tu app de notas pierde el formato de un párrafo, te enojas y volvés a Word. Todo eso se recupera. Se puede pedir perdón, se puede compensar con un cupón, se puede arreglar el jueves.

Ese manual se exportó después a toda la industria como si fuera universal. Y buena parte de la gente que lo aplica trabaja en productos donde el supuesto de base no se cumple: fintech, seguros, salud, educación formal, energía, transporte, cualquier cosa que toque datos sensibles.

Qué cambia en una industria regulada

Cuatro cosas, y ninguna es obvia.

El usuario no puede distinguir un error de un abuso. Yo entendía lo que estaba pasando en ese cajero porque trabajaba en finanzas. Ella no tenía forma de saberlo, y tenía todo el derecho a creer que le habían sacado la plata. Lo mismo aplica a alguien a quien le rechazan un crédito, le suben la prima del seguro sin explicación o le niegan una cobertura: no tiene manera de saber si fue un criterio, un sesgo o un defecto. La severidad real la define lo que el usuario cree que pasó.

La confianza se rompe en una dirección sola. Un cliente que dejó de creer no vuelve, y además cuenta lo que le pasó en cada conversación donde el tema aparezca. En un producto de consumo un mal día se compensa con diez buenos. Acá esa matemática no funciona.

El producto está siendo observado. Hay un regulador mirando, y su tolerancia a la frecuencia de fallas no depende de cuánto las tolere tu usuario. Depende lo que la norma diga (o no diga) y si recibe o no denuncias de tu plataforma.

No se puede arreglar el error. En software de consumo revertís el deploy y el mundo vuelve al estado anterior. Cuando una póliza se emitió, un crédito se desembolsó, un diagnóstico entró en la historia clínica o un siniestro se rechazó, el efecto ya existe como hecho jurídico. Podés dejar de producir más, no podés hacer que no haya pasado.

Recreación del clásico diagrama de Venn de Product Management adaptado a servicios financieros. Fuente: “Challenging: cómo hacer producto en un banco digital y construir las finanzas del mañana”. Autor: Alejandro Scasserra.

El otro lado del argumento

Todo lo anterior es la excusa favorita de las empresas reguladas o en industrias sensibles para no experimentar jamás.

“Nosotros somos regulados” es una frase que en la mayoría de los casos significa “acá nadie tiene ganas de discutir con compliance”. La escuché durante años, la usé yo mismo alguna vez, y casi siempre tapaba un problema de coraje disfrazado de problema de normativa.

Vale la pena desarmarlo, porque entender cuánto se puede jugar con esto puede ser la diferencia entre la velocidad o caos en proyectos eternos:

Qué prohíbe realmente el regulador

Prácticamente ningún marco regulatorio prohíbe experimentar. Lo que restringen son tres cosas que los experimentos suelen hacer de forma incidental, sin que el equipo se dé cuenta.

La primera es el tratamiento diferencial sin justificación. Un A/B test sobre pricing, sobre condiciones de crédito o sobre criterios de suscripción no es un test desde el punto de vista normativo: son dos tratamientos distintos aplicados a personas equivalentes, y eso necesita una justificación técnica que el equipo casi nunca tiene preparada de antemano.

La segunda es la trazabilidad. Tenés que poder reconstruir, meses o años después, qué versión exacta del producto vio una persona determinada en el momento en que tomó una decisión. En general los experimentos no conservan eso. El feature flag que borraste el trimestre pasado era evidencia, y ya no existe.

La tercera es el consentimiento y la información. Hay variantes que son ilegales en sí mismas, con test o sin test. Probar si esconder un costo mejora la conversión no es un experimento prohibido: es un producto prohibido. La restricción vive en la variante y no en el método.

La pregunta que ordena el diseño

Antes de diseñar cualquier experimento en un producto regulado o sensible, hay una pregunta que vale más que toda la discusión metodológica: si esta variante está equivocada, ¿puedo deshacer el efecto que produjo, o solamente puedo dejar de producir más?

Si podés deshacerlo, el manual estándar sirve casi entero.

Si solo podés frenar, cambia todo el diseño. La cohorte expuesta tiene que ser del tamaño que puedas reparar, no del tamaño que necesitás para significancia estadística. El plan de remediación se define antes de lanzar, no cuando el experimento sale mal. Y el criterio de corte deja de ser “cuándo tengo confianza suficiente” para pasar a ser “cuánto daño acumulado tolero mientras aprendo”.

Esa pregunta también reordena la prioridad. Los experimentos reversibles se hacen primero y sin pedir permiso. Los irreversibles se hacen últimos, con menos gente y con la reparación ya escrita.

Te doy un ejemplo: una vez estaba rediseñando un flujo de onboarding de un producto financiero. Cumplir con todos los requisitos de compliance me iba a tomar un mes y medio, y yo necesitaba saber si tenia que cambiar los formularios de carga de datos debido a algunas hipótesis que teníamos con el equipo. Lo lanzamos a producción con la aprobación de compliance para 10 usuarios. Con eso nos alcanzó para entender si funcionaba. Luego compliance pidió el resto de los datos por mail a los usuarios.

Compliance adentro del proceso, no en la aduana

El patrón que garantiza el NO es el más extendido: el equipo diseña, construye, y recién después va a pedir aprobación. En ese orden, la persona que aprueba solo ve riesgo, porque el upside ya se decidió sin ella.

Error.

En mi libro Challenging escribí que una de las capacidades centrales del PM en finanzas es entender el espíritu de la norma: qué está tratando de proteger, no qué dice literalmente. Cuando entiendes eso, casi siempre puedes diseñar una versión del experimento que no toca lo que la norma protege. Y esa conversación es infinitamente más productiva si la persona de compliance participa del diseño en vez de recibirlo terminado.

Para finalizar

Si trabajás en un producto donde equivocarse le cuesta algo serio a otra persona, el manual clásico para hacer producto se queda corto.

Trabajar con las áreas de cumplimiento y calibrar los experimentos en función de la capacidad de reparar el daño es clave. Esto te permitirá convervar la velocidad de iteración a pesar del contexto.

Ale Scasserra

¡Ey!

Cuando empecé en Producto tuve mentores, pero a veces tuve que descubrir solo cuál era el camino correcto, y eso fue duro. Si quieres trabajar algún tema en particular, como entrenar para entrevistas de trabajo, aprender a gestionar stakeholders complicados, hacer buenas preguntas, o leer un P&L, no te olvides que hago mentorías. Puedes escribirme por privado.

• Cómo mi esposa pasó de no saber nada de código a construir una app con paywall en un mes

• Por qué el concepto de “Builder PM” está explotando en la industria

• La trampa de convertir un arquetipo en el único estándar

• Qué significa esto para tu carrera, trabajes en una startup de 10 personas o en una corporación de 10.000

Read more

• Por qué los business cases de entrevistas no se parecen al trabajo real

• La trampa del PM “estratégico” que termina ejecutando pedidos

• Quién realmente decide qué se construye (y por qué no sos vos)

• Qué podés hacer para recuperar ownership sin esperar permiso

Read more

• Qué cambió en marzo de 2020 y por qué no volvimos del todo

• Por qué discovery y delivery no son lo mismo cuando estás en pijama

• Las conversaciones que nunca tuviste y no sabés que te faltaron

• Por qué creo, aunque me duela mucho, que lo híbrido gana

Read more

Read more

Read more

Read more

• La historia que se repite: cómo las empresas usan excusas para suavizar los titulares

• Meta, Block, Oracle: 92.000 despidos y una narrativa conveniente

• “AI washing”: cuando hasta el CEO de OpenAI dice que le están echando la culpa a la IA

• Lo que los datos realmente dicen sobre el mercado de Producto en 2026

Read more

• Por qué el debate del vibe coding está mal planteado.

• Lo que Naval Ravikant dijo y por qué está equivocado (y un poco en lo correcto).

• Qué habilidad del PM se vuelve más valiosa cuando ejecutar cuesta cero.

• Lo que yo haría si fuera un PM junior hoy.

• Charla de Erik Schluntz, researcher en Anthropic, sobre agentes y Vibe Coding.

Read more

• El primer artículo.

• Artículos que atacan problemas puntuales.

• Artículos de cómo pasar procesos de selección.

• El artículo del revuelo: salarios de Latam y España.

• Mis artículos favoritos

• El hack

• La lista completa.

Read more

• Ofertas de trabajo en Producto.

• Una historia del mundo en 2041.

• Tres hábitos que me han permitido surfear el cambio constante.

Read more

• Spider Man y el Product Sense.

• ¿Qué es el Product Sense? ¿Por qué es tan difícil de transferir?

• ¿Cómo sabes is tienes Product Sense?

• Product Sense puede ser una trampa. ¡Cuidado en los procesos de selección!

Read more

• Escenarios típicos donde tus emociones se ven desafiadas.

• El mundo real, lejos del ideal.

• Como te lo tomas es más importante que lo que te pasa.

• Qué es la Inteligencia Emocional y cómo trabajarla.

Read more