GOOD PM / BAD PM | Emma & Valeria PRODUCT LEADERS @Factorial

La product review cuando alguien nos pregunta: ¿qué es la product review de Factorial? ¿Qué, qué respondéis?

Emma, ¿cuál es tu GOOD PM versus BAD PM?

Eh, tiene que crear una solución al-

Tiene que crear una solución. ¿Cuál es el tamaño ideal de un equipo? En un pódcast de Jordi y yo que hablamos de la figura del PM, que concretamente Jordi decía: "Pero a ver, pero cuál es el deliverable de un PM? ¿Cuál es el output propiamente?", ¿no? Te indignó mucho.

Es que era una conversación de barra de bar .

Entonces, ¿cuál es el rol del PM, Emma?

Pues al final es, es la persona que--.

Hay como una imagen del PM como un trabajo bastante sencillo, gratificante, pero hay horas y horas de trabajo detrás, lo que decíamos de mover, ¿no? De que las cosas pasen y eso es dedicación. O sea, no puedes esperar en plan: bueno, aquí está la priorización y ahora ya que las cosas pasen.

¿Puedes explicar Valeria el caso de proyectos, que es un caso bastante espectacular de crecimiento de un producto que va de cero a millones de euros en ARR? Es que a mí me cuesta imaginar que alguien le cuente de eso y no le brillan los ojos.

Bienvenidos a la Tertulia de Itnig.

Bienvenidos una semana más al pódcast de Itnig. Yo soy Bernat Parrero y hoy estoy con Emma y Valeria, dos líderes de producto. ¿Qué tal? ¿Cómo estáis?

Bien. Muy bien.

Muy bien.

Muy bien. Muy bien. Bueno, muy bien. No sé, tengo la cabeza frita. Yo no sé vosotras, pero llevamos dos días de product review ,que son muchas horas, ¿no? Eh, viendo muchos equipos y muchos, muchos proyectos- ...estamos trabajando. Eh, y es intenso, ¿no? Muchas discusiones.

Llevamos dos días, os quedan dos más.

Nos quedan dos más. Eh, teníamos en el calendario esta charla y a mí casi se me olvida. Menos mal que lo habéis dicho.

No sé por qué .

Pero oye, no, me, me apetece mucho, eh, entender-- lo que me, me interesa mucho entender cómo veis vosotras desde vuestra posición. Vosotros lideráis tú dominio de operaciones, que es un superdominio ya, está compuesto por, pues por tres subdominios, eh, y tú, Valeria, que, que lideras finanzas, ¿no?

Em, ¿cómo veis la organización de factorial? Eh, y además ahora que lo tenéis fresco y veis todos los equipos de producto, ¿cómo, cómo, cómo veis el equipo de producto después de ver los dos días de product review de Factorial a día de hoy? ¿Y cómo lo comparáis con igual hace un par de años?

A ver, venimos sí, venimos como con toda la información en la cabeza. Ehm...

Por favor, aquí sed transparentes, ¿eh? Sabéis que aquí siempre contamos todo. Todo.

Todo. Venga, transparente.Em, vemos que hay muchas cosas, o sea, que tenemos que trabajar mucho. Tenemos que continuar trabajando en, en la comunicación entre dominios, en la comunicación con los equipos, en evitar no construir en, en silos ciertos productos porque nos pueden ayudar como a, al conocimiento, a transmitirlo.

También hay cosas muy interesantes. Hemos visto cosas, eh, que nos han gustado mucho. Ah, y luego, pues hay discusiones muy interesantes que son muy cansadas, ¿no?, que por eso igual venimos con, con ese cerebro superfrito, pero, pero que es todo como para no, para tener conversaciones igual incómodas que nos ayudan, que nos ayuden a, a cómo, eh, pivotar y cómo seguir, eh, creciendo si lo comparamos, si comparamos la organización con hace dos años a nivel de producto, em ,pues creo que ahora tenemos otros tipos de challenges que tenemos queee, que, que empezar a, a, a solucionar.

Pero creo que estamos muy ilusionados, ¿no? Y con muchas ganas de, de llevarlos a cabo.

Sí, a ver, yo creo que, que hace dos años, eh, teníamos otros problemas, ¿no? Era una organización donde cada equipo estaba más focalizado en lo suyo. Ahora seguimos teniendo silos, siempre es difícil romperlos, pero creo que mucho menos que hace dos años. Y luego tenemos un, un criterio muy claro de lo que es calidad y de cuándo no es suficiente.

Mhm.

Hace dos años había muchos equipos trabajando de manera muy separada en, en sus pequeños silos replicando muchas veces funcionalidades y patrones distintos y creando mucha inconsistencia dentro de la plataforma. Creo que eso ya no pasa, o al menos no pasa tanto. ¿Es perfecto?

Pues no. Eh, tenemos todavía mucho por hacer, pero creo que, que hemos mejorado mucho en esto, que los equipos son más, más, eh, más maduros. Y además, e-en este caso las product reviews, que ya llevamos unas cuantas, em, iteraciones, nos ayudan mucho a entender, eh, todos los dominios, como dónde están todas esas relaciones entre, entre los distintos equipos y asegurarnos de que esto se va mitigando.

Y luego también veo que los equipos ya, mmm, hace un año la product review era un drama y ahora ya entienden que una vez al trimestre tienen que mostrar lo que, lo que han estado trabajando, lo que van a trabajar y que nosotros vamos a darles feedback y eso va a ayudarlos a todos a ser mejor organización.

La product review cuando alguien nos pregunta: ¿qué es la product review de Factorial? ¿Qué, qué respondéis?

Emmm, pues depende de quién me pregunte.

Bueno, es el momento donde explicamos qué es lo que han, ehm, entregado los equipos, el impacto que ha tenido, qué ha salido bien, qué ha salido mal, ¿no? Porque también hacemos un poco ese-- pensamos pues qué cosas no han salido, por qué no han salido, ¿no? Pues por problemas que nos encontramos por el camino en, en producto.

Y luego, qué, qué pensamos que va a ser lo siguiente, ¿no? En el-- porque la product review tiene una parte de product review, pero también tiene la parte de kickoff, ¿no? Es donde explicamos qué es lo que vamos a hacer en el siguiente quarter.

Mhm. Es- ...una mirada atrás, ¿no? De cómo-

Eso es

...ha ido el quarters y luego cuál es el plan de-

Del siguiente

...para adelante, para el futuro.

Y, mmm, y en impacto, pues hablamos de, del impacto de métricas, que para nosotros es la RR, de cuánto estamos, eh, eh, ayudando, cuánto estamos contribuyendo a la compañía, ¿no? En cada de los-- en cada uno de los productos y en cada una de las, de, de las features o cada uno de los de-- sí, de los improvements que hemos lanzado durante, durante el quarter.

Y en el kickoff igual, ¿no? Que es lo que esperamos o como s-- ah, qué métricas, que en este caso es ARRA igual , eh, cómo esperamos impactar esa métrica con las decisiones o con la priorización que, que hemos llevado a cabo los equipos durante, durante el quarter anterior.

Nosotros a mis-- a nuestros equipos siempre les explicamos que es una especie de pitch to investors, ¿no? Cada equipo ha estado trabajando durante un quarter en ciertas funcionalidades y decide qué-- bueno, explica qué impacto ha tenido y qué impa-pacto espera con las siguientes funcionalidades. Eh, nosotros en la product review al final vemos lo que todos los equipos están haciendo y hay veces que, eh, las prioridades da-- dentro de un equipo son muy importantes para ese equipo y el scope que tienen, pero dentro del, del contexto de Factorial completo, pues dejan de serlo.

Entonces, por eso damos ese mensaje de que algunas veces que ha bi-- ha habido ocasiones que después de una product review, el scope entero de un equipo cambia o el roadmap cambia. Entonces, es una manera de: "Oye, hemos invertido esto, este tiempo, que al final es dinero, en unas funcionalidades, van-- han tenido este impacto o no, y debemos seguir invirtiendo o no".

Ese es un poco el mensaje que intentamos dar.

Hay gente que dice que claro, en, en una hora, porque más o menos dura una hora una product review, debería durar-

Debería No se me da muy bien.

No es fácil, ¿no? No es fácil. Eh, que, que es difícil hacerte la imagen de toda la profundidad de un problema, ¿no? Pues yo qué sé, pues, eh, pues gestión del control horario, ¿no? O-

Sí

...o pues yo qué sé, con, pues compensaciones, ¿no? Modelos de compensaciones y tal, ¿no? O integraciones con software de payroll del mundo, ¿no? O sea, es difícil hacerte en una hora una visión de cómo va o no va, ¿no? Eh, hay gente que dice esto.

Yo no estoy de acuerdo. Yo creo que se nos da muy mal ser concisos cuando explicamos cosas, porque tú puedes explicar algo en dos minutos o en dos horas y es lo mismo, pero la gente tiende a dar muchas vueltas sobre el mismo tema en lugar de realmente contestar.

¿Hasta qué punto es más importante una product review o en un pitch, porque al final es muy parecido, el storytelling, la capacidad comunicativa versus la realidad subyacente?

Claro.

Bueno, eso es, es-- realmente el storytelling al final lo es todo, porque no solo es lo que haces sino cómo lo vendes. Entonces, nos ha pasado en el pasado de, de tener equipos que han presentado mejor de lo que lo han hecho y equipos que han hecho cosas bien, but no lo han sabido presentar. Y también esto, cuando en la, en las product reviews normalmente primero presentan los, los equipos y tenemos una conversación y damos feedback, luego se va el equipo y tenemos una discusión de directores.

Y ha pasado de cerrar las puertas y decir: "Oye, este equipo, eh, lo ha explicado muy bien, pero realmente no está fi-- no está funcionando, que sepáis que lo sabemos y lo estamos arreglando." Y lo contrario-

El director, el director mismo dice: "Este equipo lo ha explicado muy bien, pero en realidad no hay nada"

Y lo contrario también, de vale, este no lo ha sabido explicar, pero realmente tal. Al final somos conscientes de lo que tenemos dentro de nuestra casa o deberíamos serlo.

Mmm.

¿Y qué pasa con-- cuando hay una mala product review?

Que hay cambios.

¿De qué tipo?

Sí.

Depende de la razón de la, de la mala product review. Hay veces que es que el equipo no funciona, entonces hay que hacer cambios en el equipo, hay que añadir nuevos miembros, eh, hay que-- normalmente es cambiar cierta dinámica. Eh, hay veces que se puede trabajar con el equipo existente, pero hay veces que, que no y, y se necesita, pues eso, contratar a alguien o, o hacer partir equipos y dividir esos miembros en otros dos equipos a ver si funciona la dinámica, depende.

Hay veces que hay que cambiar scope. Si lo que-- si el problema no es el equipo en sí, sino las funcionalidades en las que están trabajando, pues hay que cambiar el roadmap. O incluso el, el dominio, ¿no? Están trabajando en un dominio en-- eh, nos pasó con el equipo de, de documents hace, hace tres quarters, ¿no? Eh, decidimos que pu-- necesitaban trabajar mejor en las partes de, de nóminas, de posnómina y los cambiamos de dominio directamente y les cambió todo el roadmap.

Depende.

Sabe, cre-creo que al final no podemos como, em, esperar a que todo pase en la product review, ¿no? Es decir, a lo largo del quarter ya vamos viendo cosas, ¿no? Y los equipos también. Es decir, no solamente con los resultados, sino pues con los proyectos o connn las priorizaciones que han hecho.

Ah, entonces, al final la product review es el resultado, pero tampoco hay sorpr-- o sea, hay sorpresas, no hay sorpresas, porque al final es un ejercicio constante en el que estamos con los equipos.

Bueno, a veces hay bastantes sorpresas, ¿eh? Bueno, al menos para mí. Claro, yo no, no estoy en el día a día de los eq-- de to-todos los equipos, algunos sí, pero...

