Reinventarse a los 34: Mi primer paso como PM

A los 34 años decidí volver a desafiarme.
No porque estuviera perdida, ni porque no tuviera un camino recorrido. Todo lo contrario. Fue justamente el haber recorrido distintos caminos lo que me llevó a entender que todavía podía elegir uno nuevo.

Durante mucho tiempo creí que estudiar una carrera universitaria marcaba el fin de una etapa, la de aprender, como si después solo quedara trabajar y especializarse. Hice cursos, asistí a capacitaciones, pero no imaginaba —o tal vez no me permitía imaginar— que reinventarse era una posibilidad real, tangible, necesaria.

En mi tránsito laboral descubrí que había cosas que me apasionaban… y que ni siquiera sabía que me apasionaban: el trabajo en equipo, la búsqueda constante de soluciones, el acompañamiento a otros.
Conocí el rol del liderazgo casi por casualidad, y me enamoré. Fue un lugar donde me sentí plena, útil, valorada. Donde empecé a construir una identidad propia, no solo profesional, sino también personal. Ahí comprendí que no basta con hacer bien una tarea, sino que también importa cómo acompañamos a otros a hacer la suya.

Hoy arranco una nueva experiencia: un hackathon. Pero esta vez, con una diferencia.
Ya no voy a acompañar al equipo desde afuera. Hoy soy parte activa del equipo, y esta vez como Product Manager.
Y sí, puedo decirlo con confianza: me siento cómoda con este nuevo rol. Como si me hubiera probado una prenda nueva y descubriera que me queda bien, que se amolda a lo que soy, a lo que viví y a lo que tengo para ofrecer.

Este camino como PM lo transito con todo lo que aprendí: la escucha, la empatía, el análisis crítico, la mirada en el todo y en el detalle. Pero también con la humildad de saber que aún me queda mucho por aprender.

Hace poco, un compañero me compartió una reflexión que me tocó profundamente. Me dijo:

“A veces lo que falta en los hackathones es un líder técnico. Porque los PM no siempre tienen el conocimiento técnico necesario para ayudarnos”.

Y lo entendí. Me puse en su lugar y reconocí que tenía razón.
Pero en lugar de defenderme, elegí pensar. ¿Qué hace realmente un Product Manager? ¿Asignar tareas, organizar flujos, sacar métricas? Claro que sí. Pero, ¿es solo eso?

Le respondí algo que resume mi forma de entender este nuevo rol:

“Tranquilo, no voy a decirte qué trabajo tenés que hacer. Mi tarea será ayudarte a reflexionar sobre tus decisiones, cuestionarlas con respeto, y acompañarte para que vos decidas cómo trabajar. Los líderes técnicos no siempre vienen con una etiqueta. A veces emergen naturalmente, y el equipo los sigue por respeto, admiración o por la seguridad con la que comparten su conocimiento”.

Estoy dando mis primeros pasos como PM, y ya aprendí algo fundamental: los roles no definen a las personas, las personas redefinen los roles.
A veces, para crear valor en un equipo, hay que romper con los imaginarios sociales de lo que “debería ser” un profesional, y reconstruirlo desde la colaboración, la empatía y el objetivo común.

Hoy empiezo este nuevo camino con la certeza de que no estoy dejando atrás lo que fui. Estoy integrando todo lo que aprendí, para ser más.
Más útil. Más presente. Más humana.

🚨 Lo que nadie te dice sobre construir una fintech desde cero

Errores, aprendizajes y verdades incómodas desde adentro del MVP “Ahorro e Inversiones”

¿Creés que hacer una app de inversiones es solo cuestión de “scrums” y MVPs funcionales? Spoiler: nuestro MVP no funcionó.

Y eso está bien. Este proyecto fue una práctica intensiva de cinco semanas, con el objetivo de aprender. Y aprendimos. A veces a la fuerza, muchas veces en el caos, pero con conciencia crítica y compañerismo.

Este post no es un éxito para LinkedIn.

Es una bitácora real: lo que intentamos hacer, lo que logramos construir, lo que se cayó a último momento y lo que nos queda como base para seguir creciendo.

🎯 ¿Qué fue “Ahorro e Inversiones”?

