Nos COLAMOS en la Product Review de FACTORIAL | #334

Bienvenidos a un nuevo episodio del pódcast de Itnig. Esta semana vamos a hacer un episodio un tanto especial. Vamos a compartir con vosotros lo que es una product review de Factorial. Una product review es un evento que hacemos en toda la organización de producto una vez al trimestre. En este evento nos reunimos toda la organización de producto, algunos online, otros vienen en persona y nos explica cada equipo qué está construyendo, qué ha construido ya y ha sacado al mercado y por qué.

Pero mucho más importante que esto, estos equipos también van a compartir cuál es su roadmap a largo plazo, como mínimo doce meses, y qué van a hacer concretamente el siguiente quarter. Es lo que le llamamos kickoff. Esta semana es de los momentos más intensos que se viven en Factorial, porque entre otras cosas, vienen los equipos a Barcelona y presentan durante una hora aproximadamente por equipo qué van a construir.

Es como una especie de pitch to investors donde explican cuáles son sus funcionalidades y el equipo-- el resto de equipos discute el porqué. También es extremamente complicado porque es multidisciplinar. Tanto hablamos de los dominios, de los problemas en los que trabajamos, en el caso de factorial, de finanzas, de recursos humanos, de operaciones, como hablamos propiamente de tecnología y de diseño.

Y por último, y casi de los temas más complicados, hablamos de las abstracciones comunes y de cómo construir la plataforma en sí, quién se encarga de qué y por qué.

Para hablar de todo esto hoy estoy aquí con Jonathan Centeno y con Ilyas Zaiats. ¿Qué tal? ¿Cómo estáis?

¿Estáis vivos después- ...de esta semana intensa?

Yo creo que al final se va haciendo un aprendizaje, ¿no? Eh, de la primera a la tercera cada vez cuesta un poquito menos.

Sí, se va haciendo callo, ¿no?

Se va haciendo callo. Y conocimiento, ¿no? Al final, a lo mejor la primera costaba mucho, ¿no?, porque no entendías muchas partes del producto. Ahora que cada vez tenemos más conocimiento y visibilidad es más fácil.

Intelectualmente es, es un poco mind blowing, porque es cam-- el cambio de contexto, de tema constante, porque ahora estás hablando de tecnología, de abstracciones, de cosas que yo ya ni me acuerdo, eh, a nivel de ingeniería. Luego estás hablando de, de problemas de finanzas superconcretos, de cómo construir un balance, de cómo construir un, un sistema de contabilidad.

Luego estás hablando de trainings, ¿no? O sea, vas cambiando de tema constantemente y tienes que ir entendiendo en poco tiempo qué hace este equipo, por qué, por qué esta es la mejor opción, por qué cumple la calidad que toca. Tú, Ilyá, ¿cómo lo has vivido?

Yo, yo lo veo como, como una incubadora. O sea, yo no sé por qué toda mi vida estoy haciendo incubadoras , una tras otra, pero vuelve a ser un sitio donde hay varios equipos empoderados que se espera de ellos, ehm, que tengan, eh, la agencia para decidir qué construir y asegurarse de que les sirve a alguien que están solucionando un problema del mercado de verdad.

Y des-- y después ojalá este problema represente un gran problema y que pueda escalar, etcétera, etcétera ¿no? Pero de entrada que, que le resuelva la vida a alguien, ¿no? Eh, entonces te están presentando, eh, el racional a través de este one pager, ¿no? Yo creo que da mucha información la gente que tra-- te da un one pager simple porque significa que lo entiende muy bien y sabe abstraer y simplificar.

Y la gente que te mete ahí contexto, ¿no? Y toggles de estos de Notion que va apareciendo ¡guau!, gráficos. ¡Oh! Dices: "Pero, pero ¿por qué toda esta información?", ¿no? ¿Por qué la gente hace mmm, one pagers tan, tan largos? El hecho de que una vez al quarter tengas que parar y pensar qué he hecho- Exacto Sí Cien por cien, sí.

La cuestión es cómo lo hacemos más en el día a día. Porque es algo que debería estar pasando constantemente, ¿no? Yo creo que es difícil. Eh, yo por curiosidad miré uno de los one pagers, no diré el equipo, lo metí en ChatGPT y me ponía que me iba a tardar cuarenta minutos en leerlo. Evidentemente no me lo leí porque no me iba a dar tiempo.

Además, hacemos una cosa muy curiosa, que es que no esperamos a que los directores que están en esta sala donde entran los equipos a hacer la product review, eh, se lo hayan leído previamente, sino que damos tiempo, eh, concretamente un ci-cinco minutos para leernos, eh, lo que es la review de lo que se ha construido y lo que es el kickoff de lo que se va a construir.

Y lo hacemos con una musiquita de ascensor de fondo, todo el mundo mirando la pantalla en silencio, eh, y prestando la máxima concentración y atención posible. Que esto lo hemos robado de Amazon, claro. Obviamente no hemos inventado nada, pero quiere decir que es práctico para asegurarnos de que todos recibimos el mismo input al mismo tiempo.

Claro, yo creo que lo difícil es cómo simplificas cuando tienes unas reglas, ¿no? Cuando dices: "No, es que este documento no puede durar más de cinco minutos." Es que claro, entonces tienes que ir a cuál-- qué es lo más importante que tengo que compartir, ¿no? Y hacerte esta reflexión a veces es difí-- no solo es compleja, es que a veces no tienes una respuesta.

Mhm.

Porque implica entender el impacto de las decisiones que estás teniendo, el problema que estás... ¿no? Magnificar el tamaño del problema que estás atacando. Y esto es l-- de las cosas más complicadas en el día a día, ¿no? Y si estos equipos no se paran en algún momento a pensar, ¿no? A tener este stop en el camino y solo se lo hacen al final, al final ya es demasiado tarde en algunos casos, ¿no?