A ver, si, si los directores hemos hecho el trabajo correctamente, no debería haber sorpresas.

Claro.

En esta, por ejemplo, yo me he llevado una pequeña desilusión, ¿no? Ha habido un equipo que no ha salido de la product review lo bien-- lo suficientemente bien que, que esperaríamos, ¿no? Y, y te das cuenta también al ver un poco la, pues eso, todo el contesto y, y, y hacerlo desde ese checkpoint de alguna manera. Y mi trío entero de directores hemos salido un poco flagelándonos, ¿no?

De: "Oye, no lo hemos hecho bien, lo tenemos que hacer mejor. Aquí hemos hecho algo que no, no, no lo hemos hecho suficientemente bien."

Desde aquel punto, dónde acaba y dónde empieza la responsabilidad del equipo y del director. Este es otro gran tema, ¿eh? Te estoy preguntando todos los grandes temas -

Sí

...que siempre son motivo de discusión.

Ah, a ver, yo creo que

La responsabilidad es nuestra. O sea, nosotros estamos-- o sea-

¿Quién es "nuestra"? ¿Qué quién es "nuestra"?

Los directores. O sea, creo que llegar a una product review donde, eh, no se haya priorizado bien, donde no haya habido un impacto, donde, donde no haya un plan para cambiar eso, en esa-- es porque ha faltado-- falta algo durante el, durante el proceso.

Puede, puede haber muchas razones. Es decir, puede haber, eh, eh, momentos en los que los equipos sean nuevos, ¿no? Y entonces, pues esté costando que haya cohesión entre los miembros y, y todavía no esté fluyendo, entonces todavía no estén teniendo el impacto esperado. Lo mismo nos puede pasar con los directores, ¿no?, Que ha habido cambios, entonces, eh, también hay un tiempo, ¿no?

Pero, pero creo que, que no podemos-- o sea, que nosotros tenemos que ser conscientes de lo que está pasando en los equipos y saber levantar la mano durante el proceso. Y con respecto a ti, por ejemplo, esperar a que te encuentres una sorpresa es como tampoco nos beneficia a los directores, ¿no?

Es como... O sea, porque además n-nosotros nos llevamos un disgusto. O sea, al final, como: "No era lo que hice, Emma". No sé, es, mmm, para mí-

También hay sorpresas positivas.

Sí, también esas.

Claro.

Yo creo que aquí siempre es esa, ese balance que, que buscamos entre autonomía, ¿no? Cuánta autonomía tienes que darle al equipo y cuánta dirección le tienes que dar. Y al final, el objetivo es que sean lo más autónomos posible, que sean superautónomos, que lo hagan todo correctamente, que entue-- que entiendan dónde hay negocio, qué, qué tienen que priorizar y a por ello.

La realidad es que algunos equipos no son tan autónomos y luego hay veces que son autónomos, pero ven su árbol y no ven el bosque, y entonces los directores somos quienes nos tenemos que encargar de eso. Entonces, si un equipo no está haciendo las cosas mal, es responsabilidad del equipo y responsabilidad del director. Y yo considero principalmente mi responsabilidad.

Yo no he hecho las cosas bien, no he metido la mano a tiempo, porque si un equipo no está haciendo las cosas correctamente, tengo que intervenir esa autonomía que tienen.

¿Y dónde queda el famoso Martin Cagan y The Empowered Teams?

Pues siempre decía que si, si sale bien, eh, si a-- si algo sale bien es que todo el equipo lo ha hecho bien y si lo ha hecho ma-- algo sale mal, es culpa del PM. Pues con los directores es lo mismo. Es el siguiente nivel.

Si algo sale bien, es el equipo.

Es el equipo entero, todo el mundo, el equipo y ventas y todos.

No, bro.

No, no, porque hay muchas cosas que tienen que pasar dentro de una organización para, para que algo salga bien.

Sí.

Y vosotras ambas habéis sido individual contributors PM y en un momento dado habéis sido directoras de un área de varios PMS, ¿no? Con, con cada uno de los PMS llevando un producto. ¿Cómo cambia el rol de...? Tú, Valeria, hace poco tiempo- ...en particular, que has pasado de, de ser individual contributor PM, individual contributor a directora.

¿Q-qué, qué has notado diferente?

O sea, para mí, bueno, muchos cosas, pero, em, principalmente el rodearte de un equipo. O sea, hablábamos antes, ¿no?, cuando veníamos para acá, de la confianza, ¿no? El, del saber delegar, del confiar en que si tú no estás empujando, las cosas se van a mover, ¿no? Porque tenemos como un poco esa sensación de, de-- porque venimos de-- al ser-- al venir de individual contributor, es como, eh, la responsabilidad era nuestra.

Si el PM no estaba empujando, pues tenías que empujar. O sea, no había otra opción. Y además es un poco-

Aunque, aunque tampoco, tampoco picas código ni tampoco diseñas.

No. Empujas. Mueves fichas.

Pero empuja siempre. Empujas como directo y como PM.

Hablas, persigues, sí. Em, pero de hecho es unas, también unas cualidades, ¿no?", que buscamos en, en los PMs de Factorial, que es que hacer que las cosas pasen. No puedes esperar que la vida pase mirando, ¿no? Es como si algo no se está moviendo, tienes que estar ahí y, y apretar para que las cosas pasen, ¿no? Entonces, una de las cosas que, que yo he aprendido durante este tiempo es en que tú tienes que-- o por lo menos yo me quiero rodear y lo he conseguido.

O sea, ahora mismo estoy feliz con el equipo que, que, que he construido. PMs en los que confíes plenamente y que sepas que aunque tú no estés mirando, las cosas están pasando.

Y que si no pasan, te lo van a decir.

Y que levantan la mano. Eso es. Pero para mí es fundamental la confianza. Y la confianza para mí es construir ese equipo de, de las piezas, ehm, que para ellos son importantes y que incluso a ti te faltan, ¿no? Para poder complementarte con, con ellos. Entonces, para mí ha sido-- o sea, creo que uno de los challenges más, más, eh, difíciles que he pasado durante este tiempo, pero además bonitos, es cómo construir ese equipo, ¿no?

Y cómo darte cuenta de las personas que necesitas o que quieres tener a tu alrededor. Ah, y esos han sido como los primeros seis meses del rol en los que he estado como construyendo ese equipo. Eh-

¿Cuál es el PM para Valeria? La gente que nos escucha, ¿qué tipo de PM buscas?

Vale, yo busco, eh,

un PM que no deje, o sea, que no deje caer las cosas, que esté siempre persiguiendo, que esté siempre atento o atenta a lo que está pasando, em, que busque impacto, que no se conforme con las respuestas. Tú decías: "No picamos código." Ya, pero tampoco nos tenemos que quedar conformes con las soluciones que nos den.

Es como preguntar, cuestionar, apoyarte del equipo, ¿no? Ah, pero sobre todo quiero gente que, que sepa cuantificar el impacto que tiene. Para mí es muy importante los datos. A veces es como que doy mucha importancia, pero es como cuánto vamos a mover la aguja, ¿no?

Qué impacto vas a, vas a tener. Si fuera tu dinero, estarías invirtiendo ahí. Yo a los equipos les digo el poder que tienen con el dinero que tienen. O sea, ¿cuánto cuesta un equipo de desarrollo en Factorial? Lo-- ¿son conscientes de eso? Tienen ese poder, ¿no? Lo que decían de la autonomía. Tienen ese poder. Ostras, hay que saber Cómo, ¿no?

Cómo utilizar ese equipo para tener impacto. Y cuando hablas con PMs, por ejemplo, y llegan a ese momento en el que son conscientes del dinero que están invirtiendo y lo que está trayendo la compañía es como: "Ostras, lo estoy haciendo muy bien", ¿no? Y eso creo que es algo que para mí es superimportante, que sean conscientes, porque cuando es al contrario, cuando saben el dinero que están quemando y no están trayendo ese impacto, ahí es donde dicen: "Ostras, eh, igual no estoy haciendo mi trabajo como debería, no estoy priorizando correctamente, no estoy sabiendo qué, qué, qué tengo que desarrollar para llegar a este impacto".

Mhm.

Entonces, para mí esas cuestiones, que se pregunten esto y que estén todo el rato con eso en la mente para saber priorizar, es muy importante y yo intento que eso lo tengan supercaro en el equipo.

También gente que se busque mucho la vida en el go to market, ¿no? Porque tú eres muy, muy de calle, o sea, de, de salir a la calle, buscar clientes-

Sí, de vender.

No, no de estar ahí en la cueva.

De vender, sí. Y luego-

Y hablar directamente, o sea, que no, no te conformas con que te cuenten cómo son las cosas, vas a buscarlas.

Claro, porque, o sea, al final yo necesito entender, ¿no? Es como eso de cuestionarte: "Yo necesito entender" Entonces, necesito ir a hablar con las personas que tienen esa información. Y yo me meto en las reuniones, ¿no? O sea, yo me meto en, en-- con los clientes y les pregunto y les pregunto. Y si no entiendo, sigo: "Perdón, disculpa, no te entiendo." Como insisto, ¿no?

Hasta que tenemos como toda la información. Y luego no con uno, sino con muchos, ¿no? Para saber qué, qué, qué problemas tienen. Ah, y luego cómo hacer, ¿no? Para, para monetizar eso, ¿no? Porque al final tenemos que monetizar las cosas estamos solucionando problema, estamos aportando valor, ¿cómo vamos a monetizarlo?

Y cómo vamos, lo que decía Emma, comunicarlo antes, ¿no? O sea, es no solamente también esto lo hemos hablado de la product review, de estamos, em, haciendo un buen delivery, tenemos que comunicar a los clientes que estamos haciéndose delivery, a los clientes y a los futuros clientes que igual tienen estas necesidades y que no saben que estamos cubriendo ya esas necesidades y que pueden venir a Factorial a, a, a buscarlas, ¿no?

Y a cubrirlas.

Luego te preguntaré, tú tienes un caso de éxito en Factorial de un producto que va de cero a millones de euros de NRR.

Sí.

Ahora, luego, luego hablaremos pero antes, Emma, eh, tú hace, eh, un año o dos años, no sé cuánto tiempo lleva, un día en un pódcast de Jordi y yo que hablamos de la figura del PM-

Casi dos ya.

Eh, casi dos, ¿no? Eh, que concretamente Jordi decía: Pero a ver, ¿pero cuál es el deliverable de un PM? Qué, qué--¿Cuál es el output propiamente, no? Te indignó mucho. O, o te indignó poco.

Es que era una conversación de barra de bar en la que cuatro personas que no habían trabajado directamente con un PM o habían sido PMs trabajaba con, eh-

Bueno, bueno, no sé.

Hablaban del rol del PM. Sí.

O sea, no, bueno nosotros hemos hecho mucho producto, ¿eh? Tanto Jordi como yo, ¿eh?

Sí, sí.

Pero es verdad que igual no hemos trabajado con-- no habíamos trabajado tanto con PMs en el pasado o no habíamos sido PM, habíamos sido programadores.

Sí.

Claro. Entonces, ¿cuál es el rol del PM, Emma? Explícanos.

Pues al final es la persona que, que hace que las cosas pasen, un poco como comentaba Valeria. Al final es esta persona que tiene que asegurarse de entender cuáles son los problemas de los clientes dónde hay mercado, cuál es el problema lo suficientemente grande para ponerse a, a resolverlo y asegurarse de que se ejecuta una solución que realmente vaya a resolverlo.

Y esto, mmm, balanceando el corto y el largo plazo. Eh, porque hay veces que nos focalizamos mucho en: Este cliente me pide esto. Pero la cuestión es: ¿Cuál es el problema de profundidad que quiero resolver? ¿Cuál va a ser la solución mágica?" Normalmente, yo, yo creo en la magia. "¿Qué tiene mucha magia?", "qué la va a resolver y cómo vamos avanzando en esa dirección de manera iterativa, pero que cada interacción me va aportando valor y entonces voy ayudando a vender mi producto hoy construyendo el producto de mañana?” Para mí esa es la persona del PM.