Un proyecto colaborativo para desarrollar un MVP de una app fintech.

Durante cinco semanas, un equipo multidisciplinario (PM, UX, devs, QA y más) intentó diseñar una experiencia de ahorro e inversión amigable, con foco en educación financiera, personalización e integración de comunidad.

Todo en un marco experimental:

❌ sin métricas duras

❌ con planificación tentativa

❌ sin promesas de producto terminado

📍 Lo que se hizo (y lo que no)

✅ Logros reales

• Se construyó un MVP navegable con funcionalidades clave: autenticación, dashboard gamificado, sección de inversiones y foro.

• Hubo trabajo colaborativo entre disciplinas, con herramientas como Notion, Figma y Trello.

• Se planteó una propuesta de valor coherente basada en educación financiera y comunidad.

• Se realizaron dinámicas de integración y trabajo en equipo para fortalecer la colaboración.

• Se llevó a cabo una retrospectiva final que permitió reflexionar en conjunto sobre errores, aciertos y aprendizajes.

❌ Lo que no funcionó

• La organización inicial se desdibujó: los sprints no se cumplieron y las tareas se volvieron reactivas.

• El producto no pudo validarse técnicamente: la programación presentó fallas críticas al final, lo que impidió testear funcionalidades completas.

• No hubo métricas ni KPIs que permitieran evaluar el impacto o medir la calidad de forma objetiva.

🧭 Liderazgo en modo aprendizaje

El liderazgo en este proyecto fue horizontal, rotativo, adaptativo.

No hubo jefes, pero sí referentes. Y aunque no se cumplieron todos los rituales ágiles, sí hubo algo clave: la voluntad de escuchar, corregir y acompañar.

🗣 “Los líderes que se adaptan en lugar de imponer, son los que construyen confianza duradera.”

— Simon Sinek

🧪 Metodología: Scrum, pero con barro

Se intentó seguir un enfoque ágil: sprints, backlog, daily meetings.

En la práctica, la dinámica fue más caótica. Las tareas se desbordaron, el tiempo fue poco, los roles se mezclaron.

Pero también eso enseñó algo:

📌 “Los marcos ágiles no son recetas mágicas. Son marcos.

Si no hay alineación ni claridad, lo ágil se convierte en improvisación con post-its.”

— Jeff Sutherland, creador de Scrum

🔎 Investigación y diseño: la teoría vs la práctica

Se hizo una breve investigación de mercado, se validaron algunas ideas con entrevistas, y se diseñaron flujos UX coherentes.

Pero la realidad del tiempo y los recursos chocó con la teoría:

• Los prototipos estaban bien pensados, pero muchos no llegaron a implementarse.

• El onboarding personalizado y las recomendaciones con IA se pensaron… pero no se probaron.

• El foro funcionaba, pero sin usuarios reales para activarlo.

🧠 Aprendizajes con sabor a reality check

1. Planificar no es suficiente
   Tener Notion bonito no garantiza organización. La ejecución es donde se prueba el liderazgo.

2. Construir comunidad no se programa en React
   Se necesita contenido, moderación, interacción real. No alcanza con un botón de comentarios.

3. Falló el código, no el equipo
   Las fallas técnicas no opacaron la calidad del equipo humano. Y eso, en proyectos reales, vale oro.

4. El aprendizaje fue el producto
   No tener un MVP funcional no fue un fracaso. Fue el resultado de un proceso real de aprendizaje.

5. Reflexionar juntos fue clave
   La retrospectiva final nos ayudó a entender desde dónde veníamos y hacia dónde podríamos mejorar. Hablamos con sinceridad, empatía y compromiso.

📚 Referencias que cobraron sentido

• “The Lean Startup” – Eric Ries

  “El fracaso temprano y frecuente es el combustible del aprendizaje.”

• “Scrum: Doing Twice the Work in Half the Time” – Jeff Sutherland

  “Un backlog sin propósito es solo una lista de tareas pendientes.”

• PMI - Project Management Institute

  La gestión de proyectos debe adaptarse al contexto, incluso si eso implica aceptar que el éxito no siempre es la entrega de un producto terminado.

🧩 Reflexión final