Y lo único que te deja es vale, corregir, ¿no?- ...o iterar sobre lo que ya has hecho.

Sí, pero sí que es verdad que, que tú no puedes estar siempre en modo planificación. O sea, al final tú estás o en modo planificación o en modo ejecución. Pero estar en las dos a la vez es complicado. Es complicado. En algún momento tienes que entrar y coger el pico y picar.

Totalmente. Bueno, esa es la parte ya de validación, ¿no? Ya cuando vas a salir al cliente, porque claro, n-¿qué nos pasa con estas, eh...? Claro, los equipos nos comparten lo que han estado haciendo estos tres meses, pero lo que están haciendo todavía no sabemos qué impacto va a tener, ¿no?

No sabemos si el cliente realmente estamos resolviendo el cli-- el problema del cliente, ¿no? De hecho, a veces lo descubrimos en el siguiente product review, es cuando ya nos traen el insight, ¿no? El resultado del, del quarter, del trimestre anterior, en este caso, ¿no? Entonces, siempre también jugamos con un poquito de retraso en, en ese, en el resultado, ¿no?

Yo creo que es una de las dificultades también de, de producto, ¿no?

Claro, lo que re-- me refiero es que en ese momento es, es difícil-

...verificar más allá de sentido común o de que haya una serie de métricas, una serie de datos que te permitan entender el problema y la solución que has construido, ¿no? Eso sí. Mhm.

Sí, lo que pasa es que si le das tanta importancia al racional para llegar a lo que s-- estás viendo que han construido, eh, es por eso que la gente hace one pagers tan largos.

Y por eso la gente le da tanta importancia a la presentación, porque esto es otro problema. Los equipos antes de la presentación se estresan un huevo. No sé si se puede decir un huevo. Se estresan muchísimo y es-- y esto es un gran problema, porque, o sea, n-n-n-no tiene ningún sentido que el presentar lo que has hecho genere tanto estrés, cuando en realidad lo único que es q-- el único que nos va a juzgar al final es el mercado y el cliente.

El equipo de directores lo que hace es, es de coach, ¿no? Es de coach. Intentamos que una vez al mes se involucren otros directores para dar otro punto de vista y otro coaching. Pero al final la verdad viene del mercado y la mer-- el mercado lo tienes al-- a tu alcance cada día, ¿no? Y hay equipos que tienen muy claro y mucha más certidumbre de lo que están construyendo y hay equipos que no tienen ningún tipo de certidumbre.

Y cuando me doy cuenta, los equipos más estresados en la product review son los equipos que menos certidumbre tienen, porque le dan la importancia a la product review como factor de validación. Y eso no es verdad, no es así. Y uno de los grandes challenges que tenemos desde cómo comunicar a los equipos de que esto no es así.

Una de las grandes discusiones que ha habido estos días es del rol del director, ¿no? Porque, oye, el director dice: “Es el que está cada día haciendo coaching a los equipos”. Dices: “¿Por qué este equipo ha construido algo que ahora estamos viendo que no tiene sentido o que es un problema que no, no vale la pena solucionar o que no tiene la calidad que esperamos?” ¿Por qué el director, que es la persona que hace one on ones con este equipo cada semana, no ha intervenido, no?

Y eso es lo que muchos equipos dicen. Y bueno, y en parte tienen razón, ¿no? En parte tienen razón. Pero la pregunta es: en la forma como estamos desarrollando nosotros, donde no es un desarrollo en cascada, donde hay alguien que ha visualizado exactamente la solución y ha hecho un análisis racional, eh, de cómo se va a construir tarea a tarea.

En este momento, donde lo que estamos haciendo es desarrollo ágil, donde todo el mundo va descubriendo la verdad cada día, el rol del director no es el pensador de la solución, sino que es un coach. Entonces, es perfectamente normal que un equipo construya algo, ehm, que luego no funciona.

Y el equipo sigue siendo responsable. Yo no sé cómo lo veis esto vosotros, pero desde mi punto de vista hay un poco esta confusión, este pensamiento jerárquico procesal de decir: “Oye, yo tengo un, un jefe, me-- tengo un one on one cada semana y él me dice lo que yo hago.” Entonces, desde este punto de vista, eh, la product review, el dire-- el que deberíamos estar juzgando es al jefe, es al director.

Desde el punto de vista de equipos multidisciplinares empoderados, eh, cada equipo tiene una responsabilidad de dentro de un scope determinado, un alcance de, de negocio determinado, encontrar una solución, o sea, encontrar un problema primero, encontrar un problema relevante de ser solucionado y luego encontrar una solución diferencial significativa que le cambie la vida a este cliente de referencia que ha encontrado este equipo.

Esta responsabilidad es del equipo. Luego los directores son funcionales. Uno tie-tiene un punto de vista ingeniería y está pensando en la, la plataforma desde el punto de vista de ingeniería. Otro está pensando en el negocio, est-este problema es solucionable o no, entra dentro de la estrategia de la empresa. Otro está pensando en la experiencia usuario, pero el único que está pensando en todo junto a la vez es el equipo empoderado.

Con lo cual, realmente, a pesar de que el director no le haya dado el feedback, el último responsable sigue siendo el equipo empoderado. ¿Cómo lo veis vosotros esto, Ilya, por ejemplo?

Bueno, es que el director puede no tener tampoco... Puede equivocarse también.

Porque insisto, no es un ple-- un proceso centralizado y planificado en cascada. Es un proceso iterativo y que va descubriendo la verdad por el camino. Con lo cual el director también va descubriendo, pero con el matiz que está un poco más lejos de, de, del equipo y de la verdad.