¿Cómo hace eso?

¿Cuál es el entregable?

¿Cuál es el entregable? Un drama. No, el entregable al final son euros. Si ha funcionado bien, son euros.

Sí.

Hombre, es un buen entregable.

Es un buen entregable. Y si ha funcionado mal-

Todo el mundo se apunta los euros, ¿eh? O sea, también te digo, el programador es el que programa dice: "Los euros, esto lo he hecho yo”, ¿no? El diseñador dice: "Esto lo he diseñado yo” ¿no? El vendedor dice: "Esto lo he vendido yo. Yo te puedo vender cualquier cosa.”

Pues es lo que te decía al principio. Si sale bien, es gracias a todos.

Pero en realidad es el PM.

Pero si sale mal, si sale mal, es el PM que nada-- que o no ha, o no ha priorizado el problema adecuado o no se ha asegurado de que la solución pixel perfect haya salido a producción. Entonces muchas veces-

Tal y como lo pintas, no lo pintas como una gran... ¿No? Si solo te llevas lo malo y lo bueno..

Es un rol duro.

Es un rol duro. Sí, yo creo que esto, esto mayor lo hemos hablado muchas veces porque hay como un, no sé, como una imagen del PM, como un trabajo bastante sencillo gratificante y tal. Es gratificantes porque a nosotros nos gusta, pero hay horas y horas de trabajo detrás, de tener que pelearte con muchas cosas Con mucha gente en el sentido de lo que decíamos, de mover, ¿no?

De que las cosas pasen. Y eso es dedicación. O sea, no puedes esperar en plan: bueno aquí está la priorización y ahora ya que las cosas pasen

Que hagan-- hágase, ¿no?

Hágase. Claro. No, eso no pasa. Eso no pasa. Y se necesita además, eh, a-hablamos en Factorial mucho de la energía. Se necesita mucha energía para convencer, para, para influenciar, para entender, para hablar con mucha gente y luego mucha resiliencia, porque al final todo el mundo te va a decir que lo que estás haciendo no es lo correcto, porque va a venir una persona de ventas y va a decir que es que este prospect, eh, tiene esta funcionalidad, es muy, muy, muy grande y necesita esto, que por qué no lo metes en el roadmap.

Y va a venir esta otra persona de account manager, que este churn reason, que esto también es muy importante. Entonces, al final siempre vas a tener mucho input de todo lo que est-- no estás haciendo. Y hay que tener mucha resiliencia para aguantarlo y para, mmm, explicar, bueno, resiliencia y datos y entendimiento, y hablar con, con clientes para tener muy claro por qué estás priorizando lo que estás priorizando y tirar con ello, ¿no?

Entonces-

Y explicarlo un millón de veces.

Y explicarlo un millón de veces.

Sí.

A todo el mundo, porque esto muchas veces yo creo que es uno de los principales errores de un PM, y voy a decir mi opinión, ¿eh?

Sí.

Es el que dice, ehm: "No lo hemos priorizado".

Ya.

Adiós.

Claro.

¿Sabes? Lo siento, ¿eh? No lo hemos priorizado. Entonces, yo, yo la próxima vez no te voy a decir ni feedback ni, ni nada, ¿no? Y si soy un cliente es: "Oye, mmm, a mí no me escuchan".

Pero-

Pero además-

Sí, dime

...que además es muy importante, aunque no lo hayas priorizado, entender, rascar ahí cuando recibes feedbacks, sea el que sea, rascar, porque también te tienes que dejar sorprender y te puede-- tienes que aprender y te puedes equivocar, y, y se reprioriza constantemente. Entonces, si no, si bloqueas todo lo que no, no es la prioridad, no, no es la prioridad, no vas a entender lo que hay detrás para poder tomar las decisiones correctas.

Con lo cual tienes que tener mucho, mucho acceso a inputs. O sea, tienes que estar muy abierto como PM a input. Si la gente piensa que no puede venirte a ver, sta-estás perdido.

Claro, tienes que ser muy accesible todo el rato. A que-- bueno, no sé. O sea, una de las cosas claras que tenemos que lidiar es Slack, ¿no? Osea es como al final accounts managers, eh, account executives, eh, gente de partners están constantemente pregunta-- pidiendo explicaciones, ¿no? Preguntando.

Además, siempre son las mismas, ¿puede ser?

Depende.

Es que-

Hay un ochenta por ciento de, de repetición en algunos casos.

Sí, pero-

Tiene que tener paciencia a veces para responder.

¿Pero te refieres a las preguntas o a las personas que preguntan? Ambas.

Bueno . Probablemente ambas, pero las preguntas. En este momento me refería a las preguntas.

Estaba pensando en las personas.

No, no, digo las, las pre-

Las otras no, porque luego yo me he dado cuenta que es como cuando dicen: "No, habla con, habla con Valeria", "No, habla con Emma." Y al final es como: "Me han dicho que ven--" Y tú: "¿Otra persona más?" Eh-

Yo siempre digo habla con Valeria y con Emma, ¿eh? Todo el mundo.

Pero no me refiero solamente a ti. Me refiro que a lo mejor entra un account manager nuevo, ¿sabbes? Está que tiene una duda y es como: "Escribe a Emma" Y ya es como: "Hola, soy account manager de no sé qué, acabo de entrar" Y, y es como: "Ya me han vuelto a pillar" Ya estoy otra vez accessible. Eh, las-- en cuanto a las preguntas, eh, fíjate que esto es una de esas cosas que por ejemplo, yo he hablado bastante con, con Xavi, eh, y es-

¿Quién es Xavi? Explica a la audiencia.

Xavi es el, el VP de customer, eh, support en factorial. Em, que-- y con, por ejemplo, también tuve esta conversación con Alberto, eh, Troncoso, que lleva la parte apps dentro de Factorial, um, que da mucho a veces por modas, ¿no? Y entonces es como-- y por eso estamos mejorando cómo el sistema de trackeo de todas estas preguntas o pains, ¿no?

Problemas que, que trackeamos, ¿no? Porque parece que muchas veces son las mismas preguntas. Luego de repente esas preguntas cambian a otras y parece como que esas preguntas se quedan en el pasado y no son importantes.

¿Qué hay modas?-

Sí

...de preguntas?

No modas de preg-

Tendencias.

Tendencias de necesidades. Vamos a ponerlo como más, eh-

Totalmente

...formal, ¿no? ¿Y, y qué pasa con eso? Es porque ¿el cliente deja de tener, em, esa necesidad?Porque ha dejado de ser urgente, pero es importante. Em, entonces, la trazabilidad de todas esas preguntas es muy importante porque detectas muchas cosas, ¿no? Parece que si te dejan de preguntar es que ya no es importante para los clientes.

No tienes que seguir rascando ahí. No es que porque no te lo pidan igual es porque se piensan que lo estás trabajando y entonces te estás dejando como un poco, ¿no? Entonces, em, no sé, el tema de las preguntas, por eso ahora estamos mejorando tanto el sistema este de, de trackeo, de paints, ¿no? De, de problemas.

Mhm.

También, no solo por las modas, sino porque hay veces que hablas con tres clientes, te piden algo y dices: "Ah, esto es lo más importante". Bueno, pero es que hay otros, mmm, trece mil clientes que a lo mejor no les es tan importante y necesitamos un poco balancear eso.

U outros mercados, ¿no? Que hablamos esta mañana también en la product review, ¿no? De con qué, con qué mercado has hablado. España. Y ahí qué está pasando con el resto, ¿no? O esta industria, qué está pasando con el resto de industrias o, o tamaños, las compañías o todo esto. Entonces hacer como-- coger como un buen-

Siempre decimos que hay que hablar con clientes, y es cierto, pero hay que hablar también con suficientes clientes y suficientemente variados para asomarse a una opinión.

Y dentro de los clientes, con los stakeholders adecuados. Hay que tener las conversaciones adecuadas. O sea que hablar con clientes en sí no es una medalla, o sea, es necesario, pero no suficiente, ¿no?

Si de hecho una cosa-

La gente dice: "No, he hablado con clientes". Con lo cual todo lo que diga continuación es verdad indiscutible.

Una de las cosas como bastante, eh, cuando hago entrevistas a, a PMs, una de las preguntas que me hacen siempre es: Qué es lo-- Me hacen mucho esta pregunta: ¿qué es lo mejor y peor de trabajar en Factorial, no? Y, y yo una de las respuestas que siempre doy es: Para mí una de las mejores de trabajar en Factorial es el acceso a, a poder hablar con clientes. O sea, tenemos muchísimo acceso a poder hablar con ellos, pero tenemos que elegir con cuáles, ¿no?

Y ahí es donde detectas cuándo un buen PM hace su trabajo, o sea, cuándo un PM está haciendo bien su trabajo, ¿no? Es: "No, no he hablado con tres ya," Pero ¿qué tres?, ¿no? Todos tenemos como el ejemplo que pasa en finance, ¿no? Que hay un cliente que está siempre dispuesto a hablar con nosotros y hemos decidido que este cliente por ahora lo vamos a dejar, le vamos a hacer mucha-- mucho caso porque nos encanta, pero Pero tienes que decir: "Estamos hablar con más", ¿no?

Entonces es un poco así, ¿no? La-- e-es bueno, eh, porque tenemos mucho acceso a clientes, pero tienes que saber qué cliente te tiene, te tiene que dar o qué cliente tienes que ir a buscar para validar lo que necesitas o para encoger ese feedback. Porque .

Oye Valeria, ¿cómo, cómo accedes a un cliente? Pues dices: hay mucho exceso de clientes. ¿Qué, qué haces para conseguir un cliente?

Eeeh, pues yo lo que hago básicamente es... Bueno, yo tengo algunos, eh, champions, eh, account managers con los que ya después de muchos años hemos tenido como una relación y les pregunto a ellos directamente. Eeehm.

O sea, le pides al account manager directamente: "Oye Emi, necesito un cliente de este tamaño, esta industria, este país tal, ¿qué me puedes conseguir?"

Sí, en plan quiero validar esto o también-

¿Y te lo consiguen?

Pues directamente les mandan: "Pues Valeria quiere habla--" Bueno, es que sí, Valeria es que a ve-

Hablan hablan con lo-- con el cliente y le dicen: "Oye, esta chica quiere hablar contigo". El cliente no tiene nada más que hacer que, que ponerse a hablar contigo.

No, pero no es porque quiera hablar con esta chica del mar y de los peces, ¿no? Pero es como que quieren ver que están trabajando en este problema, que sé que te preocupa, eh, quieren saber más y, mmm, y accedemos a ellos.

Hay muchos clientes que están muy dispuestos a-

Muy dispuestos.

A ayudarnos, porque al final si ellos nos ayudan a-- dándonos su, su input al-- sobre el producto, se aseguran de que lo tenemos en cuenta para resolver su problema. Sí que hay algunos que, que saltan directamente a una llamada.

¿Y si luego no se reso-resuelve? O sea, si se han dedicado una hora a explicarte en detalle y profundidad cómo hacer tu sistema de centros de coste, por decir algo, y luego al cabo de una semana, que seguramente su expectativa de que cambie todo, no ha cambiado o al cabo de seis meses.

No, porque nosotros intentamos darles como seguimiento. No es en plan: "Ah, hola, ¿qué tal? Me veo contigo. Si te he visto no me acuerdo", ¿no? Sino, eh, les decimos: "Vale, pues con toda esta información..." Yo siempre digo una frase que es: "Con esta información ahora nos vamos a hacer nuestros deberes," ¿no? Que es que ahora nos tenemos que poner a trabajar, es como nos hemos que encerrar en nuestra cueva todo el equipo y tenemos que con, con el feedback de, de este cliente, más todos los temas que estamos recogiendo, empezamos a buscar patrones y vemos cómo, cómo funciona este problema y cómo vamos a darle solución.