El MVP de “Ahorro e Inversiones” no llegó a estar completo.

Pero construimos algo: un equipo con visión crítica, con ideas que merecen una segunda vuelta, y con la humildad de decir "esto no funcionó, pero aprendimos cómo hacerlo mejor."

“El verdadero aprendizaje ocurre cuando hay espacio para equivocarse sin miedo.”

— Brené Brown

 

Hablemos de plata: ¿por qué sigue siendo tabú el salario en IT?

A veces me pregunto si realmente la gente en IT teme decir cuánto gana o si, en realidad, tememos las represalias de las empresas. Todos hemos estado en esa situación incómoda en una entrevista cuando nos preguntan: "¿Cuál es tu remuneración pretendida?" y sentimos que cualquier respuesta es un error. Pido mucho, me descartan. Pido poco, me estoy regalando. Y luego la gran duda: "¿No me llamaron por caro o por barato?". Porque, claro, adivinar el número mágico es parte del proceso, ¿no?

Lo curioso es que la transparencia salarial podría ahorrarnos este mal trago y también beneficiar a las empresas. Imaginemos un escenario donde los sueldos estén claros desde el principio: las personas sabrían a qué posiciones postularse y las empresas no recibirían cientos de CVs de personas que, al final del proceso, descubrirán que la oferta económica no es lo que esperaban. ¡Menos desgaste para todos! Pero claro, ¿quién quiere eficiencia cuando podemos seguir con la tradición del secretismo?

📈 Oferta y demanda: una ley universal que ignoramos en IT

La economía nos ofrece una teoría muy básica pero aplicable a casi cualquier mercado: la ley de oferta y demanda. En pocas palabras, si hay alta demanda de un bien o servicio y poca oferta, su precio sube. Y lo mismo ocurre al revés: si hay mucha oferta y poca demanda, el precio baja.

Aplicado a los salarios en IT, esto significa que si un rol es muy demandado y hay pocos profesionales capacitados, el salario debería ser alto. Por otro lado, si hay muchas personas para una misma posición, los salarios tienden a estancarse. El problema es que esta dinámica no siempre es transparente. Sin información clara sobre sueldos, los empleados no pueden evaluar correctamente su valor en el mercado y las empresas pueden aprovechar esta opacidad para mantener los sueldos artificialmente bajos. Pero hey, mejor sigamos jugando a las adivinanzas.

🚨 El problema de la falta de información

Cuando las empresas no publican rangos salariales, generan un mercado laboral con asimetría de información, otro concepto económico clave. Esto significa que una parte (el empleador) tiene más información que la otra (el candidato). ¿El resultado? Negociaciones desiguales y empleados subvalorados.

Es cierto que no todos los salarios pueden ser iguales. Una reclutadora me dijo una vez que las diferencias salariales dependen de las habilidades de cada persona, lo cual tiene sentido. Pero el problema aparece cuando los salarios no se alinean con las responsabilidades. He visto casos en los que alguien con habilidades técnicas superiores gana menos que otra persona con menor experiencia, simplemente porque uno supo negociar mejor que el otro. ¿Eso es justo? Bueno, supongo que la habilidad para regatear también cuenta.

🌟 Transparencia: una solución simple con grandes beneficios

Pensemos en los beneficios de la transparencia salarial:

• 👩‍🎓 Mejor toma de decisiones: Los profesionales sabrían si un puesto les interesa sin perder tiempo en procesos largos.

• 💡 Menos rotación: Un estudio de Payscale demostró que la transparencia reduce la rotación de empleados en un 30%.

• 📅 Mayor equidad: Se reduciría la brecha salarial de género y otras desigualdades.

• 🎓 Mercado laboral más eficiente: Si aplicamos realmente la ley de oferta y demanda, los salarios serían más competitivos y justos.

🌐 Un futuro donde hablar de sueldo sea normal

Poco a poco, algunos países están avanzando en este sentido. En Nueva York y California, las empresas están obligadas a publicar los rangos salariales en sus ofertas laborales. En Europa, la tendencia también crece. Si estas iniciativas funcionan, podríamos ver un cambio global que beneficie tanto a empleados como a empleadores. Aunque claro, seguirá habiendo empresas que prefieran la vieja estrategia del "dinos tus expectativas y veremos si te pagamos lo mismo que al resto o te damos una sorpresa (y no de las buenas)".