Con lo cual al final el primer responsable realmente es el equipo. Luego el director también. El director ha fichado, ha montado el equipo, es el entrenador de un equipo de fútbol.

Quién va a jugar, quién marca los goles, a quién le meten los goles, al equipo. Pero ¿quién ha conseguido que este equipo juegue junto, ha metido las personas adecuadas y tal? El entrenador.

Y el director es el entrenador.

100 %.

Claro, pero es un poco lo que hice Bernat, ¿no? O sea, yo en mi caso, cuando soy de equipos, las fases de desarrollar un-

Tú eres director de diseño del dominio de operaciones, ¿no?

Correcto.

Vale. Para protegerte todavía.

Qué bien. Solo he confirmado. Solo he confirmado. Eh, entonces claro, cuando tú empiezas a planificación, ¿no?, que quieres trabajar, primero tienes que detectar el problema. Esto significa sentarte con el cliente, ¿no? Aquí a veces la cagamos, ¿no? Pero es fácil aquí detectarlo, porque es el primer input. No has construido nada todavía. Estás diciendo qué vas a hacer y estás todavía identificando el problema.

Yo creo que el problema viene ya cuando las cosas empiezan a rodarse, ¿no? Ya ese problema se mete en un roadmap, se empieza a priorizar una serie de ideas, esas ideas van bajando, ¿no? Cada vez más al detalle, más al detalle, hasta que finalmente llegamos a una solución, ¿no? Claro, chasm! El, el único, eh, las únicas personas que están en ese proceso son las personas que lo están construyendo en el día a día, que se están sentando, se están alineando, que son ingeniería y diseño, realmente.

Todos los demás somos casi espectadores en algún-- en inputs, en varios puntos de este proceso, pero a veces llegamos incluso demasiado tarde y implica o tirarlo todo o bu-bueno, pues esto es lo que hay hoy y hay que salir, ¿no? Eh, y yo creo que para nosotros, para mí como directoes, darnos cuenta de estos errores, ¿no?

Y tomar acción de cara, de cara hacia adelante, ¿no? Ya hacia atrás, lo que hemos hecho ya no podemos hacer nada. De cara hacia delante, sí. Y yo creo que un, un punto importante aquí, Emma, que es ahora es la product director, en este caso de-

De Operaciones.

De Operaciones, conmigo, junto conmigo, eh, ha sido, eh, hace nada estaba en un equipo Y me comentaba, ¿no? Qué diferente se ve cuando eres director a cuando estás en un equipo, ¿no? Porque-

Muy bien

...me decían-- porque cuando eres director, eh, estás viendo todo, ¿no? Ves las conexiones, ves los problemas, ves hostia una oportunidad, eh, una deficiencia tal. Cuando eres un equipo vas allí y no ves nada te ves, te ves a ti mismo y que, y que tienes gente, ¿no?, que, que, que te pregunta a ti y, y, y nada más, ¿no? Y no ves nada más. Y yo creo que es la pregunta que nos podríamos hacer es: ¿cómo hacemos igual de valioso el-- la Product Review para los equipos para que vengan-- vean también oportunidades, para que vean también deficiencias, para que vean conexiones quizá con otros equipos, no?

¿Cómo trasladamos eso?

Pero, a ver, no todo el mundo puede estar en el punto de, de vigía, de, de-- y, y viendo todo lo que está pasando en el pueblo y al mismo tiempo trabajando en la mina.

Evidentemente no.Porque no le vas a poner a todos los equipos a que vengan a la Product Review sería, sería ineficiente.

Pues sí pueden, ¿no? Y algunos, algunos muy listos desde mi punto de vista, ehm, ven lo que están haciendo todos los equipos, ¿no? Y los ves ahí conectados porque por cierto la Product Review, eh, tiene una cámara y todo el mundo se puede conectar se hace de forma transparente.

Pero aun así la gente que va no va todas sabe a cuáles ir.

Son muchas horas.

Claro. Pero cómo hacemos por ejemplo esto, ¿no? Que tú sepas que a lo mejor oye te es interesante con-- buscar conexiones o deficiencias con estos equipos.

Pero ¿muchas horas o no muchas horas? Estoy pensando al final, eh, porque es todas las cosas que estamos discutiendo allí hay claro que algunos para algunos equipos vamos en detalle de este equipo dentro con contexto de este equipo pero en ge-en general cosas muy aplicadas por todo producto. No lo sé, No sé tenemos mucho scope.

Sí tenemos mucho scope pero al final si est--yo estoy pensando A mí me encantaría que estuvieran todos ahí Exacto Todo el rato. Pero pienso: "Hostia, yo puedo entender que alguien que está pensando en un problema y tiene que profundizar Mhm En este problema, eh, y tal, hostia, no pueda-- no le quepa en la cabeza también todos los otros problemas Sí,sí exacto O sea a mí me cuesta meterme en la cabeza Por eso yo no estoy diciendo que todo equipo de productos tenemos que meter en product review y s--y que todo el mundo es tien-tiene que participar esos cuatro días.

Pero es normal y yo veo cada d--cada vez más participación desde equipos de producto especialmente de niveles muy altos de senior staff Sí De staff porque es normal Es natural Que para mí esto también a nivel de director ellos también sep-- pensar a nivel de todo Factorial Es que eso es lo para mí del rol del staff Exacto Conectar puntos El rol del staff y de los directores Sí,sí Es tener el contexto global y saber conectar los puntos en general Exacto De factorial Exacto De la plataforma pero bueno yo entiendo que los equipos pueden estar muy focalizados en los problemas y ahí, ahí está el rol ahí sí que está el rol del director porque mira así como te digo que al final el equipo es responsable encontrar una buena solución y resolver un problema sí que el rol del director tiene que ser de dar más contexto