Y lo que yo siempre les pregunto es: "¿Os puedo volver a llamar para cuando tengamos una primera solución validarla con vosotros?". Y entonces es como: "Sí, por favor". Y s-- y luego siempre la pregunta es: "¿Y cuándo lo vais a lanzar?" Es como: "Bueno, bueno, habrá un tiempo", ¿no? Y le explicamos muchas veces cuando les das visibilidad de cómo es el proceso de: Estamos entendiendo el problema, vamos a buscar la solución, pero la solution no va a venir mañana.

Y les vas dando esa visibilidad, vas teniendo llamadas con ellos y vas construyendo el producto con ellos y lo van viendo, lo van testeando. No son tan demanding como parecería, ¿eh?

Depende.

Bueno, es que tú tienes, tú tienes, tú tienes más complejos que yo. Tienes clientes más complejos, malagrà mers.

tracking ha tenido situaciones donde ha tenido reuniones con clientes que a lo mejor además estaban, eh, en riesgo de churn por cierta funcionalidad, eh, relacionada por ejemplo con descansos, ¿no?

Sí.

Y entonces hemos hecho un, un discovery y una validación para entender el problema y para, eh, decidir cuál va a ser la solución. Y a lo mejor, o se ha depriorizado o es-- se ha hecho, eh, se ha dividido en fases y la solución a ese cliente va en la última que va dentro del año que viene. Y entonces no siempre se ha gestionado de la manera correcta y hay, y hay algún churn que dice: "Oye, pues no, pues esta funcionalidad yo la quería y no, no ha llegado en el, en el timeframe que yo cre-- esperaba."

Oye, pasará que haya algún cliente que os dice: "No quiero hablar con vosotros, tengo, tengo trabajo"

Claro, probablemente.

Yo por ejemplo, a ver, yo se-- yo, o sea, yo desde el lado de, de proveedor, eeeh, me encanta hablar con clientes. Siempre que puedo estoy hablando con clientes. A la mínima que alguien me dice que es cliente factorial empiezo a hacer millones de preguntas.

Sí.

Pero tengo que reconocer que cuando me escriben de proveedores, o sea, de proveedores míos-

Sí.

Eh, que estamos utilizando a alguien en Factorial no sé qué y me dicen: "Oye, ¿te puedo hacer una en-- una encuesta, una entrevista de no sé qué?" Mi-- o sea, raramente he dicho: "Sí, mira, tengo ahora una hora, vamos a hacer una entrevista de no sé qué."

Pero para eso también tenemos champions, ¿no? Tenemos algunos, algunos, eh, clientes específicos que nos ayudan mucho, que nos ayudan un poco a codesarrollar a veces ciertas funcionalidades y medidas.

Ojalá tienen que ser beneficiario de, de la solución que creas, ¿no?

Claro.

Tienes que asegurarte muy bien de que está muy involucrado y muy interesado.

Normalmente, el peligro está-- el peligro de expectativas no es tanto cuando estás validando la solución, porque ya estás más cerca de, de esa implementación, sino pues cuando estás intentando en-entender un problema.

Mjm.

Entonces, en esa parte del discovery del problema es cuando puedes crear unas expectativas de que lo vas a resolver mañana y a lo mejor no lo vas a resolver, porque después del discovery, pues se prioriza.

Ya. Oye Mai, no sé si has acabado de contar cuál es tu GOOD PM versus BAD PM.

Eeeh, pues a ver, el GOOD PM, lo que estaba comentando era que hace que las cosas pasan. Entonces el BAD PM es el que se mete en la cueva, eeeh, prioriza un roadmap, se lo pasa al, al equipo y dice: "Ya he hecho mi trabajo", ¿no? Entonces, al final, ¿qué es un good PM, un buen PM?

Pues dependiendo de-- es el que, el que hace lo que haga falta, lo, lo que haga falta. Y por eso a veces es un rol difícil de definir, porque las tareas, cuando dicen: —¿Qué es un día normal en la vida de un PM?, pues depende, porque tengo un PM que está haciendo un producto de cero a uno y que necesita estar todos los días vendiendo, hablando con los clientes, entendiendo cuál va a ser el pricing correcto, emm, euro arriba, euro abajo, y, y viendo exactamente, haciendo interacciones muy rápidas para implementarlas dentro del producto.

Mientras que tengo otro producto que es mucho más maduro, que tiene mucha más deuda, que aquí cualquier cosa que cambies va a impactar a muchísimos clientes. Entonces, al final esa persona pues tiene que entender muy bien los problemas en profundidad, eh, tiene que crear una solución que no vaya a dañar a los otros 12.000 clientes que lo están usando.

Entonces al final-

¿Tiene que crear una solución?

Tiene que asegurarse que la solución se crea. Normalmente, el diseñador y el equipo, el equipo, tenemos un equipo que piensa y son mentes pensantes muy buenas para crear una solución. Pero si la solución no pasa, yo voy a responsabilizar al PM.

¿Quién sabe más del problema? ¿Quién sabe más del problema y de la solución? ¿Los ingenieros, diseñadores o el PM?

¿Quién sabe o quién debería? Claro.

Bueno, espero que coincida, teniendo en cuenta que sois las líderes de producto y, y hacéis que las cosas pasen, sin duda.

No siempre coincide, porque hablamos mucho en Factorial de-- bueno, nosotros siempre responsabilizamos al trío, ¿no? El trío, que es el-- que a ti te horroriza este término de trío.

Sí, me horroriza. Me horroriza.

El product manager, el product designer y el engineering manager, ¿no? Entonces, juntos tienen que asegurarse que las cosas pasan. La teoría dice que el product manager es responsable de entender dónde está el negocio y el problema, y que el engineer, el engineering designeer son los que se van a encargar más de la solución.

Pero al final los tres son responsables. Lo que pasa es que en cada uno de las fases hay uno que coge más ownership, pero al final los responsables son el trío. Entonces, ¿esto qué significa en la práctica? Depende. Hay algunos que el designer, eh, se mete s-- mucho en entender el problema en profundidad para crear una solución en profundidad.

En otros, el designer no entra tanto en profundidad, entonces el PM tiene que meterse más. Entonces, al final lo importante es que el equipo se compense.

Y el que hace esta compensación al final es el PM, porque como el equipo puede ser diferente, el PM cubre los huecos. Es un rol generalista.

Porque tendrá que hacer lo que le toque.

Pero claro, entonces tienes que tener un PM que pueda cubrir cualquier tipo de hueco, ¿no?

Sí. Pero es que-

Y esto también es complicado.

Hubo un equipo que el, el-- en enero se quedó sin diseñadora y mi respuesta fue: "Muy bien, pues ya sabes, a, a diseñar en papel si hace falta, pero no podemos parar la máquina". Al final tú te tienes que asegurar que las cosas pasan.

Para aclarar lo que decías de que yo, mmm, no me gusta el concepto de trío.

Te gusta el concepto de equipo.

Para explicarlo. Es que me gusta el concepto de equipo, efectivamente. Entonces, es tan difícil esta, este mix de skills y de complementariedad, ¿no? Estos equipos multidisciplinares, es tan difícil que se produzca, que para mí me, me resulta una supersimplificación que encima se tenga que producir en tres personas, ¿sabes?

Y de alguna forma también me fi--me, me parece como una pérdida de, de talento dejar fuera a, eh, ingenieros que pueden ser 10X engineers, ¿no sabes? Vamos usando estos conceptos. Ingenieros que son en la capacidad multiplicadora, ¿no? Que son perfectamente capaces de entender el problema, la solución y la estrategia de negocio.

Y de alguna forma, por hablar del trío, se deja afuera a cuatro personas que caben todas en una sala.

Pero es que es-- no es dejar fuera, es, es traerles mucho contexto para, para meterles dentro de la conversación. No es dejarlos fuera. Al final, si todo el mundo está haciéndolo todo, y esta conversación la hemos tenido muchas veces -

Muchas veces.

Si todo el mundo está haciendo todo, nadie hace nada.

Pero yo estoy acuerdo, pero creo que es muy importante compartir y comunicar al resto de desarrolladores los porqués de las cosas.

Claro.

O sea, por ejemplo, a mí una cosa que me pasó con el equipo de projects es que, ehm, los desarrolladores acabaron queriendo ir a las reuniones de clientes porque es que empezaban a entender todo mucho más. Entonces, les dabas un contexto inicial de: este es el problema. Y, y es que al final, los-- o sea, lo que hacen es al entender mejor las cosas, son mucho más valiosas sus ideas y sus inputs, porque están metidos dentro del círculo.

O sea, al final es como un poco-- Yo lo veo, lo veía así, es como llevo las reuniones y cuando detectaba que algo era superinteresante es cuando los llevaba para que ellos, no descentrarnos al final, porque tienen que estar en el foco en el desarrollo. Pero conseguí que el equipo entendiera todos los problemas en los que estábamos focalizados, el porqué y el impacto.

Y eso es como...

Claro, pero, pero si creís que en la época de cursor, ¿no? Donde se programa casi, eh, escribiendo en inglés o en catalán, si quieres, lo que quieres construir y te lo construye un cursor o te lo construye Copilot. Eh, en esta época, ¿creéis que e l ingeniero todavía tiene que estar en la cueva concentrado y construyendo todo el día?

No es el concepto de trío y el ingeniero en la cueva o el concepto de, de equipo. Al contrario, yo a mi equipo, cuando eran individual contributor, lo traía todo. Tenía una reunión cada tres semanas con ventas y de hecho estaban, estaban invitados opcionalmente y casi siempre venían. Estaban muy metidos en el producto.

Con eso me estás dando la razón.

No, porque no estaban en todo. No estaban en todo. Otra cosa del buen PM es dar foco y hacer priorización radical. Entonces, el PM recibe una cantidad de ruido tremenda, tremenda. Recibe inputs por todos lados. Te llama este prospect, este cliente y vas allí y hay veces que coges mucho input importante y hay otras veces que has perdido una hora de tu vida.

Y entonces si la pierdes tú, pues bueno, pero si la pierde todo el equipo, el equipo no está implementando la funcionalidad que hemos prometido que este cuarto para esta fecha vamos a tener.

A ver, pero yo no digo todo el equipo, ¿eh? Aunque ojo, yo igual me gustaría ir siempre todo el equipo de la mano, todos. Porque entonces, si todo el mundo tiene exposición a todos los problemas, todo lo que está pasando, lo que acaba construyendo aunque haya menos horas productivas, seguro que va a tener más sentido. Porque gran-- el gran problema siempre es la comunicación, ¿eh?

El dar contexto todos a todos todo el rato. He aprendido esto nuevo, he descubierto esto otro.

Siempre creo que lo que dicen Emma es que al final nosotras, o los PMS, en nuestro caso nosotras filtramos el ruido. Es como--porque a,a mí me ha pasado Que me haya llamado a lo mejor alguna account manager o alguna account executive, en plan: “Por favor, tienes que venir a esta reunión porque este cliente tiene un problema”. Y luego el problema, eh, o sea, ya está implementado.

Pero lo que me estás diciendo, lo que me estás diciendo es PM versus resto del equipo. No, no trío versus-

No, no, trío. Yo iba a las reuniones con clientes, estaba el trío, íbamos en trío

O sea, el trío sí va a todas partes.

Sí, el engineering manager estaba siempre, él venía haciendo reuniones.

Y después el diseñador tampoco diseña, pues solo hay uno por equipo.

No, pero depende, ¿no? Depende. Hay más prioridades para unos y para otros Depende del momento también del discovery, depende del momento donde esté el, el problema, depende de-- o sea, al principio cuando estás empezando a hacer un, un-- Cuando , ¿no?, cuando tienes ese tufillo de que hay un problema y quieres empezar a, a, a ir mucho más en profundidad, eeeh, sí que nos-- o igual nos dividimos, ¿no?