Hasta entonces, la mejor herramienta que tenemos es hablar. Hablar entre colegas, compartir información y exigir transparencia. Porque al final del día, saber cuánto ganamos no debería ser un tabú, sino un derecho.

🤔 Reflexión final: ¿y tú, cuánto vales?

Si hoy descubrieras que alguien en tu equipo, con las mismas responsabilidades, gana significativamente más que tú, ¿qué harías? ¿Seguirías en silencio? ¿Lo confrontarías? ¿Te replantearías tu valor en el mercado?

💡 La transparencia es poder. Y el conocimiento es la mejor herramienta para exigir lo que mereces.

📢 Si seguimos ocultando la información salarial, ¿realmente estamos ayudando a mejorar el mercado laboral o solo perpetuamos un sistema desigual? Dejame tu opinión en los comentarios. ¡Hablemos de esto! 📝🌟

Job misclassification

 

Junior por elección o por conveniencia: cuando tu trabajo habla más que tu cargo

“Siento que a veces leer las experiencias de otros ayuda a saber que no estamos solos.” Y así empieza esta historia. Una historia que podría ser la tuya, la mía o la de cualquiera que alguna vez usó la etiqueta "junior" más tiempo del necesario.

La gorra de “junior” y el peso simbólico del título

Es normal —y hasta saludable— empezar una carrera con una gorra que diga “soy junior”. Es una etapa de aprendizaje, de adaptación, de ensayo y error.
Pero llega un momento en el que esa gorra ya no ajusta. Empezás a asumir otras tareas, a tomar decisiones, a resolver problemas complejos… y te das cuenta de que creciste.
El problema es que muchas veces ese crecimiento no se traduce ni en el título, ni en el salario, ni en el reconocimiento.

 - El caso personal (que no es tan personal)

En uno de mis primeros roles como QA, me involucré con pasión. Desde el día uno, hice más de lo que el rol “junior” pedía. Me anticipaba a los problemas, proponía mejoras en los procesos, acompañaba a clientes y facilitaba la comunicación del equipo. Mi PM me dijo una vez:

“No deberías ser junior. Hacés más que muchos seniors.”

Y aunque lo dijo como un halago, con el tiempo entendí lo que realmente significaba: hacía más, pero seguía cobrando menos.

Años después, lideré un proyecto móvil que nadie lograba estabilizar. Me convertí en una figura clave. ¿El resultado? Me ascendieron... a Junior Level 2.
¿La causa? Me habían visto como “Open to Work” en LinkedIn.
¿El título real que debía tener? Posiblemente QA Lead.
¿El cargo que figuraba en el sistema? El de siempre.

Y no era solo mi percepción. Compañeros me preguntaban por qué, si yo lideraba procesos, facilitaba decisiones y explicaba funciones a otros, seguía siendo “junior”.

🧐 La teoría que explica lo que vivimos

La situación tiene nombre: desalineación entre responsabilidades, habilidades y reconocimiento formal.
En teoría organizacional, esto se conoce como job misclassification, y es más común de lo que parece en la industria del software.

Según un informe de LinkedIn Talent Insights (2023), muchos equipos tech optan por contratar juniors como una forma de reducir costos, con la promesa implícita de que “más adelante viene el crecimiento”. Pero sin políticas claras de evaluación ni trayectorias profesionales definidas, muchos terminan estancados con un título que ya no los representa.

Y acá entra el problema: el trabajo en software es dinámico, pero los cargos suelen ser estáticos.

💻 ¿Qué implica ser junior realmente en IT?

Un rol junior en QA o desarrollo no se define solo por el tiempo de experiencia, sino por la autonomía, la complejidad de las tareas que maneja y la capacidad de análisis frente a problemas.

Pero en la práctica, muchas veces:

• Se espera que un junior “resuelva como un senior”, sin ser molesto.

• Se les da ownership sin acompañamiento.

• Se premia la iniciativa con… más tareas, no con reconocimiento.

🔬 Reflexión final: ¿junior por elección o por conveniencia?