a los equipos de dar información ojo mira en este equipo han hecho esto Sí,si Ha pasado esto y lo han resuelto así ojo que esta gente está construyendo una abstracción que puedes utilizarla tú y no hace falta que reinventes la rueda ¿sabes? Ojo que este mismo problema pas-pasó ya una vez y el equipo llegó a esta conclusión Este tipo de contexto lo puede dar el director Sí Y los staffs Sí y staffs sí También pueden ver oportunidades crear estas abstracciones conectar puntos y también a veces empujar más cosas de nivel tecnológico o escalidad o, o a que sea porque al final es--ellos también están responsables para construir roadmap para todo Factorial no es solo directores o todo Ellos también tienen que tener esta agencia y para tener esta agencia

tam--tienen que tener todo contexto Por eso me gusta ver cada ve-cada vez más y más staffs participando en product review

Al final llevamos tres y si comparamos la primera con esta tercera hay mucha mejora Sí O sea seguimos teniendo encontrando problemas sí pero bueno los problemas al final son oportunidades pero está claro que lo que antes no éramos capaces de ver porque cada uno estaba trabajando en su dominio en sus responsabilidades ahora lo estamos viendo y estamos podanndo po-- tomando acción Es que lo importante no, no es esta semana Esta semana es solo el principio Hmm O sea ahora viene el vale Ahora que hemos detectado todos estos problemas o todas esas oportunidades ¿qué hacemos con ellas?

¿No? Y cómo nos aseguramos de que llegan a los equipos y los equipos luego son capaces de ejecutarlas Ahí,hay una cosa muy curiosa que yo he estado tres años casi cuatro años en el go to market ¿no? Muy focalizado en lo que es vender ¿no? Y ahí o sea también pues tss--es igual de difícil e igual de fácil ¿no? O sea no, no ,no es ni más ni menos difícil pero es más cierto y sobre todo es más rápido Y tú montas un equipo y ves funciona o no funciona vende no vende ¿no?

A veces cuando no venden es cuando se complica porque tienes que ir experimentando pero experimentas y ves vende o no vende ¿no? Vuelves a probar otra cosa vende o no ven--O sea todo la verdad llegas bastante rápido En producto tengo la sensación a veces que,que el vivir o morir pasa todo lentamente ¿no? O sea tú entras en un quarter y ves que este equipo está empezando a morir y el siguiente quarter sigue muriendo pero,pero o sea o,o,o este equipo va muy bien pero tampoco tanto ¿no?

Y el siguiente quarter va un poco mejor pero todavía no lo ha petado ¿no? Todo es como muy lento Pero es curioso porque por ejemplo yo no voy a decir el equipo ¿no? Pero vimos un equipo que el,el trimestre pasado estaba medio muriendo Mhm Y este ha pegado un subidón Sí,sí En todos los sentidos Equipos que resucitan Que eso es lo intento Y equipos que van muy bien y se estancan Sí Poco eh ves un poco de todo ¿no?

Sí pero yo creo esa es la dificultad esa ¿no? Eh l--de hecho lo hablamos ¿no? Que a veces el impacto de producto cuesta de verlo es va como con retraso ¿no? Cuando ves el impacto de que has hecho algo bien llega seis meses después y cuando ves el impacto de que has hecho algo mal llega también seis meses después ¿no? Eso es lo más difícil Pues esta product review traemos una de las features más pedidas por nuestros clientes que es labor cost Ba-básicamente consiste en que a partir de ahora nuestros clientes puedan saber,eh cuánto les cuesta una hora de cada uno de sus empleados Puedan ver eeeh,pues por ejemplo si tienen que incluir una hora extra de unos empleados pues cuánto impacta a sus presupuestos cuánto impacta en sus costes qué persona pues a lo mejor les da como ese información para poder escoger si alguien tiene que hacer

una hora extra pues igual ah escoge una persona que gane menos para mitigar,eh el impacto Y mmm al final lo que hacemos es agrupar información que tenemos en factorial y ponerla a,a disposición de nuestro producto que es una de las ventajas competitivas con respecto a otros competidores que no tienen por ejemplo esta información

Factor que ha salido mucho en la product review: el cambio. Hay muchos equipos que dicen: "Joder, es que cambia todo tot el rato", ¿no? Cambian los equipos. Es verdad que cuando cambien los equipos, sobre todo cambien los managers y tal o cambien bastantes personas de un equipo, es un poco difícil volverse a encontrar, ¿no? Porque un equipo, un equipo es una obra de arte en sí.

Antes lo comentábamos, ¿no? Es como una conjun--una combinación de personalidades-

Una engranaje

...skills complementarias que van a ver las cosas de distintas formas y van a encontrar la verdad juntos, ¿no? Y son--tenemos tres roles que son product designer, product manager e ingeniero. Pero el ingeniero realmente es quien tiene más, como además tiene, o sea, por eso además tiene un manager, un engineering manager, ¿no?

Pero en general hay dos di-direct responsible individuals que son el diseñador, prod-diseñador de producto y el product manager y ingenieros, pero ingenieros de producto. Lo cual significa que las líneas entre estos tres son borrosas, ¿no? Puede ser que un ingeniero diseño una solución, puede ser, em, que un diseñador, eh, plantee un roadmap, ¿no?, y vaya al mercado a buscar cuáles son las prioridades.

Puede ser que un PM se meta en la solución. Se puede hacer que se pise todo el mundo, ¿no? Tenemos diseñadores que saben programar, eh, que esto a veces nos sale tan bien. Tene-- no tenemos PMs que saben programar.