Va con los clientes, esto va con nosotros empezamos a sacar como patrones, eh: “Luego vamos a seguir hablando con este cliente.” O sea...

Es que muchas veces llamamos Discovery a todo, ¿no? Pero es-- hay una parte de Discovery que es continuous discovery, que es hablar con un cliente cada vez que tienes oportunidad o mirar los datos cada vez que tienes oportunidad. Entonces eso para mí es más, más responsable el PM. Entonces ahí sí que indispensable que vaya a todo lo que haga falta. Luego, eh, lle-- está la parte de Discovery, que es entender el problema y discovery de validar una solución.

Todo lo llamamos discovery. En el problema sí que tiene que ir el product designer y el engineer manager, porque si no, no van a reso-- si no entienden el problema, no van a ser capaces de resolverlo. Y en la validación de la solución sin duda.

Yo mira, cuando empecé Itnig, eh, voy a, voy a historieta. Historieta, ¿vale? Momento historieta. Eh, ostras, em, yo era un PM. Ahora que-- o sea, ahora que lo pienso, ¿yo qué hacía? Pues yo, quieras o no, era un PM, porque lo que hacía era crear motivación y entusiasmo sobre un problema. Al final, básicamente lo resu-lo resumo así, ¿vale?

Entonces, ¿qué pasa? Una vez había generado el entusiasmo, todo el mundo le interesaba estar donde había la acción. Yo era incapaz de hacer una reunión en el que no estuviera el 100 % de la empresa, que esto no era productivo. Ya lo descubrí con el tiempo, no os preocupéis, ya lo descubrí. Pero durante mucho tiempo pensaba: “Ostras, ¿por qué no? ¿Por qué dejar a este pobre fuera?” ¿No?

Porque yo he hecho todo el esfuerzo de generar este entusiasmo, vamos a resolver esto tal, tal. Y ahora, pues tú no vengas, ¿no? Entonces, em, bueno, era improductivo. Probablemente todo el mundo estábamos todos siempre en, en, en todas las reuniones, eh, y luego en el tiempo, pues esto, eh, no escaló, ¿no? Y al final tuvimos que, que pensar otras metodologías, ¿no?

Pero en general siempre—y ahora me pasa con, con organización de producto de Factorial, o sea, para mí mi equipo hoy sois vosotras, los directores, eh, ¿no? Entonces yo soy incapaz de tener una reunión donde no estemos todos, porque al final lo que nos cuesta alinearnos. Somos doscientas treinta, doscientas cuarenta personas, ¿vale?

Tenemos dieciséis directores, si no recuerdo mal, ¿no? Esos dieciséis directores que vamos a todos lados juntos. Y hemos discutido muchas veces: “Oye, nos partimos, no sé qué, tal.” ¡Ostra! Pero es que si nos partimos, ¿luego qué? Cuántas veces tenemos que tener la comunicación, la conversación y alinearnos, ¿no?

Ya, pero creo que ahí es también el trabajo del PM y de un buen PM ser capaz de coger todo ese contexto, traerlo al equipo para aliñarlos y motivarlos hacia la solución. Y eso es, es in-- es muy importante. Eso como-

En eso estoy siempre de acuerdo, pero esto es PM y equipo, no trío y equipo, ¿eh?

Sí, pero por ejemplo, el producto. O sea, hay, hay momentos en los que los problemas a lo mejor son más técnicos, ¿no? Entonces a lo mejor, pues necesitas más el apoyo del engineering manager y puedes delegar esa parte en el engineering manager, ¿no? O cuando a lo mejor estamos buscando, pues por ejemplo, ¿no? Nos ha pasado a nosotros ahora con, con proyectos o soluciones más transversales, pues a lo mejor es una--tiene que ser más el director de diseño que esté ahí, porque tiene que tener esa comunicación con el resto de directores de diseño y nosotros al final es como , hablamos con nuestro, con nuestro peer, vemos que las cosas van funcionando y ya está.

O sea, al final es-- también depende mucho del producto, depende del momento del producto, depende del momento del problema. O sea, a mí me encanta ir con todo mi equipo. Además, yo-- a mí me gusta trabajar en equipo. Yo n-no sirvo sola, pero, pero es que tenemos ocho horas al día, doce incluso.

Para mí la diferencia entre equipo versus trío es que, por ejemplo, el engineering manager, que muchas veces actúa de, de equipo, ¿no? Cuando pides, pues yo qué sé, viene un cliente y dices: “Oye, ¿esto es grande o pequeño?"Al final todo el ruido se lo come el engineering manager. Desde el equipo se come menos ruido. Al final es ese, es darle más foco al equipo y traerles el contexto en los momentos adecuados para que no--para que nos aseguremos de que somos capaces de, de desarrollar cosas cada quarter y sacarlas y lanzarlas.

Para dar contexto un poco tarde, porque llevamos media hora hablando de esto, un equipo de factorial es--está compuesto por un PM, un engineering manager, un product designer y un equipo de ingenieros o product engineers. Nos gusta decir product engineers, dejar constancia de que son product engineers, es decir, gente que busca soluciones a problemas, no que pica código, eh, o que hace tecnología en el vacío, que normalmente está formado entre tres, cuatro y seis personas.

Eh, algunos-

Algunos más grandes

...algunos más grandes que empiezan a tambalearse. Entonces ya sigue difícil que este lineamiento, esta comunicación fluida, ¿no? ¿Cuál es el tamaño ideal de un equipo?

El que funcione.

No sé.

Yo creo que no hay un tamaño ideal. Si-siempre se dice lo de cinco más menos dos, eeeh, o siete más menos dos. Siempre dudo con los impares, pero al final hay equipos que tenemos que son más grandes, que son con el, con el PM y el PD a lo mejor son incluso once, doce personas que funcionan bien. Y hay equipos que tenemos que son pequeños y no funcionan bien.

Entonces cuanto más pequeño, es cierto que hay menos problemas de alineamiento, porque todo el mundo está más, más alineado y, y, y tiene el contexto completo. Pero yo no soy muy radical con respecto al tamaño de un equipo.

Es que luego también pesa mucho el--la seniority del equipo, ¿no? El qué piezas te faltan dentro del equipo, ¿no? O sea, por ejemplo, es muy importante que haya como Personas nuevas, juniors que vayan entrando en los equipos, que vayan aprendiendo de los seniors, que vayan cogiendo ese contexto. Que luego para poder también-- que luego esos seniors no, pues como nos ha pasado por ejemplo con Roger Campos, que está desarrollando un equi-- un, un producto desde cero nuevo ¿no?

Puedan-

Estás nombrando gente como si la gente los conociera, pero bueno-

Bueno, pues un, un, eh, ingeniero de manera-

Roger Campos es un histórico de Itnig, es bicofundador de Itnig casualmente.

Sí. Ehm, para que él pueda ¿no?, como desacoplarse de u-- de ese producto e irse a ser como, eh, la, la semilla del nuevo, ¿no? Entonces al final hay momentos en los equipos en los que necesitamos irlos ampliando para que ese equipo igual se vaya, eh, separando y vaya cogiendo nuevos scopes.

Eh, también depende mucho de cómo funciona el equipo, porque hay equipos mu-- eh, lo que os digo, cinco personas que funcionan superbién, metes una persona y se tambalea todo. Entonces, mmm, es, es al final encontrar el equilibrio entre el momento del producto, el, el tipo de perfiles... Es como un poco de broma, pero nueve-- “Cómo es nueve embarazadas no tienen un bebé en un mes”, ¿no?

Pues no por meter a más gente vamos a hacer las cosas más rápidas, ¿no? Pues todos esos-

Luego hablaremos de embarazo.

Luego hablamos de embarazos. Pero, pero es verdad, es: no puedes-- o sea, no por meter a más gente puedes, eh, desarrollar más rápido. Entonces todas esas cosas es-- hay que tenerlas en cuenta para, para como balancear el número de, de, de las personas.

Antes preguntaba sobre GOOD PM y BAD PM y lo decía en inglés, no para ser chu-chupi guay. Igual también, pero es más por referirme al, al artículo del año 1999 de Ben Horowitz donde hablaba GOOD PM, BAD PM ¿no? Y explicaba un poco para qué-- cuál era el rol del PM para él. Eh, yo creo que de las primeras veces que se hablaba, eh, de este, de este rol aplicado a tecnología, porque aplicado, pues a marketing, por ejemplo, pues lleva, lleva mucho tiempo.

Y una de las cosas que decía Ben Horowitz es que el PM es el s-- el CEO, el CEO del producto. ¿Esto lo compráis o no? Es también un tema controvertido.

Sí, es co-es controvertido y siempre-- Yo sí lo compro, pero siempre con una moletilla, ¿no? Al final el, el PM no tiene-- no es el manager de nadie, es este individual contributor que tiene que convencer a todo el mundo. Entonces no gestiona por línea de reporte, sino gestiona con mucha influencia y mucho liderazgo.

Entonces, eh, un CEO sí, un CEO puede echar a, al, a quien le reporte, ¿no? Entonces sí que ahí esa-

PM no puede echar a nadie.

Directamente no. Puede influenciar. Todo por influencia. Al final lo-- es eso, hace que las cosas pasen y va empujando. Pero realmente nooo-- todo por influencia.

¿Vosotras qué background tenéis antes de ser PM?

Yo tengo-

¿Qué estudiasteis para ser PM?

Yo Ingeniería Informática y Telecomunicaciones.

Eso ayuda.

Eso ayuda.

Conocer la tecnología ayuda.

Desarrollé durante un par de años y muy pronto me di cuenta de que quería más contacto humano y entender de por d-- por qué venían las cosas, por qué priorizábamos lo que priorizamos y me, me he ido moviendo poco a poco hacia el negocio.

Porque buscabas contacto humano, ¿eh?

Eso también. Siempre explico que, que-- porque cuando tenía que hacer un algoritmo, eh, supers chulo tal, guay. Pero cuando tenía que resolver un bug de lo que ya llamo tuberías, ¿no? Que tenías un, un código, una base de datos, un, un archivo de spring y algo no conectaba correctamente entonces no funcionaba y no podías hacer debug y tal.

Eso me desesperaba, me comía las-- la energía del ordenador.

Y con los humanos no pasa. No es-- no se te bloquean los humanos.

No te consumen energía.

Me consumen, sí, pero es de, eh, de otra manera, ¿no? Al final yo, yo, yo noté eso que necesitaba. A mí-- a mí me gusta mucho hablar con gente.

A mí también.

Consumo batería, pero..

Yo estudié Económicas.

Vale. O sea, tú vienes del negocio.

Yo vengo de negocios.

Por eso buscas lo-- el RR siempre bien.

Estoy siempre con los datos. Estoy como loca con los números. Eh, sí, yo estudié, eh, Económicas y la verdad es que entré-- la verdad es que mi, mi trayectoria fue como bastante casual, ¿no? Porque fue-- entré de, de becaria en un, en un pequeño banco, mmm, y llevaba las campañas de marketing.

Pero claro, las campañas de marketing es como tú puedes quemar pasta, pero si eso luego entra en un funnel que no funciona, ¿no? De, de producto, es como quemas el dinero y ya está, ¿no? Es como… Y entonces íbamos como-- empecé como a meterme ahí, a entender cómo podíamos optimizar el funnel del producto para convertir esos clientes que estaban entrando.

Y ahí empecé a darme cuenta de que no quería hacer más SEO, que, que lo que quería era mejorar-

El problema era el producto, ¿no? Te estuviste tirando de un hilo infinito y acabaste como haciendo producto.

Entonces empecé ahí a rascar qué era eso del producto y hasta hoy. Entonces, antes, antes fui estudiante, pero no, sabes, pasé de, de-

O sea entraste en producto muy temprano.

Entré en producto muy temprano.

¿Y en qué empresas has estado?