Quizás alguna vez elegiste ser junior para aprender, y eso está bien.
Pero cuando llevás tiempo resolviendo problemas, proponiendo soluciones, liderando proyectos y ayudando a otros, y aún así seguís con un cargo que no refleja eso… entonces ya no es una elección. Es conveniencia ajena.

Como dijo Lisa Crispin, referente en testing ágil:

“Cuando asumimos responsabilidades que impactan en el producto, no somos solo testers. Somos impulsores del valor. El título es lo de menos. Lo que importa es lo que hacemos.”

 

---

Lo viejo y lo nuevo

 

Fuerzas instituidas e instituyentes en el desarrollo del Software

Cuando empecé a sumergirme en el mundo de la gestión de proyectos, una pregunta me dio vueltas en la cabeza desde el inicio: ¿Puede un PM ser realmente ágil si su equipo no lo es?

Esta duda me persigue cada vez que la palabra “cambio” aparece en escena. Durante la facultad, en una materia llamada Instituciones y los grupos en la universidad de Humanidades, aprendí dos conceptos que me marcaron profundamente: lo instituido y lo instituyente. Desde entonces, los aplico como lentes para observar cada proyecto o proceso en el que participo.

Para explicarlo mejor, lo traigo al mundo IT:
En muchos proyectos existen formas de trabajo instituidas, heredadas de mandos anteriores o rutinas que, si bien no son eficientes, son conocidas. Y lo conocido da seguridad. Por eso se sostienen. Es la famosa zona de confort organizacional, donde se privilegia evitar riesgos por sobre innovar.

Ahí es donde entra en juego lo instituyente: aparece un nuevo PM, o un CEO con hambre de mejora. Llega con visión de cambio, con ideas de automatización, optimización de riesgos, y foco en el éxito del producto. Es ahí donde choca lo nuevo con lo viejo. La intención de transformar contra la fuerza de lo ya establecido.

Y, por supuesto, ahí entra la palabra mágica: agilidad.

---

“Somos ágiles. Hacemos daily todos los días.”
— Escuchado en una reunión donde los entregables se gestionaban en una planilla de Excel llamada Urgente_final_2_real_ahora_SÍ_v2

---

La agilidad está de moda. Scrum, Kanban, XP, Design Thinking… todos quieren sumarse. Los post-its se reproducen como si fueran stickers de WhatsApp.
Pero hay una verdad incómoda: 🌟La agilidad no es un rol. Es una cultura.

Y si el equipo no la comparte, el PM se convierte en una especie de actor secundario con acceso limitado a Jira.

El PM que quiere, pero no puede

Podés tener al PM más comprometido del universo. Que arma retrospectivas en Miro, planifica sprints con criterio, y celebra entregas con GIFs de perritos en Slack.
Pero si los desarrolladores no se hacen cargo del producto, si QA vive apagando incendios, y si Producto cambia las prioridades como quien cambia de pestaña…
Houston, tenemos un waterfall con daily.

¿Qué dice la teoría?

Martin Fowler, uno de los firmantes del Manifiesto Ágil, lo resume así:

“Being agile is not about following a recipe, it’s about continuous learning and adapting.”

Y para que eso ocurra, todos tienen que estar en sintonía.

Ejemplo real:

Una startup implementó Scrum. Todo pintaba bien… hasta que los devs se negaron a participar de las retrospectivas (“eso es pérdida de tiempo”) y los stakeholders exigían releases “para ayer”.

😓Resultado: PM frustrado, equipo estresado, y el Scrum Master meditando en la cocina.

Pero sería ingenuo decir que con eso alcanza. Porque cambiar lo instituido no es un proceso mágico. Requiere trabajo, paciencia, acompañamiento, entrenamiento y —sobre todo— convicción.
Cuando se introduce agilidad, muchas veces aparece resistencia, confusión, entorpecimiento. Y ahí, el cambio se vuelve costoso. Tanto, que algunas empresas prefieren dar marcha atrás. Volver a ese método anterior que no era ideal… pero al menos, funcionaba.

Reflexión final

Si tu entorno no permite experimentar, si equivocarse se castiga, si la planificación es solo una excusa para imponer fechas, entonces no sos ágil.