El diseñador tampoco sabe programa .

Pero mayormente todo lo demás se pisa, ¿no? Em, y, y creo que eso es, es bueno, es bueno que pase. A ver, si pierdes, eh, un ingeniero, pues como son cinco ingenieros, siempre puede haber alguien que, que lo sustituya, ¿no? Pero si pierdes un diseñador o pierdes un PM y los equipos pierden PMs y pierden diseñadores, porque es normal, una organización de mucha gente, pues hay rotación, las otras personas tienen que cubrir las dos posiciones, sobre todo de diseño y PM.

Y eso a veces es controvertido. ¿Cómo, cómo lo veis vosotros, los equipos que han perdido o un diseñador o un PM durante un quarter? ¿Cómo deberían reaccionar?

Yo no .

Pasando la pelota, sí.

Bueno, a ver, yo, yo es que siendo diseñador, a mí una de las cosas que más me gusta es meterme en todo .

Pero no programas. Nada villain .

Algo, pero igual no soy buen programador.

Haces queries, haces query.

No hago query, pero sé algo de frontend, no sé backend, pero sé algo de frontend. Eh-

Lo que pasa es que llevas tanto tiempo discutiéndote con ingenieros que tienes ya una mente bastante estructurada de cómo hacer building blocks de ingeniería, ¿no? Entiendo-

Sí. Hay u--hay un punto en el que alguien me enseña un código y lo, lo puedo leer. No tengo ni puta idea de cómo se hace, pero lo puedo leer hasta cierto punto. Eh, pero me, me gusta meterme un poco en todo, ¿no? Entonces, yo, yo lo que espero cuando pasa esto es: "¿Cuál es tu objetivo?", ¿no? Mi objetivo es construir un producto, encontrar un problema, construir una solución, ¿no? Para mí este es el objetivo de, de, de los tres roles.

Entonces-

Totalmente

...cuando tienes una carencia, la, la sustituyes como puedes. Eh, y evidentemente, pues un diseñador a lo mejor no sabe de métricas, no sabe realmente entender el negocio, ¿no? Pero vale, ¿cómo puedo medir un problema? ¿Cómo de grande es? Pues bueno, pues al menos me voy a entrevistar con diez clientes a ver si todos tienen el mismo problema. Hostia, ¡todos lo tienen! Pues el problema definitivamente quizá es grande.

No sé cómo de grande, pero quizás es grande, ¿no? Entonces cada uno tiene que tirar de sus herramientas.

Y luego todo el mundo tiene la skill de hablar con el cliente. O sea, yo me niego a que-

Tiene que tener

...hablar-- debería tener. Me niego a creer que, eh, hablar con el cliente sea una skill. O sea, me nieg-me niego a, a entender eso. Yo siempre pongo la misma ejemplo que es oye, si, si esto que estamos construyendo es tu casa Si esto es tu casa, te aseguro yo que vas a enterarte de, de-- o tú estás intentando convencer a tu pareja de que e-eso es la casa que queréis.

Te aseguro yo que vas a hablar y vas a entenderte, ¿no? Porque si no va a ser un problema, ¿no? Con lo cual como-- verdad que eso es cierto, sí pues puedes entender cuál es el problema del cliente

La Jira ticket para gente que no nos escucha es una especificación en un programa Exacto Sí Que se llama Jira eh que la gente mete ahí y hay programadores que lo cogen como si le entrara por un tubo este programa y empiezan a picar Exactly Exacto A picar código pupupupu ¿No? Que eso es lo que intentamos Quitar Eliminar exacto En Factorial ¿no?ExactoQue, que no O sea una frase hemos repetido mucho en este Product Review es por favor dejad de programar ¿no?

Dejad de pro-- levantad las manos de los teclados dejad de programar O sea vamos a asegurarnos de que resolvemos el problema adecuado uno y dos de que esto que estamos escribiendo de código resuelve el problema Exacto Para eso tienes que entender el raíz de problemas Tienes que entender trabajo antes de hacer trabajo Por eso sí ver discusiones con clientes o hablar mejor creo que con clientes directamente hoy y también pero para esto tienes que sacar un montón de contexto de negocio de cliente Tienes que hacer muchas preguntasDe proceso Exacto exacto exacto Eso Esa es la diferencia entre un ingeniero clásico Sí Eh que trabajaba en las líneas de producción de la ingeniería picando código a un product engineer Sí Que se llama hoy que es un

ingeniero con agencia ExactoCon sentido crítico con opinión propia que no va a hacer algo en lo que no crea Esto duele si tú no has tenido esta experiencia antes Por eso tenemos que hacer un aplauso para todas las personas que está aprendiendo esto y que está diciendo que vale ahora no tengo PM no tengo ingenierdor me da igual Yo quiero resolver problemas de cliente MhmY por eso yo voy a hablar con clientes y me gustan mucho estas personas porque ellos IncreíbleSí tiene un montón de ambición y ellos van a crecer en factorial mucho porque es laaa el único camino cómo podemos al final crecer y crear producto poderoso Sí pero os duele esto duele mucho Y si este momento cuando tú pierdes una persona y tú tienes que cambiar mente es algo

duro pero también es un momento para ti crecer co-como profesional Totalmente es una oportunidad brutal Osea todos los roles son absolutamente claves Son diferencialesPero en ausencia de un rol durante un tiempo existe la oportunidad y creo que desde los equipos deberían verlo así de entender más de una forma más general el end to end de construir un productoPara mí esto es una es una oportunidad Sí Y mientras tanto oye involucrarse buscar una persona mejor Exacto No es optimalpero también La línea perfecta no puede ser optimaNo significa que no podamos hacer nada Sí sí sí sí sí Es que ya no en la ausenciade ¿no?