¿En qué empresas he estado? Eh, pues est—empecé en SellBank, que era un pequeño banco que pertenecía a Société Générale y a CaixaBank. Ah, luego pasé a una pequeña startup que era un crowdlending de, de préstamos. De ahí pasé a Imagin Bank, luego pasé a Idealista, después a Lo Quiero y ahora Factorial.

Y cuando comparas varias culturas de producto en España, ¿qué, qué te viene en mente? ¿Cómo se comparan? O ¿cómo se compara Factorial con otras?

¿Cómo se comparaban? Creo que en cada empresa y en cada momento de la historia, que parece como historia mucho tiempo, pero de, de los últimos años, el PM ha tenido como unos roles distintos ¿no? Y creo que también esa flexibilidad, eh, no solamente también del momento del producto, el momento de la compañía, del momento de, de, de también ser, eh, ser PM hubo un momento que era como una moda, ¿no?

O sea, era como que ti-- o sea, los equipos tienen que tener un PM, da igual. Y ponían un PM y ya está, ¿no? Y parecía como que las cosas iban a pasar. Es como hacemos que las cosas pasen, pero tiene que haber un, ¿no? Como detrás un por qué se pone un PM y qué se busca con un PM, ¿no? Ahm, entonces para mí, por ejemplo, si comparo factorial con el resto, creo que unas cosas que a mí más me gustan de Factorial es la visibilidad que tenemos del impacto, ¿no?

Volvemos a los números, ¿no? El ARR al negocio. Somos muy capaces de ver, somos capaces to-todo el rato de ver lo que está-- cómo estamos impactando A, a Factorial. En qué porcentaje nosotros estamos impactando a Factorial cada uno de nuestros productos. Si están teniendo impacto o no las features si hemos, ehm, priorizado bien y eso en otras compañías, pues ahí no, no tienes esa-- o no hay esa transparencia o no hay esa facilidad al acceso de los datos, ¿no?

Igual también creo que en cuanto a, al-- la exigencia que tenemos y en cuanto al delivery que tenemos en, en Factorial, ¿no? O sea, entregamos cosas, nos gusta, eh, estar entregando constantemente el contacto con el cliente, la rapidez, o sea, tener la calidad, pero a la vez, eh, seguir constantemente, eh, actualizando el producto.

Hay veces que eso en otras compañías, pues no tienen esa, ¿no? Y luego se compara, pues por ejemplo Imagine Bank, que pertenece a, al grupo CaixaBank con Factorial es que son cosas muy distintas, ¿no? O sea, la rapidez que hay aquí, la f-- mmm, la agilidad que tenemos en cuánto a decisiones, en cuanto a meternos en lo que queramo-

Fregados.

No iba a decir en fregados, iba a decir, eh: en, en, ¿no? Pues hoy esta conversación que la hemos tenido tú y yo de los politiqueos, ¿no? En plan de pasa algo, me meto. En otros, en otros sitios, puedes-- tienes que tener como igual...

Sí, que te lo he said yo a ti, ¿eh? Te decía-

Por eso, por eso

...nada de politiqueo.

Nada de politiqueo, métete. Claro. Y yo estaba pensando en plan: "Es verdad, es ver-- Porqué, por qué no, ¿no?" Pero claro, igual. Y justamente en ese momento he pensado: hostia, aquí mi background me está jugando una mala pasada de cuando no podía hacer ciertas cosas porque, sabes, había barreras. Eh, y aquí no, aquí es como pa'lante y, y a solucionar las, las cosas y luego ya hablamos, ¿no?

Pero que las cosas estén solucionadas. Entonces, un poco esa es la, la diferencia entre las, las compañías.

¿Y tú, Emma, cómo lo ves? ¿Cómo comparas, eh, la cultura de producto en España o donde has estado? Y t-- y explica rápidamente dónde has estado con Factorial.

Yo empecé cuando salí de la universidad, me fui a una, a un marketplace austriaco que se llama Billhaven y pertenecía al grupo que es Adevinta hoy en día, antes Shiptstat. Y allí estuve realmente ocho años, primero en un marketplace. Empecé como desarrolladora, luego product owner, luego product manager y se me globalizó a, a Shiftstat central y ahí head of product llevando un portfolio de, de productos centrales.

Entonces para mí era muy distinto, porque de hecho cuando trabajaba en Central, que fue mi mayor experiencia como PM, tenía mucho más stakeholder management de lo que puedo tener aquí en Factorial, que aquí a veces los stakeholders como que no están, no están tan claros, tan definidos, mientras que estaba mucho más lejos del impacto, porque era como un B2B2C, tenía que pasar a través del marketplace.

Stakeholder management es una palabra en inglés para decir politiqueo.

Mmm, no es-- influencia.

Todo es influencia, vale.

Todo es influencia. No, al final es entender quiénes son las principales personas importantes en los equipos que, em, que tienen algo que decir sobre tu producto y que tienes que hablar con ellos y, y coger su-- pues todo lo que te tengan que decir, ¿no? Todo el input. Otra palabra en inglés que nunca me acuerdo cómo decir en español.

Pero, pero ¿y si, y si, y si es mentira lo que te dicen que tienes que hacer o, o si no, no tiene impacto?

Claro, para eso están, mmm, los, los otros datos que tengas, ¿no? E intentar validar cosas. Pero ya te digo, en, en Adevinta yo estaba muy lejos del-- También porque no trabajaba en el marketplace directamente, sino en Adevinta central. Estaba muy lejos de ese impacto y por eso decidí irme en cierto mo-- punto. Decir: "Vale, llevo ocho años de mi vida aquí, he crecido, he aprendido muchas cosas, pero necesito-- quiero acercarme más al impacto final".

Y eso es lo que, como comentaba Valeria, tengo mucho en factorial. En Factorial puedo hablar con clientes, ver si toco esto, si sube, si baja, eh, qué impacto tiene. Es otra cosa. Y en cuanto a en qué se diferencia producto, yo creo que eso también lo notamos mucho en, en cuando entrevistamos candidatos.

Al final depende mucho de cada empresa. Hay empresas donde el product manager todavía sigue siendo muy, eh, gestor de proyecto y lo notamos.

Sí.

Eh, que piensa en ejecutar tareas. Em, en otros, pues eso, no piensa, le han venido dadas muchas cosas.

Vienen de negocio, los requerimientos vienen de negocio. A mí me dicen mucho eso. Los requerimientos vienen de negocio.

Negocio PERE.

Yo, ¿Quién es negocio?

Preséntamelo.

Claro.

Nos pasa mucho, ¿no? Que vamos a--estamos intentando contratar un senior PM, eh, y llega una persona que lleva muchos años de experiencia, pero a lo mejor no tiene ese nivel de autonomía en todos los niveles, en negocio, estrategia, eh, y ejecución e impacto que necesitamos nosotros Go To Market, que esperamos de un PM y que necesitamos de un PM aquí.

Entonces notamos que es distinto, que hay muchas diferencias con respecto a la empresa en la que estés.

¿Es fácil pitchear en Factorial?

No, no. Ojalá.

Mira que hay PMs, ¿eh? Osea, yo, yo tengo mi LinkedIn ple-- lleno, lleno de PMs que me escriben.

Pero es que se necesitan. Es decir, aparte de todo esto que hemos comentado, vuelvo a reiterar el tema de, de la energía, de las ganas. Al final-

Flexibilidad

...Factorial es un poco caos, ¿no? Esto de haz lo que hagas falta, no hay parcelas. Eh, puede venir Bernat con una idea feliz sobre tu mesa y tienes que saber cómo, eh, sí cogerla o dejarla. ¡No! Hay que saber decir que no, también, ¿no?

De ''Oye,pues, eh, le coges el input.'' Pues lo que hablábamos antes de no decir que no ni decir que sí tampoco. Ah, vale, me lo ha dicho Bernat, chu, chu, esto lo voy a hacer. Tampoco, ¿no? Entonces encontrar esta persona capaz de coger todos los inputs de todas partes, tener una opinión fuerte, hacer que pase, hablar con mucha gente sin a veces unos procesos muy definidos en algunos, en algunos casos dentro de Factorial, pues requiere mucha energía y requiere muchas ganas.

Entonces hay gente a la que yo le explico candidatas a los que le explico esto y le brillan los ojillos. Dices-- y le digo: El bien y el mal se miden en ARR y necesitamos, eh, mucha resiliencia y necesitamos que las cosas pasen. Y quiero que este producto va-vaya de cero a no sé cuántos millones en un año y le brillan los ojitos. Entonces después ya ¿Sabes qué? Por ahí hay de dónde rascar.

Y hay gente que dice: Sí, sí

Ya, pero luego hay gente que le brillan los ojitos y luego .

Ya, ya. Dices: "Aquí algo". Pue-puede que luego rasques un poco más

Pero es que si todo el mundo-- Es que a mí me cuesta imaginar que alguien le cuente de eso y no le brillen los ojos.

Pues no, hay gente que está en distintos puntos de su vida, queee, que nooo... El, el famoso-

Que quiere más predictibilidad.

Que hablaremos, hablaremos del life work balance, pero hay gente que tiene distintas definiciones de lo que eso significa. Eh, no sé.

Sí, hay gente, o sea, hay gente que no, que no está acostumbrada a, al continuo... Es que no te decir continua evaluación, porque no es que vivamos una continua evaluación en Factorial, pero es un continuo-

Estar expuesto

Sí, uno estar expuesto, dos a, a los datos, ¿no? Es como lo que dice Emma: se-- mueves o no mueves el dato. Entonces, es como tienes que moverlo. No, no puedes estar, eh, con tu equipo pasándotelo muy bien construyendo features sin mover las, las métricas.

Y si no lo mueves-

Se te va a preguntar

Y si no lo mueves, tienes que tener muy claro por qué y cuál es el plan para, para moverlo.

Para moverlo.

Y eso hay gente que no le gusta estar tan expuesta.

O que nunca lo ha estado, por-porque hay compañías donde no estás expuesto a este nivel. Y entonces pensar que van a pasar a estar expuestos les da miedo. Y a mí se me han caído candidatos durante el proceso en plan: "No es para mí"

Igual que hablábamos antes del famo-- de Martín Cagan, ¿no? Hay gente que tiene otro concepto de autonomía. Mientras que aquí es: mira, vas a tener este, este equipo y vas a poder generar mucho negocio. Encuentra oro, ¿no? Encuentra, mmm, dónde es el problema correcto para resolver. Y hay gente que no, que no tiene esa, la misma definición.

A mí me desespera esto de la autonomía, tengo que decirte. O sea, esta idea que doc-

Hago lo que quiero.

Pseudodogmática, pseudodogmática, que dicen: "No, no, el equipo es empower. Tenemos que hacer lo que nos dé la gana." Digo: Pero bueno, o sea, mo-monta tu empresa si quieres hacer lo que te dé la gana

Con tu dinero.

O sea, no sé. Eh, o sea, es importante tener autonomía porque es una forma de escalar, evidentemente. O sea, yo desde luego-

Ojalá

O sea, vosotros no podéis hacer todo lo que, lo que tenéis ahora mismo en vuestro scope, ¿no? Entonces necesitáis equipos, necesitáis crear estructura, eh, y evidentemente gene-- tenéis, queréis gente buena que se haga una opinión del bien y del mal y que actúe con, con decisión, ¿no? Pero que esté expuesta también a cambios, a nuevas externalidades, a cosas que afectan a toda la compañía, que a veces hace falta esta generosidad para decir: Oye, ojo, que si todos estos equipos tienen una necesidad y lo que estoy haciendo es una abstracción que tenga que ayudar a esos equipos, pues esto me puede hacer cambiar el roadmap.