Sos waterfall con daily👀

De QA a Product Manager

 

De QA a Product Manager: ¿Ascenso natural o cambio radical?

Hace un tiempo, me hice esta pregunta: ¿Un QA puede convertirse en un gran Product Manager o es un salto demasiado grande?

Mi camino no empezó en gestión de producto. Fui líder de equipo en operaciones y luego trabajé como QA manual, dos roles que parecían estar lejos de la estrategia de producto. Pero cada experiencia me estaba preparando para ser un PM con una visión más completa y profunda del proceso de desarrollo.

Como QA Manual: Aprendí a cuestionar todo. No solo me dedicaba a encontrar errores, sino que me enfocaba en entender el porqué detrás de cada parte del producto. En mi internship, uno de los QA Senior que nos enseñaba mencionó a Michael Bolton y su frase me marcó profundamente "Testing no es solo encontrar bugs, es cuestionar suposiciones." – Michael Bolton

Este enfoque cambió mi perspectiva por completo. Aprendí que el verdadero valor del QA no está solo en detectar fallos, sino en cuestionar las decisiones y las suposiciones subyacentes del producto. Testing no es solo un proceso de validación, sino de aprendizaje constante. Esta idea se convirtió en la base de mi enfoque como Product Manager.

Priorizo con base en impacto y riesgos reales, no solo en deadlines,

Durante mi tiempo como QA, uno de los problemas más comunes era la falta de claridad en los requerimientos. Esto no solo dificultaba las pruebas, sino que también llevaba a errores costosos cuando se implementaba la funcionalidad de manera incorrecta o incompleta. Como PM, esa experiencia me enseñó a priorizar la claridad en los requerimientos desde el inicio. Por ejemplo, cuando los requisitos no definen bien las expectativas de usabilidad, como en una función de registro que no especifica cómo deben gestionarse los errores de entrada, puede generar una experiencia de usuario frustrante. Esto puede no ser un "bug", pero sin duda es un riesgo de usabilidad que debe abordarse.

Entiendo a los equipos técnicos y operativos porque estuve en su lugar.

En QA, me enfrentaba a la frustración de trabajar con requerimientos incompletos o ambiguos, lo que resultaba en test cases que no cubrían todos los aspectos del producto. Como PM, puedo identificar estos vacíos en la documentación y evitar que se repitan. Por ejemplo, si un equipo de desarrollo recibe una especificación vaga sobre el flujo de pago en una aplicación y no hay detalles sobre la validación de tarjetas, esto puede generar errores graves. Mi experiencia me ayuda a comunicar la importancia de una documentación clara y a asegurar que todos los involucrados tengan la misma visión del producto.

Valoro la calidad desde el inicio, no como una fase final del desarrollo.

Como QA, aprendí que los problemas de calidad no son algo que se pueda dejar para el final. El desarrollo de software no es una cadena de montajes en la que los defectos pueden ser corregidos en etapas posteriores, sino que deben ser identificados y abordados desde el principio. En proyectos donde los requerimientos no estaban claramente definidos o los aspectos de usabilidad no se especificaban correctamente, los errores no solo afectaban la funcionalidad, sino que también perjudicaban la experiencia del usuario. Esta experiencia me enseñó que, como Product Manager, debo asegurarme de que la calidad esté integrada en cada fase del proceso, desde la planificación hasta la implementación. Además, como líder de hackathones, experimenté de primera mano cómo la falta de claridad o los detalles insuficientes pueden generar caos y errores, especialmente cuando el tiempo es limitado. Ahí, la calidad tuvo que ser asegurada desde el inicio, incluso en condiciones de presión, para garantizar que las soluciones fueran funcionales y de alto impacto. Detectar problemas de usabilidad, diseño o lógica en etapas tempranas evita grandes retrasos y costosos reworks en el futuro. La calidad debe ser un compromiso constante, no un parche final.

🌟"Cada paso en tu camino te prepara para el siguiente desafío. Ser QA no es solo encontrar errores, sino aprender a cuestionar, entender y mejorar. Esa mentalidad es la que te convierte en un gran Product Manager. Confía en tu experiencia, porque cada lección te acerca a tu próximo gran logro."