S-si tú defines responsabilidades específicas para cada rol ¿no? El product manager es negociopróblemaEl diseñador espintar figmas UI interaccionesy usabilidad y el ingenieroesprogramar frontend y backendAl finaleh si elPMse equivoca y detectael problemaque no esya está todo lodemásda iguaLexactosi eldiseñadora haceuna interfazterriblepues lo queprograma elingeniero puesseráigual deterriblee xactoEs escasaes justamenteeso¿no?En cambiocuandotodo elmundo tratade entenderede todose involucraen todoesmás fácilque nonometaserroresporque alo mejorelingenie rolevantala manoy diceoye yono creó queseesel problemaporqueestuvehablandootrodía conun clientey medijonosequé Ode repenteuningenioleva lamano yediceoye eldiseño loveomuycomplejoIgualdeberíamosbuscarotras

formade simplificarlo¿YSihiciéramosesto?Puestodo estoespára mía estoluegoestasdinámicasSonlas que hacenun buenequipoLoquetú hablabasdelengranajeEsteeselengranajecuandotodelmundosepisanadielemolestaehysecolaboracienporcienYo estoy en el dominio de Talent Pues en esta Product Review hemos anunciado unnn una feature que vamos a lanzar en unos meses que será la conexión de nuestra herramienta de goals que son los objetivos de cada empleado con las performance review O sea que las compañías puedan en un periodo de evaluación medir el progreso de cada empleado

hacia sus objetivos ¿Cómo ha ido este quarter? Este quarterha idobiénHemos tenidoolgunos cambiosen elequipopor esetambiénhasidehemostenidoUn jetomuygrandeenseguiralineadosyyyy poderentregarconla cantidaddepersonoqueeenemosenequipoEstequarterhetenido uncambiodeproductmanagerNuestraproductmanagerhastaahora ahorasubió adirectoray entróBárbaraque perteneciaal equipodederecruitmentyy páramíhasidoungrandhighlightComo contodosloscambioshemosseguidadelanteye hemoses entregadotoda lo quenoshcemoscomprometidoYYYY siemprecon

unfreebing equipoqueehaparecidocuesiemprehemosestadojuntoscreoquemepositiv

Seguimos otra cosa que hemos-- pensando todos los temas que han ido saliendo, ¿no? Cómo conseguimos que todos los equipos en un dominio trabajen juntos o en problemas parecidos. Porque vale, hemos definido un equipo de empoderado, este es su scope más o menos de problema. Tienen que encontrar un problema concreto, pensar una solución y llevarla al mercado.

Eh, esto parece fácil, vale, pero ¿qué pasa cuando los equipos están atados entre ellos y cada uno soluciona un trozo de un problema? ¿Cómo conseguimos que trabajen juntos, Jonathan?

A ver, yo creo que el, el mayor reto que teníamos hasta ahora es que muchos equipos estaban construidos casi más que en problemas, en soluciones. Entonces, esto delimitaba quizá muchísimo más el horizonte que tocaban, ¿no? Porque se, se delimitaba a una parte del menú en nuestra navegación de Factorial, no a un problema del cliente muchas veces, ¿no?

Ahora hemos cambiado un poco el enfoque. Ahora e-el enfoque es más: vale dividimos problemas. Y esto hace que muchas veces haya pues eso, ¿no? Los equipos se empiezan a pisar porque tienen que tocar para resolver problemas que los dos tienen tiene que tocar la misma parte del producto.

Pero tú dices, eh: Dividimos problemas, pero dentro de un mismo espacio de solución, ¿no? Lo que estás diciendo tú, por ejemplo, estás hablando concretamente de la gestión del tiempo.

Por ejemplo.

Que para l-- que la percepción del cliente, la gestión del tiempo puede ser un producto único. Tengo esta software para gestionar mi tiempo y ahí están las ausencias, el control horario, ¿no? Está la planificación de los turnos, eh, está el calendario común, están las peticiones de cambio de turno, está un conjunto de cosas que para el cliente todo esto es uno.

Correcto.

Y luego nosotros hemos dividido para p-- para poder dedicar más energía a este problema, que es mu-una buena oportunidad de negocio para nosotros y para poder meter más, más pulso y contratar más gente, hemos tenido que dividir el scope en trozos y esos trozos los hemos dicho en trozos de nuestra solución a este problema. Eso es lo que te refieres, ¿no?

Exacto. Pero nosotros, por ejemplo, empezamos teniendo tres equipos, uno enfocado en la planificación de turnos, otro enfocado en el control horario y otro enfocado en las ausencias. ¿Qué pasa? Cada uno de estos equipos cuando iban a hablar con el cliente le preguntaba: "¿Cómo planificas turnos?" El otro pregunta: "¿Cómo haces el control horario? ¿Cómo fichan tus empleados?".

Y el cliente responde: "Bueno, pues tengo gente que, que está de ba-- eh, de baja o gente que está de vacaciones y tal." Y no, no. Y el otro dice: "De vacaciones me da igual".

Claro.

"Hablando del turno."

¿Cómo fichas el turno?

Claro.

Y, y algo tan obvio que, que las empresas al final como funcionan, ¿no? Planifican, hacen una planificación a futuro, ya sea en jornadas laborales, en turnos, vacaciones festivos, bajas médicas. Y luego hay una realidad, ¿no? La gente ficha y trabaja unas horas que no corresponden a lo que tú planificas. Y finalmente las empresas tienen que pagar, porque el ejercicio de hacer todo esto es pagar.