Eso es otro punto importante. Has mencionado el tema del cambio. En factorial cambian muchas cosas y lo tenemos como, como base, ¿no?, como dogma. La única constante es el cambio. Hay gente que tampoco gestiona bien el cambio, entonces tampoco-- igual buscamos a gente que pueda gestionar bien el cambio y que se pueda adaptar. Y para esto hay que darles contexto, hay que explicarles el porqué se cambia, pero hay gente que, que no le, que no le gusta.

Y lo que hablabas de, de esa generosidad hacia otro equipo. De hecho, nosotros en Operations hemos estado trabajando mucho en el concepto de dominio como equipo. Precisamente por esto, porque en el pasado la gente estaba-- Al final todo el mundo necesita un sentimiento de pertenencia. Cuando tú tienes un sentimiento de pertenencia a un equipo concreto, con un scope cerrado y te cambian o el scope, o la gente o el equipo, te desestabilizas.

En cambio, si tu sentimiento de pertenencia no es solo necesariamente a ese, a esa equipo burbuja, sino al dominio o a Factorial, entonces si tú tienes Factorial o el dominio tiene otra prioridad mayor, es más fácil hacer esos cambios.

Me encanta que me estés dando la razón a lo que decía al principio yo, que es incluir a más equipo, ¡más equipo! O sea, hacer menos divisiones. No, no, no más de-- o sea, no el trío ni el equipo, sino el dominio.

Siempre te estoy explicando que una cosa no quita la otra. Cada vez que tenemos una assembly traemos muchísimo contexto a toooodo el mundo.

Claro.

Eh, el trío tiene que dar mucho contexto a su equipo. Tienen que tener mucha información para alinearnos y para entender el porqué de las cosas. Pero no pueden estar en todas las entrevistas con los clientes, en todos los-- el ruido que viene de, de Slack.

Ojalá estuvieran. Eh, por cierto, Dominio en Factorial es una área, ¿no? De, de negocio, de, de un espacio de problemas. En nuestro caso tenemos finanzas, tenemos payroll, bueno, tenemos operaciones, que está formada por payroll, plataforma y gestión del tiempo, ¿no? Y luego tenemos gestión del talento, ¿no?

Eh, son como dominios de espacios de problemas que actúan casi como una empresa autónoma que vamos creando y moviendo equipos, ¿no? Como, como estabas contando, ¿no? Pero al final todo es Factorial.

Claro, somos el equipo de Factoriales.

Y a veces los dominios también tienen que tener generosidad con otros dominios.

A veces, todo el rato.

Bueno, bueno, pero también hay muchas discusiones de, por ejemplo: "¿Por qué Payroll ha puesto un incentivo a..."

Yo, esa soy yo.

" A los account managers y no nos ha llamado Finanzas para que nosotros también tengamos la opción de poner un incentivo?"

No, yo no est-- mi conversación no iba tanto por ahí, sino cómo podemos tener todos nuestra parte, porque todos tenemos que vender. O sea, por ejemplo, para mí, o sea, al final es-

Un ejemplo aleatorio y ficticio y que nunca ha pasado.

Y que nunca ha pasado. Que le ha pasado a una amiga, de hecho, ¿no? Antes he dicho: Esa soy yo. No, ehm, o sea, porque creo que, o sea, para, para una cosa que tenemos superclara en Factorial es Factorial. O sea, tenemos que conseguir los objetivos como Factorial, ¿no? Pero sí que es verdad que lo que pasó ahí en ese momento es que hay dos, dos productos, eh, nuevos que necesitan como mucho ese apoyo, ¿no?

Entonces, si balanceamos por un lado el otro producto

Puede caer. Y yo no, o sea, no, no lo hago para llevármelo todo a Finance, sino es más: ¿cómo podemos trabajarlo de manera que ninguno salga perjudicado? Porque además-

Aunque no cae, aunque no caí, aunque no cae Pero bueno, ese, ese sería entrar en...

Otra conversación.

No, no sé, no tengo más da-- no tengo más datos. No puedo hablar, es vuestra persona la que le pasa eso.

Muy bien. Ehm, vale, pues hemos hablado de procesos. No, no hemos hablando de procesos.

No.

¿Cuáles son los procesos de Factorial?

Por eso vamos a hablar de procesos.

Hombre, yo creo que hay unos cuantos ya. Gracias a vosotras.

A ver, los procesos que están claros son los rituales. Hay ciertos rituales que están claros, ¿no? Tenemos la product review, como ya hemos comentado, y el alignment. Esos son los, los que no pueden-

Que son, que, que-- El "alignment" y la "product review", ¿en qué se diferencian?

La product review, como hemos estado hablando, es este, esta reunión que tenemos a principio de cada quarter, donde hacemos una review, una revisión de lo que se ha-- cada equipo ha lanzado y lo, el impacto que ha tenido en el quarter anterior y sus planes para el, este quarter, para el quarter siguiente. Entonces, es-- dura tres días y medio, cuatro días.

Todos los equipos presentan. Dura tanto porque somos muchos equipos.

Cuando dices días, son días.

Días. De nueve a siete.

24 horas.

Y entonces, eh, los-- e-es muy importante, no solo por esa visión que coges de que todos los equipos presentan y ves, eh, qué está pasando, sino porque los directores entendemos, eh, lo que se está trabajando y también si tiene sentido a nivel de prioridades, lo que hablamos de factorial.

Entonces, esa es la product review. Luego tenemos el alignment, a mitad de-- teóricamente, a mitad de quarter, pero que al final siempre termina yéndose un poquito hacia, hacia mitad más, ehm, que es una demo a toda la empresa de lo que hemos, eh, lo que estamos haciendo. Entonces, la product review es solo para el equipo de producto.

Eh, cuando hablo de, del equipo de producto incluye ingenieros, diseñadores y product managers, obviamente. Y cuando el alignment, no, el alignment es abierto a todo el go to market y a toda la empresa. Entonces, es ese momento para recibir el feedback, para recibir, eh, las opiniones de todo el go to market, de si estamos haciendo algo bien o algo mal, y asegurarnos de que, de que lo que estamos-- al final, ambos, ambos rituales, el foco es asegurarnos que estamos trabajando en la cosa correcta, eh, con el nivel de cali-de calidad adecuado.

Entonces, lo más importante es el feedback que deci-- que recibimos y qué hacemos con ese feedback.

¿Hay más procesos?

Tenemos el, el productor hands, que es un ritual interno, eh, de todo, de todo el equipo de producto, donde normalmente, pues lo usamos para ese alineamiento, eh, co-- a nivel de, de equipo de producto, de organización.

Pero si tu pregunta va más: hay un proceso de cómo definimos producto, cómo hacemos producto. O sea, porque al final estos son como más-

Rituales de equipo

...rituales. Sí, pero sí es-- o sea, creo que al final pasamos, o sea, creo que pasamos por todos los pasos de la creación del producto, pero-

Sin framework concreto.

Sí, eso es, sin un framework concreto.

No enforcement ninguna metodología, dejamos libertad a los equipos.

Eso es.

Hay equipos que funcionan de una forma y otros de otra, y equipos más agile, menos agile.

Sí.

Eh, ¿no? Eh, al final, lo co-lo común es: hay un-- est-estamos troceados en quarter, ¿no? Eh, la unidad, digamos, de tiempo donde has--hay una evaluación completa de todo es el quarter.

Mhm.

Pero cada dominio tiene distintas formas de ir evaluando cada semana o cada dos semanas, ¿no?, lo que se está construyendo.

De hecho, em, al final, lo que yo suelo comentar en las entrevistas es que a mí me da igual el libro que tú utilices, ¿no? El equipo al final se pone de acuerdo si usa Kanban Scrum, si utiliza este framework, este otro para proyectar. Me da igual el libro. Si funciona, es el libro adecuado. Y si no funciona, cambia el libro. Al final da un poco igual el framework.

Si funciona aprendemos todos del libro que funciona. Hablando del libro que funciona, puedes explicar Valeria el caso de proyectos, que es un caso, eh, bastante espectacular de crecimiento en poco tiempo.

El caso de Proyectos fue un producto que el año pasado tuvimos una conversación, el año pasado, bueno hace dos, como a finales de 2023, ¿no? Una conversación de qué hacemos con este producto. O levantamos un millón o adiós producto. Y me acuerdo que y-yo las Navidades pasadas, suena como el cuento de Navidad, pero las Navidades pasadas, las de veinte-- veinti-veintitres, veinticuatro, cuando todo el mundo estaba de vacaciones, yo estoy como pensando en plan: esto hay que levantar un millón, o sea, tenemos que levantarlo.

Y, mmm-

Cuando dices levantar un millón, quiere decir vender.

Vender.

No conseguir un millón de Factorial, del balance Factorial para-

No, no, no, no. El conseguir un millón de ARR, eh, consiguiendo que clientes paguen por ese producto.

Mhm.

Y lo que hicimos básicamente con, eh, el equipo de projects, eeeh, que para mí son como top, o sea, sí son top, eh, todas las personas que han pasado por, por, por ese producto a lo largo del tiempo, em, fue, em, meternos de lleno en entender cuáles eran los problemas que tenían nuestros clientes con la gestión de los proyectos y empezar a sacar, eh, valor en muy corto tiempo, validando a la vez, eh, el precio con lo cual vendíamos ese producto, ¿no?

Porque era todo nuevo. Ese producto está dando cero euros a Factorial. Bueno, de hecho, estaba restando a Factorial, ¿no? Porque consumía mucho, ¿no? De, de, de ciertos recursos. Em, y conseguimos levantar, eh, un millón deee-- levantar, conseguimos, eh, así, generar un millón de ARR en, en menos de un año.

Y ¿como lo hicimos? Pues fue contacto con el cliente, em, buena definición deee producto de las soluciones. Es que era contacto constante con el cliente. Es que, o sea, yo creo Si veías o si ves las métricas de, de Gong, que es la plataforma con la que gestionamos las, las comunicaciones con los clientes.

Yo veía las métricas otra vez con los datos y decía: "Ostras, es que voy a muchas reuniones con clientes a la semana". Y, y claro, y luego verte las grabaciones con el equipo, escuchar al cliente cuál era el problema. A partir de ahí, pues definirlo con, con el designer y con la engineering manager. Em, y aparte conseguimos una cosa que para mí es fundamental y es que todo el equipo estaba supermotivado con el objetivo, supermotivado.

O sea, es que todos sabían el, el, e-- la-- y lo siguen sabiendo, el ARR que están generando. Es que cuando creas ese engagement con el equipo entero es que todo funciona mucho mejor porque están dispuestos a, a arrimar mucho más, a poner más ideas.

Cuando piensan, piensan como mucho más focalizados en los problemas que queremos, eh, solucionar. Y luego un go to market, eh, muchas comunicaciones, mucha campaña, mucha, mmm, mucho upsell. O sea, basamos mucho la estrategia del go to market en upsell, de cómo podíamos cruzar esos productos con otros productos de Factorial.

Y como nosotros queremos ser, ¿no? Como una only one solution, era ahí, ¿no? Es donde nuestro producto es competitivo con respecto al resto de la competencia, ¿no? Dónde es, dónde es diferencial en lo que ya tenemos dentro de Factorial que otras empresas no tienen, ¿no? Como era, por ejemplo, el coste por hora, el poder trackear el tiempo exacto, que para muchas empresas es muy importante.

Entonces fue unificar todos esos productos y luego enseñarles el valor que tenía el producto sin que lo hubieran contratado. Entonces eso generaba la, la-- el deseo de probarlo y de contratarlo, generando un upsell. Y con un equipo de comando, eh, convertir esos com-- El equipo de comando es un equipo de upsell especializado en el producto que nos ayuda a explicar al cliente, em, el producto y bueno, el cliente en ese momento es un, es un cliente potencial y conseguimos convertirlo.

Bueno, no es, no es un cliente potencial, es un cliente de-

De Factorial, pero potencial de nuestro producto. Eso es. Y-

Empezaste pescando en una piscifactoría, digamos, ¿no? Porque eran, eran clientes de Factorial ya.

