A menudo se vende el rol de producto como el de esa persona visionaria que tiene todas las respuestas, respaldada por roadmaps perfectos y datos irrefutables. Pero cualquiera que trabaje en el mundo real sabe que la verdad es mucho más caótica.
Nuestro día a día consiste en navegar la incertidumbre, tomar decisiones difíciles con información incompleta y gestionar la presión cuando las cosas no salen como esperábamos.
Hoy me siento con Jesica Wulf, Senior Product Manager en eDreams, para hablar precisamente de esa cara B de la gestión del producto.
¡Sigue el podcast Realworld!
Escucha el episodio en Spotify, Apple Podcast o YouTube Music.
Suscríbete a nuestro canal en YouTube para no perderte ni un episodio
¿Qué quieres que sepamos de ti?
Mi nombre es Jessica Wulf. Soy argentina y hace seis años que estoy en España. Vine por trabajo en producto. Soy ingeniera industrial y llevo más de 10 o 12 años trabajando en producto. He trabajado en empresas y productos B2B y B2C. Además de haber tenido muchos fracasos y muchas victorias, me armé una carrera en organización de eventos y creación de comunidades: organicé eventos TEDx, hace poco creé una comunidad para mujeres en producto, estoy en Producta en Barcelona y, como si fuera poco, también produzco obras de teatro.
¿Qué error profesional te enseñó más que cualquier éxito?
Más que un error concreto, hubo un momento que me marcó muchísimo y me construyó toda la “coraza” de cómo me enfrento al fallo. Fue en un trabajo de hace varios años, en una empresa con alcance global, donde me tocó llevar un producto con bastante exposición. Yo estaba paralizada: me daba pánico tomar decisiones porque sentía que era muy fácil cagarla.
Una amiga que entonces era mi mentora y manager me dijo algo clave: todo el mundo se equivoca. Tenés que confiar en vos y en tu capacidad de reaccionar ante el fallo. Vas a intentar hacer lo mejor posible, pero también tenés que ser buena en reaccionar cuando salga mal. Esa conversación me cambió: empecé a enfrentarme a esas situaciones con más confianza y a construir un framework y una estructura para encontrar y enfrentar errores antes de que exploten. Me marcó muchísimo la carrera.
Todo el mundo se equivoca. Tienes que confiar en vos y en que tenés la capacidad para reaccionar ante ese fallo.
¿Has sentido ese miedo otras veces?
Sí, pero cada vez lo fui bajando más. Me fui armando esa contracara: saber qué te podés encontrar del otro lado y cómo prepararte. Pero miedos y errores, todo el tiempo.
¿La cultura influye en ese miedo a equivocarse?
Totalmente. Influyen muchas cosas: de qué país venís, la cultura de la empresa y el espacio que te rodea. Se construye una cultura sobre el error que cambia según el perfil de las personas en esa empresa. Creo que en los últimos años esto avanzó bastante: no era lo mismo equivocarse hace 10 o 15 años que hoy en tecnología.
También está el concepto de psychological safety, pero tiene que estar del lado de cada uno: animarte a equivocarte y poder decir “me equivoqué”. Eso creo que se está mejorando, aunque también hay algo muy propio de cada persona.
El rol de product manager no es tener todas las soluciones, es saber dónde ir a buscarlas.
¿Qué ha cambiado en estos años respecto al error?
Culturalmente se le da más espacio y se entendió que una buena forma de avanzar también es cagándola, pero minimizando riesgo. No es lo mismo mandarte una cagada de millones que una pequeñita.
Yo viví algo que me marcó: en un trabajo no nos pedían objetivos de negocio, nos pedían aprendizajes. No era outcome ni output, era aprendizaje. El objetivo era: “¿Cuántos aprendizajes tuviste hoy?”. Y nos reíamos, pero era real. Podías decir: “Saqué a producción un cambio de contenido y vi que no funciona”. Listo, aprendizaje. Incluso el manager decía: “Pueden traerme cinco aprendizajes en un día, no hace falta cambiar el mundo”.
Esa estructura te marca el camino y organiza la cultura.
Yo no quiero hacer bien mi trabajo, yo quiero hacer buenos productos.
¿Cómo haces para que el equipo no viva como fracaso no validar una hipótesis?
Hay personas a las que no validar una hipótesis les dispara “voy a buscar otra cosa para validarla”, y otras a las que les dispara “soy un desastre”. Volviendo a producto, para mí la clave es cómo minimizás riesgos y cómo hacés que aprender cueste lo menos posible. Ahí encontrás más certidumbre y menos impotencia cuando no validás a la primera.
El error lo vas a tener seguramente; el punto es cuándo te das cuenta de que existe
¿Qué opinas del MVP?
El concepto de MVP está muy bastardeado. Todo es un MVP si querés, pero el punto es entender qué es lo mínimo que querés validar. Yo conozco MVPs de seis meses, y para esa empresa puede ser “mínimo”, pero hay empresas que no se lo pueden costear.
Además, cada empresa tiene su “mínimo” distinto. Me pasó hace poco: yo quería sacar una interfaz nueva en una versión muy cutre para validar que la pantalla se viera. Para mí era mínimo porque validaba lo que quería, pero trabajo en una empresa con mucha exposición y no se puede dar el lujo de algo tan cutre. Ahí entendí que el chip del MVP cambia según dónde estás.
¿Qué haces cuando tienes que decidir bajo presión?
Back to basics. Algo que aprendemos tarde en producto es entender el objetivo. Si tenés muchas cosas por delante, necesitás entender hacia dónde disparás y por qué una cosa es más importante que otra.
Veo mucho a gente (incluso senior) con la sensación de que el product manager tiene que saber todo y tener respuesta para todo. Yo también lo viví: me iba a dormir un domingo estresada porque el lunes no tenía backlog para la planning. Hasta que alguien me dijo: el rol de producto no es tener todas las soluciones, es saber dónde ir a buscarlas.
Ese aprendizaje se conecta con el miedo al fallo: “no tengo backlog, soy un desastre”. No: tenés que saber dónde buscar problemas y soluciones. Hacer benchmark, hablar con customer service, hablar con developers. Yo siempre digo: “yo no soy técnica; si ustedes no me traen problemas técnicos para priorizar, no puedo armar un backlog técnico”.
¿Cómo generas impacto en tu trabajo?
Genero impacto cuando encuentro problemas que necesitan ser resueltos. A veces molesto porque soy la persona que, si me decís “necesito el botón rojo”, te pregunto “¿para qué?”. No es falta de confianza: es evitar que nos enamoremos de una idea sin revisar el objetivo. Es en esos momentos donde rompo la estructura y reencuadro: ¿para qué? ¿qué objetivo buscamos?
¿Cómo decides cuando todo parece importante?
A veces tener tantas cosas genera “backlog vacío” en el sentido de que el trabajo planeado se traba. En empresas grandes, con upstream y downstream (dual track), podés quedarte con poco listo para ejecución no porque no haya nada, sino porque hay tantas prioridades y dependencias que el upstream se bloquea.
¿Cómo entiendes el dual track para que no sea waterfall disfrazado?
Totalmente de acuerdo con que si lo separás por equipos es un waterfall tapado. Es clave tener gente técnica en el upstream. Me pasó una vez: una sala llena de gente hipotetizando una hora y media, pasa un chico técnico (ni senior) y dice “esto es una configuración del backend, se arregla”. Y fue como: no puedo creerlo. Tener una persona técnica en esa conversación cambia todo.
Pero también toca una fibra humana: roles, límites y ego. A mí me gusta meterme en lo técnico por la lógica, y no todos los equipos se bancan que pregunte por qué una configuración está así. Y al revés: cuando UX define producto, antes me molestaba y ahora entiendo que hay que estar por encima del ego. Yo siempre digo: “yo no quiero hacer bien mi trabajo, yo quiero hacer buenos productos”. Si el producto es mejor dejando lugar al developer o al UX, entonces yo soy mejor, no peor.
¿Qué rituales o procesos te ayudan a detectar riesgos y puntos ciegos antes de lanzar?
Primero, una idea de humildad: Instagram intentó parecerse a TikTok, cambió el feed, hubo reacción enorme y tuvieron que hacer rollback. Si Instagram se manda esa, ¿por qué yo no me puedo equivocar? Eso ya te baja la exigencia irreal.
En lo práctico, me gusta mucho el dependency map (mapa de dependencias): módulos, arquitectura, equipos. Visualizar dependencias te muestra lo que no viste. En un proyecto para reducir llamadas rediseñamos un proceso, todo perfecto… pero nos olvidamos del equipo que enviaba mails de confirmación. No se mandaban, y a los dos días explotaron las llamadas: “no me llegó el mail”. Ese mapping de sistemas y equipos ayuda a prevenir errores.
Después, cuando el error ya puede estar ocurriendo, definimos thresholds en sanity metrics en experimentos: tenés una métrica principal, pero también métricas de sanidad (por ejemplo: subo conversión pero no quiero destruir revenue o attachment). En proyectos sensibles definimos umbrales: “hasta 1% abajo lo tolero, menos no”. Eso alinea a todos para mirar lo mismo y frenar rápido.
Y otra herramienta clave: la Stop the Test Metric. Si una métrica cae, por ejemplo, más de un 5%, no se pregunta a nadie: se frena el test. En empresas grandes esto evita reuniones eternas mientras seguís rompiendo cosas. El punto no es no equivocarte: es darte cuenta rápido de que existe el error. No es lo mismo caer un 5% dos horas que tres semanas.
¿Cuándo es suficiente? ¿Cuándo se para de iterar?
Depende, como toda respuesta de product manager, y para mí es costo-beneficio. Cuánto beneficio te puede dar esa hipótesis y cuánta certeza tenés de que va a darte ese beneficio. He tenido productos en los que estuve testeando un año y medio porque el costo inicial era altísimo y parecía haber una “olla de oro”. Pero llega un momento en que el costo y el beneficio dejan de cerrar y tenés que invertir esa capacidad en otra cosa.
No creo en una regla fija de “a los dos meses se mata”. Hay métricas que dicen cosas (por ejemplo en videojuegos), pero también hay historias de juegos que arrancaron tarde. Lo que sí: hay que sentarse con equipo, manager o dirección y decir: ¿cuánto queremos invertir? ¿hasta cuándo? ¿qué indicios necesito para seguir metiendo dinero?
¿Cuál fue un riesgo o error que te persiguió?
En otra empresa, había una funcionalidad que todos querían hacer y yo no le veía valor. Eran meses de desarrollo y nadie me podía explicar el impacto. Yo me planté con el libro bajo el brazo: “acá me tenés que mostrar impacto”. Peleé fuerte contra mucha gente para frenar la iniciativa… y después se hizo y funcionó.
Me costó meses darme cuenta de que fue un gran error mío. Aprendí que a veces el libro hay que guardarlo y entender el contexto. Podés decir “yo creo que esto no va”, pero si todo el mundo está alineado, a veces toca avanzar. Fue un aprendizaje duro sobre cuándo elegir batallas y cuándo soltar.
Y lo conecto con un mito: “no hay que hacer roadmap”. Decimos eso hasta que te ponés en la piel del CEO y entendés que necesita visibilidad. Los libros son herramientas, pero producto se aprende haciendo, adaptando y aceptando que te vas a equivocar.
¿Cómo equilibras intuición y datos cuando no hay tiempo o no hay data?
No todas las empresas se pueden costear una base de datos fuerte, y a veces aunque tengas data no tenés tiempo de buscarla. Entonces hay decisiones que se toman con menos data. Pero yo no iría solo con “la sentí”. Para mí vale la intuición, pero hay que saber jugarla: necesitás algún soporte, aunque sea mínimo. Hoy hay información por todos lados: un research rápido, una señal, un número. Pecamos por querer “la mejor data”, pero algo que te sostenga necesitás; si no, estás en el aire.
Yo uso mucho: “hay olor a que es por acá”. Y sí: la intuición viene de la experiencia, pero idealmente dispara una hipótesis que luego validás.
¿Con qué idea te gustaría cerrar?
Hay algo cultural y humano sobre el fracaso y cómo enfrentar situaciones difíciles que tenemos que seguir explorando. Y para mí es clave aprender en comunidad. Mucha gente me dice: “en mi empresa no se hace bien producto, no tengo de quién aprender”. Buscalo afuera. Hay comunidades de producto llenas de gente disponible y con ganas de enseñar.
Yo tuve la suerte de tener managers que me enseñaron mucho, y un día me di cuenta de que no a todo el mundo le pasa. Ahí dije: así como me llegó a mí, tengo que ayudar a otros. Pedir ayuda, salir afuera, correrse de la idea de “tengo que ser el product manager perfecto” te permite crecer.
La conversación con Jesica nos deja una lección fundamental de pragmatismo y resiliencia. El verdadero seniority en producto no se demuestra cuando todo va bien, sino en la capacidad de mantener el foco y la calma cuando las incógnitas nos rodean. Jesica nos ha recordado que el riesgo cero no existe y que intentar alcanzarlos es el camino más rápido hacia la parálisis. Lo valioso no es tener todas las respuestas antes de empezar, sino tener los rituales adecuados para detectar riesgos a tiempo y la valentía para decir basta al perfeccionismo en favor de aportar valor real. Al final, gestionar producto no trata de no equivocarse nunca, sino de saber corregir rápido, decidir qué batallas no pelear y aprender a navegar la incertidumbre con decisión.
Un fuerte abrazo y os espero en el mundo real.