¿No? Rellen-- tengo, tengo que rellenar una serie de personas que están haciendo un trabajo y asegurar una cadena de producción y tengo que pagarles al final de eso, ¿no? Es el incentivo. Pues algo que era tan obvio, lo-los equipos lo han descubierto hace, eh, seis, seis, nueve meses cuando dijimos cambiamos completamente el horizonte. No, tú ya no vas a hacer, eh, gestión de turnos, tú te vas a encargar de entender cómo planifican las empresas el tiempo a futuro.

Claro.

O sea, lo-los equipos lo han descubierto hace seis meses. No, nosotros mismos, porque al final nosotros tenemos nuestra complejidad, nuestros líos, nuestros problemas y luego nos los comemos.

Correcto.

Y creo que en este caso nos falta quizá esta product review a nivel de estos equipos, ¿no? Que puedan, eh, tener más espacios en lo com-compartir lo que están haciendo y encontrar esas, esas conexiones entre ellos. Y re-- y el, y el dire-- y esto es la función del director y, y de rellenar estos huecos, que cuando haya un hueco y haya una gran incertidumbre entre medias donde nadie estaba actuando, el scope e-eh, para mí es la función del editor.

Voy a-

¿Ycómo lo hacéis concretamente los directores? ¿Cómo juntáis a los equipos para que, eh, descubran los problemas conjuntos y se repartan un poco las responsabilidades?

Ahora lo estamos haciendo un poco asíncrono y nos está funcionando bien. Entonces, eso para nosotros es un reto resolver, ¿no? Pero hasta ahora es, eh, los equipos trabajan sobre este problema, bajan, bajan un roadmap y sobre este roadmap ya vemos que puede haber ciertas sinergias, ¿no?, entre equipos. Entonces, es aquí cuando luego les juntamos, ¿no? Y decimos: "Oye, mira, habla con aquel que tenéis cosas parecidas que seguramente forman parte de la misma pieza y tendréis que trabajar sobre la misma solución, ¿no?" Lo que pasa es que todavía sigue costando, ¿no?

El quizás esto es demasiado tarde, ¿no? Ya, ya hay un roadmap, ya se ha planificado tal, los equipos ya empiezan, es demasiado tarde, ¿no? Y quizás necesitamos hacer este ejercicio antes, ¿no? Cuando-- antes de que los equipos tengan un roadmap, sino cuando están definiendo y entendiendo su visión y su estrategia, que hayan esas sinergias, ¿no? Y que hablen entre ellos. Por eso decía: igual tenemos que trasladar la pro review a un formato mucho más reducido dentro de los dominios, donde los dominios se pueden dar.

Igual que nos damos cuenta nosotros como directores de cómo juntar las piezas, los problemas que tenemos para juntar las piezas grandes, que son finanzas, recursos humanos y operaciones, que el equipo se dé cuenta: oye, cómo just-junto l-la planificación del tiempo con el, con el control horario. Esto que algo tan simple y a la vez tan complejo.

Bueno, concretamente, este es el producto más maduro de Factorial, donde hay ocho años de, de desarrollo, ¿no? Hay mucha funcionalidad, eh, hay código de todo el mundo que ha pasado por, por Factorial, ¿no? Y entonces mucha gente le tiene miedo a legacy, ¿no? Es un poco, ya lo digo con ese tono,porque hostia-.Es que qué, qué pasa esto, por qué pasa esto, cómo-- n-nlo sé y no lo quiero saber y no lo voy a tocar, ¿no?-

Sí Porque luego, eh, volviendo a algo que comentábamos antes, ¿no? Eh, cuando tienes que medir el impacto de las cosas, lo que más cuesta de medir es borrar algo. ¿Qué valor tiene borrar algo?

Altísimo.

Claro.Pero-

Tiene unvalor altísimo.

Pero esto no es obvio muchas veces, ¿no?

Pero volvemos al hecho de entender los problemas.-

Eh, y oye, cuál es el problema, cuál es la solución óptima a este problema. Igual lo que pensabas hace cinco años no es la solución óptiva, aunque la esté utilizando alguien. Y puede ser que la verdad de hoy sea mejor que la verdad de ayer. Entonces, lo que tenemos que hacer es de, de llamar a este cliente. Otra cosa que a veces es muy difícil de conseguir, llamar a este cliente y preguntarle: "Mira, cuando construimos esto pensábamos esto, ahora pensamos esto, que tiene más sentido para el conjunto de nuestro mercado, nuestros clientes, y por eso hemos cambiado de esto a esto." Se-- vuélveme a contar tu problema que me contaste hace cinco años y voy a pensar con la verdad de hoy si puedo o no puedo solucionar tu problema, ¿no?

Y afrontar esas decisiones, oye. Em, una cosa que sí que hemos visto es que los equipos, eh, respecto hace dos products reviews, trabajan más conjuntamente. Y hay una cosa que es todo lo que es lo común, la plataforma, que hemos conseguido que se reparte bien entre los equipos, especialmente entre los roles de más seniority, eh, en Factorial.

Y hemos conseguido que,que pues yo que sé, un equipo el quarter pasado hizo comentarios, eh, y este equipo,hay otro equipo,este quarter ha, mmm, evolucionado comentarios,pues ahora tienen más niveles,tienen emojis, ¿no? Y de repente aparecen emojis en todos lados, ¿no? Ese tipo dede colaboraciones,de co-- de elementos comunes, em, creo que ahora está funcionando mejor.

Ya, me encantaesto.