Sí, pero fue bastante curioso, porque la hipótesis que yo puse al principio es que conseguiría el 70 % de los clientes de upsell y se dieron las, se dio la vuelta a las tornas.

Y luego acabó siendo nuevos clientes.

Nuevos clientes. Tenemos más-- tenemos al revés. Tenemos más- Sí, sí, tenemos el 30 % de nuevos clientes y el 30 % de upsell. Sí, sí.

Pero empezaste hablando con clientes existentes.

Empecé hablando con clientes existentes.

Que tenían un problema de gestión de proyectos.

Sí.

Mhm.

Sí. Y que las herramientas que hay en el mercado son demasiado complejas para ellos. O sea, como por ejemplo un Jira o un Monday.

Y le dan poca visibilidad de costes reales porque no tienen la información del costo del empleado-

Eso es

...y lo pueden imputar a la obra. Tampoco tiene un sistema de clock in, clock out y de trackeo de horas entre proyecto.

De tracking de horas, de traque-- de la gestión del tiempo, eso es. Bueno, ni de las vacaciones, ¿no? Es como al final-

La gestión de las vacaciones y la capacidad de-

Claro, lo que fuimos haciendo es linkar todos los productos que teníamos en Factorial para dar visibilidad y poner en valor mucho más el, la gestión del proyecto. Porque tú ahora cuando gestionas un proyecto sabes si a la persona que estás, ehm, introduciendo en ese proyecto tiene vacaciones o no tiene vacaciones, si cuántas horas trabaja al día, qué disponibilidad tiene, Ahm, bueno, y el coste por hora de esa persona, porque tenemos el salario y a partir de ahí muchísimas más cosas hacia donde queremos ir, que es como buscar la productividad de esta persona, ¿no?

Eh, también, pues podemos linkarlo-- queremos trabajar en el futuro en cómo linkarlo, pues por ejemplo con, con trainings, ¿no? O sea, qué skills tiene esa persona, cómo performa esa persona. Porque al fin y al cabo tienes que tomar decisiones sobre qué personas poner, ¿no? En, en los proyectos o sobre todo cuando estás gestionando un proyecto para un cliente, ¿no?, para un tercero, es pues todas esas preguntas de quién es mejor poner, quién no, dónde puedo obtener más rentabilidad con el proyecto.

Al final es-- el objetivo es que los proyectos sean lo más rentables posibles y cómo les ayudamos a que eso, a que eso suceda. Y tenemos todos esos datos en Factorial.

Emma, tú ahora que has visto las entrañas de Factorial, porque llevas toda la plataforma en sí y los productos, eh, que más venden, eh, de Factorial, ¿cuál es el, el producto que más te ilusiona?

El producto que más me ilusiona.

¿Y dónde ves algo que más-- que te flipe más?

A ver.

Así de concreta es la pregunta.

Sí, muy concreta. A ver, mmm, yo tengo el corazón dividido, ¿no?Porque vengo de Time, porque fui individual contributor de el equipo de, de Time Planning. Entonces, toda la parte de gestión del tiempo, que yo aunque son tres productos, lo veo como uno, em, pues me, me, me encanta.

Y además estamos haciendo cosas muy chulas ahora que hace dos años prometí que iba a llegar la, la, la planificación automática y que no íbamos a tener que estar añadiendo turnos manualmente. Y ahora ya por fin va a llegar y vamos a ser capaces de hacer la planificación, eh, con un clic.

Dices cuántos, cuántas

Cuál es la cobertura que necesitas dentro de tu negocio y calculamos esa planificación por ti.

Mágicamente.

Mágicamente. Ya dije que yo creo en la magia. El botón mágico, esa era mi visión hace dos años, ¿no? Entonces, pues eso a mí me ilusiona mucho porque veo que por fin, por fin conseguimos llegar a esa visión que nos habíamos marcado hace un tiempo. Por otro lado, a ver, tenemos un nuevo producto, que es el nuevo bebé, ¿no? Que es Benefit y que al final estamos intentando, eh, lo estamos llevando al go to market, estamos viéndolo crecer.

Estamos ahora en esa aventura que estuvo llevando, eh, Valeria en su momento con Projects y siguiendo una estrategia parecida, ¿no? Empezando, eh, con unas iteraciones muy rápidas, eh, este de cero a uno, que al final siempre ilusiona porque ves cómo haciendo pocas cosas vas iterando y vas creciendo y vas recibiendo una-- esa interacción rápida gracias a las conversaciones con los clientes y yendo primero a los clientes actuales, que los tenemos más cerquita, eh, para luego sacarlo abiertamente al mercado.

Entonces, bueno, esos dos al final, eh, son-

Yo te quiero pensar que me hablarías de Factorial AI, ¿eh?

Es que para mí eso no es un producto. Claro, tú me has preguntado producto. Te contesto la pregunta.

Esos son todos.

Claro, Factorial AI es la nueva manera que tenemos de, de, de ver factorial, de hacia dónde vamos. Entonces, vamos a meter unas funcionalidades muy chulas que tienen que ver con meterle un buen empuje de AI y que va a cambiar cómo, cómo pensamos Factorial y que además nos permite pensar de una manera más estratégica.

No tanto: "Este convenio me pide que apruebe estas vacaciones, que estos son..." No, sino: "Oye, ¿por qué necesitamos aprobar vacaciones? Mmm, ¿cuál es toda la información que necesitamos? ¿Cómo nos aseguramos que tenemos la cobertura del negocio y el negocio tira?" Eh, y estoy llevado a todas las partes del producto, ¿no?

Eh, ¿cómo nos asegu-- por qué necesitamos compensar de esta manera y de otra? ¿Cuál es el objetivo de esto? Entonces, para mí, Factorial AI no es un producto, es una nueva manera de hacer todo el all in one, todos los productos.

Qué interesante. Oye, pues para acabar, eh, hablemos de embarazo.

Hablemos de embarazo. Embarazos .

Tú, Valeria, em, eres directora de Finanzas, ¿no?

De Producto y Finanzas.

De Producto y Finanzas, que siempre nuestro CFO cada vez se levanta de la silla

Em, ¿no? Y, y bueno, y est-- te queda poco para, para desaparecer.

Me queda poco para hacer el gran delivery. Sí.

Exacto, ese es el grande delivery.

El gran delivery.

Eh, eso pasa en, en el equipo de producto. Tenemos un equipo de, de una media de edad de unos treintaitantos años, ¿no?

Sí.

Entonces, constantemente la gente desaparece, ¿no? De ahí muchas maternidades, maternidades, ¿no?

La gente tiene hijos.

¿Cómo ya? Por interés, ya por curiosidad, ¿eh? ¿Cómo gestionamos eso?

¿Cómo gestionamos esto? ¿Desde qué perspectiva? Desde la perspectiva de PM.

Vamos a ir a la de Factorial.

Bueno, eh, a ver, sí, porque desde la otra perspectiva no quiero pensarlo todavía . Eh, ¿cómo gestionamos esto? Pues hemos...

Y luego tendremos también como es la conciliación, porque tú tienes tres hijos, ¿no? Cómo, cómo, cómo lo hacen los equipos de producto, ¿no? Que en un entorno tan in--tan demanding, ¿no? ¿Cómo se gestiona?

Sí. Bueno, eh, básicamente rodeándote de un equipo, lo que decía antes, de mucha confianza. O sea, estoy mu-muy tranquila en el sentido de que estos meses he construido un equipo supersólido en el que las cosas van a seguir pasando, aunque, aunque yo esté focalizada en otra cosa. Mmm, y al final, o sea, yo estoy, estoy como un poco el corazón dividido, ¿no?

Porque, mmm, estoy en un momento mun--estoy viendo un momento en Factorial superemocionante, pero a la vez también tengo como un proyecto personal superemocionante, ¿no? Entonces es como hay ese, no sé, ese balance de, de cosas bonitas que están pasando a la vez, porque las cosas estas pasan a la vez, es como de repente pasan, ¿no?

Suceden. Entonces, bueno, rodearte de un equipo de mucha confianza e intentar preparar las cosas, eh, dejando responsables que no dejen caer, eh, las cosas más importantes, confiando en el equipo. Es que no puedes-

Y aquí es donde el trío de directores también ayuda, ¿no?

Sí.

Porque el hecho de tener un engineering director y un design...

Ellos me han dicho que cuidan a la niña, que la tenga y que la cuidemos entre los tres, pero que no me vaya. Eh, sí, absolutamente. O sea, al final tienen que cubrir, ¿no? Que es lo que--pues antes hablaba Emma de creo que ha sido que, que faltaba un designer, ¿no? Pues es lo mismo, en plan yo voy a faltar unos meses y ese espacio se va a tener que cubrir. Va a haber PMs que, que, que tienen más seniority, que, que van a subir y van a cogerme esa mala responsabilidad, que van a cubrir espacios de producto, sobre todo con, con el resto de PMs que, que me reportan a mí.

Y luego, el, eh, Jesús y Will, que son nuestros directores, van a cubrir ese espacio, eh, durante los meses en los que yo esté fuera y, y las cosas van a seguir pasando, porque el equipo, osea, al final todo-

Tocamos madera.

Sí, bueno, porque to--al final todo, o sea, es nuestro, es nuestra forma de trabajar, ¿no?, que las cosas pasen. Entonces, aunque no esté yo, las cosas seguirán pasando y toquemos madera, yo creo que va a pasar. O sea, claro que va a pasar. Yo quiero volver y que hayan pasado muchas cosas, muchas.

Buenas.

Buenos, sí.

Importante.

Importante, que hayan pasado muchas cosas buenas, sí.

Pero Emma, ¿cómo lo vive?

El tener tres hijos.

Y ser directora de producto.

Y ser directora de producto. Pues en una constante-- es-estoy constantemente haciendo malabares. No, al final, eh, la sensa--la respuesta real es que siempre siento que n--que no hago ninguna de las dos cosas suficientemente bien. Pero bueno, al final vas haciendo..

Yo creo la que tengo visibilidad, yo creo que bastante bien la haces.

Creo que el equipo es importante tanto en el trabajo como en casa. Entonces, en mi caso, pues tengo un marido que me, me apoya en lo que haga falta y, y cuando no estoy, porque yo viajo a menudo, pues se encarga de, de los tres y sobrevive mucho mejor que yo. Y cuando estoy en el trabajo, pues me lo estoy pasando muy bien y tengo un equipazo, eh, tanto de, de PMs que me reportan a mí o directores de producto que me reportan a mí, como, con mis directores, ¿no?

Mi VP de ingeniería y mi director de diseño, que son un equipazo. Entonces, al final vas distribuyendo tanto-- más que el tiempo, es la energía, ¿no? Al final, cuando estoy en el trabajo intento estar muy presente y asegurarme que las cosas pasan. Cuando estoy en mi casa, pues intento emm, estar mucho más presente para mis hijos.

Y luego cuando se habla del "life work balance" muchas veces hablamos como que parece que tienes que trabajar de nueve a cinco y luego salir y estar con tus hijos. Yo no lo veo así. Para mí es: a lo mejor cojo un... y a las cuatro y media salgo del trabajo porque me voy a recoger a mi hijo, o a las nueve de la mañana o a las diez tengo una tutoría y voy al colegio, pero luego, mmm, por la noche limpio el Slack, lo de-- ¿No?

Al final me balanceo en los ratos que yo tengo para asegurarme de que intento hacer las dos cosas lo mejor posible. Estar muy presente para mis hijos y para el trabajo sacar las cosas adelante, que hay que sacarlas.

Qué bien. Muy interesante. Oye, pues, ¿nos hemos dejado algo de contar? Yo creo que hemos hablado bastantes cosas. Pues muchísimas gracias por-

Gracias a ti

...por contarnos vuestra, vuestra experiencia y, y bueno, seguiremos contando, como siempre, transparentemente todo lo que pasa en Factorial.

Gracias.

Hasta la semana que viene.