Yo creo quelotenenos queevitar esque yayaha parecido, ¿no? Este casodevoy aconstruiruna abstra-abstracciónparatodomundo.Voy avertodoslospotenciales casosquepuedehaber, ¿no? Yaquí llegaunaparálisisby análisis,porqueestástodo eldíaintentandodescubrircasos, perono terminasejecutandonada, ¿no? Yaquí creoque escondetenemosque abrazareste conceptode notúlanzaalgo queresolvADOS,trescasosde uso, ¿no?

Losque hayasconsiguidoecontrary,y vayas apriorizarhoy, ¿no? Ymañanaelsiguiente equiposevaencontrar elsiguientecaso deusoya cogeráeso quehas hechoy looterarási hace faltaparasolverotrocaso deuso, ¿no? Yesese esun pocotambiénla filosofíaunpoco delopen source,del colaborar dealguienhace algoyel otroconstruyeencimade eso, ¿no?

Yademás construyeformaqueseaduraquetodal anterior siguefuncionando.

Y elorgullo Que tienes cuando haces open source de, de tener líneas de código en abstracciones comunes. ¿Sabes? O sea, hace ilusión. Hay veces depende qué culturas de ingeniería que pasa lo contrario nadie quiere contribuir a lo común, ¿no?-

Mhm

...nadie quiere-- es lo que se llama la tragedia de los comunes, ¿no? Nadie se quiere encargar de lo común. No, pues eso es un tema cultural. Eh, tú lo has dicho bien, el Open Source la gente le hace ilusión tener un commit en un código Open Source, ¿no? Yo creo en Factorial está pasando lo mismo.

Último punto del debate. Esto es un debate, si no sabíais. Lo acabo de decidir. Eh, la calidad.Esto es un producto que tiene calidad, esto no tiene calidad. Eh, Iliá.-

Vamos, vamos.

¿Cómo sabemos? Porque es muy fácil decir: "esto está bien, esto está mal"-

Sí

..."esto es bueno, esto es malo". ¿Cómo sabemos...? ¿ Cómo podemos definir qué es bueno y qué es malo?

De examen.

Aunque algunos PowerPoint nos hemos comido, ¿eh?

Pero bueno,-

...la mayoría de equipos han hecho demos. Es verdad.

Que todavía no estaba listo-

...para ser utilizado por un cliente.

Emociones buenas.

No te quedes detrás del ordenador por la cara.

Vale Magnético donde estoy diciendo emociones, estoy pensando en... .

Al final tenemos, tenemos una lista de cosas-

..que dice no, un producto tie-tiene que tener conectividad con otros productos. Tiene que ser simple, prescriptivo tal Claro, pero cuando tú piensas este producto es lo-- es la solución más simple posible. Claro, hay debate. Puede ser que haya una solución todavía más simple de la que hay, ¿no?Entonces igual la calidad puede ser incluso mejor todavía, ¿no?Yo creo que esto siempre va, va a tener un, un cierto rango de subjetividad.

Y es normal.Es normal.

Y debería tenerlo.

Ya que a mí me gusta mucho escuchar historias de otra gente y entender cómo la otra gente trabaja, en Figma le llaman "la complejidad irreductible". O sea, la versión más simple es como-- es la complejidad más irreductible. No puede reducirse más, ¿no? Eh , y también le llaman el craft de producto: el arte de resolver problemas básicamente, ¿no?, el, el the art applied to sol-- problem solving, ¿no?

Em, y, y creo que esta es la mejor metáfora de lo que es, eh, crear producto. Porque al final un producto tiene una función-

Mhm

Sí Yo creo que si lo trasladas al diseño, al final es, em, la forma de encontrar esas, esas soluciones es hacer más con menos.

O sea, la gente piensa a veces que cuando una persona es más creativa es cuando tiene un lienzo en blanco y eso es un poco al contrario Es cuando menos creativo eres porque más te cuesta por dónde empiezo, ¿no? Qué hago Ahora bien, si yo te reduzco mucho lo que puedes llegar a hacer, ¿no? o los elementos o los componentes que puedes llegar a utilizar Claro para resolver un problema que es muy complejo Te tienes que poner muuuy creativo Y ahí vas a simplificar a la máxima expresión porque tienes tantos límites Que ostras claro hay un momento También que puede ser que Los límites te, te Lo que tú decías Si todo termina siendo Una tabla Pues nuestro Producto tampoco va A ser apetecible Pero tener ten pero Ahí está La magia Entre Tener unas reglas Que permitan a Gente Ser Creativo Hacer Más Con Menos Y dejar cierto

Margen a Explorar Nuevos Caminos Que nos den ese extra no Que El producto Puede Puede necesitar Para Mí esa es la parte De Diseño y Esto y es Un reto Porque Lo vemos Constantemente Lo fácil Como Diseñador Decir ah pues Hago algo Nuevo Lo difícil es No no Con lo viejo Voy a Resolver este Problema Supercomplejo En lugar de Hacer Algo específico Exacto exacto Esto requiere mucha más creatividad efectivamente exactamente Pero Me quedo Con el tema De las emociones Que también Me ha gustado Que el Arte Produce emocioneS TambiéN totalmente Muy Bien Creo Que Hemos tocado Todos los temas Por Cierto Este último Tema Que es el tema Más complicado De producto La definición De calidad Es También Es

un problema Que no Ha existido O no existe Un algoritmo Que lo pueda Resolver Un checklist Un proceso Y por Eso es tan Difícil también Contratar Porque Al Final Tú quieres contratar A gente Que te explique Te sorprenda Con Con la nueva Calidad Que no te Lo tenga Que preguntar Sino que Te lo Explique Y bueno Yo creo que Ahí están todos Los retos De toda La gente Que Está haciendo Producto en El mundo De Esta Definición De calidad Porque No Hay nadie Que quiera Generar una Solución Que no Tenga calidad