Bienvenido a las historias de Startups de Ibnig.
Yo soy Bernat Farrero y esta semana estoy con Ilya Zayets.
Hola.
¿Qué tal, Ilya?
Hola a todos.
Ilya, con este apellido, no es de Reus, es ruso.
Viniste a España hace...
Nueve años.
Nueve años ya.
Y fue precisamente para trabajar en Teambox, que era la empresa donde...
Redbus en este momento.
Y ahora Redbus, ¿no?
Sí.
Vale.
Que era la empresa donde Jordi Romero y Pau Ramón, antes de venir aquí a Factorial, trabajaron, ¿no?
Sí.
Posteriormente a esto, luego entraremos en tu historia, pero posteriormente a esto, viniste a Ibnig,
trabajaste en uno de los proyectos de Ibnig como CTO, Camalún, ¿no?
Luego emprendiste, montaste tu empresa, levantaste bastante dinero, de entrada, muy temprano,
construiste un producto muy difícil, Consumer, luego nos explicarás.
Y finalmente te recuperamos aquí en Ibnig en Factorial.
Todo correcto.
Y has llegado a un año especialmente complicado.
Ha sido un año para Factorial bastante difícil de cambios.
Donde tú entraste en febrero, ¿no?
Y tú entraste como líder tecnológico, director de ingeniería del dominio de Finance, que era un dominio nuevo que habíamos creado en Factorial.
Y poco a poco, bueno, empezaría a haber cambios y hasta el punto que habría una reestructuración, un cambio, una reorganización, digamos, en el equipo de producto, una forma de trabajar.
Y saldría el CTO, mi socio, Pau Ramón, después de siete años decidió que quería hacer otra cosa, estaba cansado, que le superaba la escala, que no le apetecía.
Y decidió hacer otras cosas, con lo cual tú te convertiste en su sustituto, ¿no?
Y hoy eres el líder de tecnología de Factorial, ¿no?
Entonces, yo quería preguntarte, Ilea, ¿cómo se vive esta situación donde de golpe un co-founder, CTO, que está desde el primer día, que ha contratado a la mayoría de gente, de golpe se va?
En un medio, en un momento de cambios de todo tipo, y de golpe tú eres el next guy.
Estoy riendo, porque sí, con Pau es un patrón.
Sí, claro, sí que tú quieres tocar mi historia un poco de adelante, pero en Redwood pasó exactamente lo mismo.
Sí, al final, Pau y Jordi me han contratado para como ser un team lead, pero en algún momento ellos diciendo que vale, tenemos una idea, una idea genial, hacer una plataforma para recursos humanos, que se llama Factorial, por eso vamos a hacer esto.
Y ya, ahora tú eres un sitio de Redwood.
De Redwood.
Sí, por eso aquí, vale, en Factorial, pasa lo mismo.
Tengo una experiencia.
No, pero es verdad, sí, bromas fuera, es que es verdad, es un reto, pero es un reto grande y que me motiva al final.
Porque hay un montón de cambios, hay un montón de challenges a nivel del equipo, a nivel cultural, a nivel de negocio, pero es algo como, es manera perfecta para crecer al final.
Si tú quieres, perdón, siempre en todas las empresas, en todos los equipos, cuando todo, si todo va bien, vale, es muy confortable, es muy estable, pero es también, no es aburrido, pero es algo que tú estás cómodo día al día.
Pero si hay un challenge, es una oportunidad grandísima para crecer.
Pero es un challenge del que para mucha gente huiría un poco, ¿no?
Porque es muy difícil de golpe, en un entorno así de cambio, asumir esta responsabilidad, ¿no?
Con gente que está con las urpas un poco, las uñas, fuera, ¿no?
Porque se han producido cambios y porque se va la persona que los ha contratado, que en aquel momento, además, se convierte en un semidiós.
Yo quiero mucho a Pau, ¿eh?
Pero Pau en Factorel hoy es una especie de semidiós, ¿no?
No, pero depende de cómo tú ves esto. Si tú crees en un equipo, si tú crees en una idea, sí, claro que hay algunas cosas y hay algunos problemas que tenemos ahora.
Pero si tú ves en seis meses, un año, en dos años, en larga duración, es una motivación grandísima.
Porque al final vale, vale, tenemos algunos challenges ahora, vamos a arreglar todo, vamos a poner en marcha y al final vamos a crecer mucho.
Y es una motivación. Si tú enfoques solo en un mes o en dos meses, claro que vale, es más fácil despedirse.
Yo recuerdo cuando te lo planteo, que tú, bueno, tomas un tiempo para pensártelo, pero ¿qué pasa en aquel momento?
O sea, ¿cuáles son las variables? Rápidamente dices, sí, ¿no? Voy a hacerlo.
En mi historia, normalmente, si este tiempo para pensar es algo falso en el final, porque normalmente yo tengo respuesta en cinco segundos.
Pero también después tengo que racionalizar a mí, porque es una buena respuesta, pero internamente también tengo esta respuesta.
Aquí pasa lo mismo, porque yo no he visto otra manera, como yo puedo decir no a esta oportunidad.
Vale. ¿Y cómo te encuentras el equipo y el equipo de producto de Factorial?
Aquí somos muy transparentes, explicamos siempre todo y creo que es bueno.
Entonces, ¿cómo te encuentras el equipo y cuáles son tus primeros, lo que haces en el primer mes, dos meses?
Aquí, el challenge principal es, claro, como tú estás diciendo, que Pau es una persona muy fuerte,
que yo tengo un montón de confianza y respeto.
Y también es claro que todo el mundo va a comparar a ti con Pau, pero yo no soy Pau.
Y yo tengo mi estilo, yo tengo mi visión, yo tengo todo.
Y primero que yo quería hacer es transmitir esta visión y también aprender mucho, porque claro, para mí Factorial fue algo nuevo.
Solo desde febrero hasta julio este cambio pasó tres meses y por eso me falta un montón de contexto.
Por eso hablar cada día con un montón de gente y hacer cosas que todo el mundo está pensando que no es escalable.
Pero para mí la idea fue que vale, yo voy a coger todos los managers que tengo, todos los directores que tengo
y voy a aprender qué es un producto, qué es un dominio, qué challenges hay.
Hablar persona por persona y tener, sí, sacar más información, máxima información que puedo.
Y en paralelo también enviar mensajes que valen, cosas más culturales.
Porque aquí podemos empezar un poco sobre qué cambios hemos hecho y por qué lo hemos hecho.
Si yo voy a hacer como un repaso, que yo he visto personalmente es que en cada compañía pasa en esta historia
y si tú vas a escuchar un montón de podcast, siempre pasa esto.
Ah, estamos en fase de hypergrowth, por eso buscamos un montón de gente, encontramos un montón de gente
y después no sabemos cómo podemos manejar.
¿Cómo gestionarla?
Exacto, 100%. Y es algo que pasa mucho.
Y en este caso me parece, Factorial no fue diferente.
Porque al final tenemos un equipo muy bueno, tenemos, me parece, cultura de ingeniería y producto muy buena.
Pero claro, si tú vas a meter más de 100 personas un año, es normal que al final...
Se rompan cosas.
Se rompan cosas y es muy complicado alinear este tamaño de personas.
Por eso en este caso al final pasó lo mismo.
Que para mí algo que fue muy significativo es que cuando ha entrado este dominio de finance,
yo entendí que vale, yo entiendo esta idea que al final podemos centralizar cosas y descentralizar cosas.
En el momento cuando yo he entrado, todo está muy descentralizado.
La idea fue que vale, vamos a crear una compañía dentro de una compañía.
Tenemos un CEO, tenemos un sitio de dominio y tiene su idea, tiene su visión de todo.
Pero al final teníamos seis o cinco estas compañías sin hablar de todo, sin hablar de nada.
Y al final cada esta compañía va a su dirección.
Antes expliquemos igual lo que es un dominio.
En nuestro caso el producto está dividido en cuatro dominios.
Cuatro dominios, cuatro partes muy diferenciadas, igual demasiado, en aquel momento muy diferenciadas, del producto.
Una es la parte de HR operations, de recursos humanos, la parte más operativa, que es la gestión del tiempo y del payroll.
La otra es la parte de desarrollo de talento, que es donde hay la evaluación del desempeño, el engagement y el recruitment principalmente.
La otra es finance, que es todo lo que es a día de hoy gestión de gastos, notas de gastos.
Y la cuarta es una parte más meta, que es lo que mucha gente le llama plataforma,
que es básicamente el producto per se de factorial.
Es donde los dominios construyen, donde hay las abstracciones comunes,
donde hay todos los espacios que unen, el pegamento que une todas las distintas funcionalidades de Factorial.
También la API, las partes estructurales, la parte de reports, todo esto es core.
Estos cuatro dominios, les llamamos dominios, era como estaba dividida el equipo de producto.
Y cuando tú llegas y cuando yo también me centro en el producto, porque esto vamos juntos,
nos encontramos que los dominios están divididos con un GM, un GM, un General Manager, por dominio,
a quien reportan tanto los ingenieros, como los diseñadores, como los Product Managers.
Exactamente. Y al final la idea fue como separamos todo.
Es como cada equipo tiene su roadmap, tiene su OKR y tiene su visión.
Después de este equipo tenemos un dominio, que es un conjunto de estos equipos,
y conjunto de dominios es como factor al final.
En papel, todo perfecto.
Perfecto.
Sí, sí, sí. Funciona 100%.
Cada uno tiene un objetivo también de ARR.
Sí, a nivel de dominio, en teoría a nivel de equipo.
Sí, pero en realidad, OKRs y todo es como si es una herramienta, pero si nadie está usando este correctamente,
está usando como herramienta y pone como una idea, es algo que solo decidimos una vez a Quater y después no sabemos.
Claro que con nuevo contexto y todo pensamos que, vale, este OKR no tiene sentido, pero vale, tenemos este OKR.
Y lo mismo con todos los roadmaps, cosas que cada equipo va solo por su cola,
no revisando qué está pasando por la izquierda o por la derecha.
El equipo es un subgrupo dentro de un dominio.
Hay unos seis por dominio, ¿no?
Seis o siete por dominio.
Y cada uno tiene una misión.
Sí, una misión.
Y también es como un trío de director, es product manager, diseñador y engineer manager.
Y con engineer manager, cada engineer manager lleva cinco, seis, siete ingenieros.
Por eso es como equipo multifuncional que tiene todo el día del mundo.
Pero al final, si tienes esta separación tan muy definida y esto todo es muy tan distribuido,
y al final este Conway Law clásico es que tú vas a tener tu producto como tu estructura de compañía.
Y pasó lo mismo.
Porque al final tenemos algunos productos que desde el punto de vista de usuario es un producto,
pero porque es tres o cuatro equipos en nuestro organigrama,
es cuatro productos diferentes que no hablan entre ellos, que no comparten datos entre ellos.
Y al final, de punto de vista de usuario, todo es un caos.
Porque yo entro en un lugar, es para mí un producto de Time, por ejemplo,
o un seguidor de Finance, y al final hay otra pestaña, y tercera pestaña,
y también quien no comparte datos, y yo no entiendo por qué,
porque para mí es un factor, todo es factor.
¿Qué prefieren los equipos hacer su propio subproducto, su empresa,
incluso pestaña dentro del producto con toda su funcionalidad,
que colaborar con otros equipos que no tienen una línea directa de reporting?
Exacto. ¿Y por qué?
Porque comunicación siempre es algo muy, muy complicado.
Y el ser humano busca lo fácil, el camino fácil.
Sí, sí, es normal.
Y desde luego colaborar con otros seres humanos probablemente no sea lo más fácil.
Porque al final todo es como un proceso, tienes su roadmap,
otro equipo tiene su roadmap, y por eso es como alinear roadmaps es muy complicado,
también pasa no cada día, si quieres romper algo también tienes que levantar su mano,
es también otro challenge, y al final sí, status quo es tú vas por su cuenta.
Pero también qué me preocupa más, que todo el mundo inicialmente pensaba que todo bien al final,
si yo estoy haciendo mi trabajo día al día, mira, estamos creciendo, estamos…
Esto es otra cosa que pasa cuando crecen los equipos, y no le pasa solo a Factora, le pasa a muchas empresas,
que es que de golpe en la división de responsabilidades empieza a aparecer la complacencia,
es decir, la gente dice, bueno, alguien se encargará.
El producto no va bien, yo ya se lo he dicho a alguien, ya se lo he dicho al de al lado.
No me gusta cómo se ha hecho la última navegación, no me gusta el último design system,
no me gusta la tabla, la abstracción de la tabla que hemos hecho,
pero como me queda lejos, pues no lo puedo cambiar.
Y otro tema que también cambia tu chip un poco,
porque hasta todo el mundo ahora está pensando que vale, estamos tan grandes,
es como estamos un enterprise, no hay otra manera diferente, es solo que es…
O sea, asimilarlo como un hecho incambiable, ya somos enterprise,
con lo cual esto ya es lo normal.
Sí, si somos tan grandes por cambiar algo, es un reto grandísimo,
por eso no vamos a atacar esto, porque yo, como una persona, no puedo, porque es un…
¿Cómo se cambia eso tan horroroso que estamos describiendo?
¿Qué haces para cambiar eso?
No, al final no es tan horroroso, porque…
Oye, eso es horrible.
Sí, es horroroso, sí, tú ves en esta manera, pero nadie,
no hay como iniciativa mala en esto, nadie está pensando que vale,
vamos a romper esto, sí, sí, pero es algo que tenemos que cambiar.
Es increíble cómo, o sea, sin mala fe, se puede ir al desastre,
todo el mundo, cada parte con buena fe.
Y cada persona está haciendo su trabajo, su trabajo definido, creo en este caso.
Y tiene una idea muy fuerte de cuál es su trabajo, de dónde empieza y dónde acaba.
Pero ese es el challenge principal aquí, es como siempre en todas las compañías, especialmente grandes,
más grandes como es comunicación y alineamiento.
¿Cómo podemos alinear todas estas personas si tenemos más de 200 personas?
¿Cómo podemos asegurar que ellos trabajen en la misma dirección?
Es primero, es un challenge grandísimo.
Al final, ¿qué hemos hecho?
Y para mí es un trabajo clave de middle management, de directores en este caso.
Porque es como ellos están, en nuestro caso es managers de managers,
están responsables de alinear todos los dominios y ver dónde tenemos estos puntos de conexión.
Y si Time tiene conexión con Core, Core tiene alguna dependencia con People, no sé.
Esto es su trabajo principal y no pasó antes.
Y al final, ahora, me parece que estamos más en mejor lugar comparado con hace seis meses en ese sentido.
El primer punto, para estructurarlo, yo claro estoy muy metido, pero la gente que se escucha igual no.
El primer punto es construir una capa de management, de directores,
que se pisa un poco, ¿no?
Que trabaja en el mismo proyecto en conjunto, en construir un solo producto, ¿no?
Exacto.
Pero también, en este caso, tenemos que romper estas cosas como falsos.
Al final, que Factorial es tan grande que no podemos meter todo roadmap de Factorial en cabeza de una persona.
Porque esto fue como un truismo.
El mantra.
El mantra que se repetía, ¿no?
Es que es demasiado grande, es demasiado complejo.
Exacto. Y eso no es verdad.
Porque sí, claro que estamos grande, pero no tan grande,
que es imposible para un Q revisar qué va a pasar en TodoFactorial.
Por eso es un primer requerimiento que todos los directores tienen que saber roadmap de TodoFactorial.
Porque solo en este caso podemos buscar estos puntos y overlaps de todos los dominios.
Si esto no pasa, claro que nunca podemos asegurar que a nivel de IC o a nivel de equipo,
ellos pueden tener estas conexiones.
Por eso es primero.
Segundo, es también revisar nuestros rituales y nuestra cadencia.
Porque al final, si estamos tan grandes, tenemos que buscar unas oportunidades,
comunicar a toda la compañía y a toda la gente.
Por eso ahora tenemos como en cada quarter, tenemos una serie de eventos que estamos asegurando que al final vamos a la misma dirección.
Primero es cada roadmap en primera de quarter, cada roadmap que tenemos está publicado en Slack y todo el mundo puede ver a nivel de equipo y a nivel de dominio.
Que es muy importante porque si producto al final no es solo para producto, es para ventas, es para customer success, es para todo el mundo.
Ellos tienen que tener y tienen que tener esta posibilidad de influir qué va a pasar en esta quarter.
Y normalmente todo el mundo está diciendo que cada día esto está pasando normalmente, pero no es verdad.
A veces es complicado, a veces tenemos día al día.
Por eso es tener una oportunidad en quarter cuando publicamos todos los roadmaps y todo el mundo puede ver.
Y ver si vale, ahora este equipo está pensando en atacar este pain, este challenge, es mejor y da oportunidad a todo el mundo de entender y cambiar algo en este momento.
Otro tema que es importante es también, es porque estoy saltando un poco, para mí, yo creo mucho en deadlines.
Para mí es algo muy importante y esta también es una oportunidad para alinear todos los equipos.
Por eso ahora tenemos la timeline o time slot normalmente a nivel de queue.
Todos los equipos están entregando algo al final de quarter y es como un deadline normal que está pasando.
Revisamos todas las entregas a nivel de quarter.
Por eso es algo, no es tan popular a veces en el mundo de ingeniería, porque todo el mundo está pensando que tenemos que deployar cuando estamos seguros que tiene calidad muy alta, pero yo no compro esto.
Porque normalmente tenemos tres variables que podemos incluir, recursos, scope y time.
Si fijamos dos de estos, recursos porque normalmente tiene, tamaño de equipo más o menos está definido, deadline, tenemos que entregar algo en seis semanas o en quarter.
Solo una cosa que podemos incluir es un scope.
Y es algo que es llave al final, porque si queremos un equipo...
Sí, porque si queremos un equipo que sabe qué está haciendo, que está alineado, ellos tienen que aprender 100% que es un challenge de usuario.
Al final, ¿por qué creamos este feature?
¿O por qué hacemos este refactoring?
¿O por qué hacemos algo?
¿Hay alguna razón dentro de esto?
Y sin aprender esto en detalle, tú no puedes incluir el scope.
Porque si tú no sabes por qué esto es siempre...
¿Cómo tú puedes decir si yo tengo que hacer parte de este feature o algo más global o puedo quitar esta esquina o no?
Es cortar algo si tú no sabes a dónde vas.
Por eso, sí, para mí es algo clave, otra vez es que si gente tiene su control 100%, si equipos tienen control 100% de scope, ellos automáticamente empiezan a aprender a por qué estamos haciendo esto.
Y para mí equipo no es solo ingeniería o es solo diseño o es solo PMs.
Al final es conjunto de todos.
Porque a veces en el mundo pasa que el proceso normal de desarrollo de producto, que yo normalmente estoy llamando a McDonald's, es que PM está encontrando un pain y está preparando un documento, un artefacto.
Está descripiendo, vale, la solución ideal es esta, vamos a añadir estos botones, vamos a añadir estas pantallas y ya está.
Después pasa esto al diseñador.
El diseñador coge solo este artefacto, sin conocimiento de usuario, sin conocimiento de nada, está pintando high fidelity screens y después pasando esto a ingeniería.
Ingeniería está desarrollando algo y deployando.
Al final en cada paso de esta cadena introducimos más y más ruido.
Y de inicial, que puede ser también no es tan buena de PM, al final se convierte en algo totalmente roto, totalmente diferente que el usuario no quiera.
Por eso, para mí una manera como construir producto sana es hacer overlap de todas estas partes.
Que PM tiene muy claro el pain de usuario y puede explicar solo pain, no la solución.
Y después pasar esto a equipo de diseño y equipo de ingeniería.
Y ellos, en un time box de seis semanas, de un quarter, tienen que llegar a una solución.
Pero tener en claro, primero, el input es un problema, un problema de usuario y no una solución.
Y normalmente este funciona mucho mejor comparado con McDonald's.
Y ese concepto del overlap es interesante porque el que se puedan pisar, el product manager, el product designer y el ingeniero,
en vez de trabajar en cadena, como dices, del McDonald's, del producto que pasa en muchas empresas,
hace que se cree cosas mucho más creativas, pero sobre todo hace que se priorice y se decida mejor.
Tú lo has dicho, ¿no?
O sea, al final, el construir un proyecto es un trade-off, es una dicotomía o una tricotomía entre el alcance, el tiempo y los recursos utilizados para construir el producto.
Entonces, como esto es muy difícil de terminar a priori porque hay muchas variables en muchísimas dimensiones que pueden aparecer en la construcción de un producto,
le das el ownership al equipo para que ellos dinámicamente decidan en base a la información que van recogiendo,
trabajen juntos, pisándose, construyendo una solución en conjunto, aunque el diseñador se encarga más del diseño y el ingeniero más de la ingeniería
y el product manager más del problema, los tres, o los tres roles, porque en realidad el equipo puede ser más grande si hay más ingenieros,
trabajan como un solo equipo, pensando como un solo equipo, decidiendo como un solo equipo,
y al final acaban teniendo el producto óptimo, que no has podido determinar a priori,
pero que confías en el equipo que es el producto óptimo con el tiempo y recursos, ¿no?
Y por eso es importante que el tiempo sea uno de los factores que se determina.
Y tú dices, bueno, en estos tres parámetros de alcance y recursos, yo te fijo el tiempo y los recursos, ¿no?
Son las personas que forman parte del equipo y el tiempo, entonces te dejo el scope, te doy la responsabilidad del alcance
para que tú decidas hasta dónde puedes llegar, ¿no?
Sí.
Y claro, ¿cuál es el incentivo del equipo de llegar lejos?
Porque dices, oye, pues voy a ser muy conservador y voy a hacer poquita cosa.
Sí, pero es normal también. También hay otra cosa que no es variable, y yo quiero hacer esto muy fijo,
es esta sensación de calidad, que también significa, vale, este fijo es parte de factorial,
¿y qué significa calidad de factorial aquí? Esto es como criterio interno, es algo que es muy complicado mostrar o poder...
Es describir.
Es describir, es verdad, tú tienes o no tienes, pero es algo que tú puedes aprender,
pero normalmente se transmite a nivel cultural, que tú ves, ¿vale?
Tradición oral.
Sí, como historias, sí.
Como la cultura misma.
Sí, sí, sí, sí, sí, pero es verdad, tú ves qué está pasando en otros equipos,
cómo estamos decidiendo que vale, es un buen producto o es un mal producto,
también revisando los números, pero hay un montón de cosas.
Pero al final, esto es, no podemos quitar esta variable, no podemos decidir que vale,
como es difícil de medir, pues no lo vamos a medir, ¿no?
Otro tema es como excusa, es solo seis semanas, tengo recursos limitados, es un problema complicado.
He hecho esta taca, pero es porque es que realmente no tengo más tiempo, ¿no?
Sí, sí, sí, sí, sí, pero también es importante aprender que vale, puede ser solo un botón,
pero un botón que funciona 100% de veces y está resolviendo un pain de usuario, ¿vale?
No es algo muy flashy, es un botón, pero exactamente, usuario quiere este botón.
Pero otro tema que a veces está pasando es, estamos invirtiendo,
invirtiendo, sí, gracias, un montón de tiempo en algo muy complicado,
pero no podemos traer en seis semanas o en un quarter, y por eso estamos casi ahí,
pero no sabemos si va a funcionar, es algo muy, muy complicado, usuarios no lo entiende,
y al final es también motivación de equipo, está totalmente en su suelo,
porque sí, claro, ellos que no pueden traer algo a producción.
Pero al final, esto pasa porque no tenemos este challenge dentro de un equipo.
Si el diseñador no puede trabajar con ingeniería, ingeniería no puede decir que vale,
porque no tiene sentido de mi punto de vista,
porque todo el mundo no tiene en su cabeza esta visión final de usuario.
Y cuando tú estás cambiando esto, magia, magia, empezará normalmente.
Volvemos al principio, donde yo te he preguntado,
¿qué pasa en los siguientes dos meses después de asumir este error, no?
Sí.
Hay una serie de discusiones y cambiamos la forma de hacer producto.
Sí.
O sea, la maquinaria de Factorial y cómo se construye producto cambia, ¿no?
Tú has hablado de, bueno, hay una serie de rituales.
Sí, sí.
O sea, básicamente, en general, en producto hay los rituales,
hay una serie de artefactos que la gente construye y mantiene,
hay una serie de incentivos, ¿no?
Sí.
Vale, finalizamos con...
Y la cultura también, ¿no?
Hay un montón de cosas.
Pero finalizamos con rituales porque sí, al final tenemos este principio de queue,
esto, kick-off, se llama, es que todo el mundo está publicando su roadmap.
Un queue, cuando dices un queue para la gente que no se ha metido en la jerga,
es un trimestre.
Ah, trimestre, gracias.
Sí, sí, sí, porque sí, sí, es un trimestre, sí.
Es como funciona el equipo de producto, piensa en trimestres.
Exacto, sí, es como...
Cuatro al año.
Sí, sí.
Y es como un calendario, sí, está definido de esas partes y normalmente estamos entregados
en cada quarter.
Claro que deploymos más cada día, pero al final que medimos y que revisamos es como un quarter.
O sea, el quarter es la unidad de valoración de los resultados hechos.
No es cuando se lanza el producto.
No, no, no.
Lo has dicho, se lanza, constantemente se está creando, se está cambiando el producto.
Pero al final del quarter es cuando se evalúa.
Sí, también paramos y pensamos, ¿a dónde vamos?
¿La dirección correcta?
No.
También es importante tener algunos puntos en su día a día.
Cuando vale todo este día o esta semana estoy totalmente en manera de revisar cosas.
Vale.
Y tenemos tres.
Primero, sí, es como este kick-off que todo el mundo está pensando que vale.
Esos son los rituales.
Sí, rituales.
Los eventos que pasan en la organización de productos.
Exacto.
De sincronización.
Sí, sí, sí.
Primero es, vamos con este plan, es nuestro roadmap.
Mitad de trimestre es a dónde publicamos primeros resultados que cada equipo está diciendo
que vale, nuestro plan inicial era esto.
Ahora estamos en esto, en este estado.
Es mira, puede ser una Figma o puede ser un demo real o algunos números nuevos.
Es vale.
Sí, gente va acá día al día aprendiendo contexto nuevo.
Ellos están reprocesando este contexto, están construyendo producto nuevo.
Y ahora es en mitad de quarter.
Podemos hacer un check-in y mostrar que vamos a la misma dirección.
Lo que tengo hecho.
Sí.
¿A quién lo muestran?
Sí, a todo el mundo en realidad.
A toda la compañía.
¿Por qué es importante?
Porque sí, todo el mundo está empezando.
Claro que podemos tener algunas dependencias con clientes, con ventas,
pero también todo el mundo puede aprender cómo desarrollamos producto y cómo pensamos.
Y por qué priorizamos algunas cosas sobre otras.
Y también que es importante, a veces es normal romper su roadmap.
Porque cada día tenemos un contexto nuevo y puede ser que tú vas a encontrar una oportunidad más grande que pensáis hace seis semanas.
Por eso es normal que decir que vale, chicos, totalmente repensamos nuestro roadmap, pero mira por qué.
Tenemos un documento o una lógica detrás.
No es porque no podemos entregar, es porque tenemos otra oportunidad más grande.
Y es otro momento donde es normal decir a todo el mundo que nuestro roadmap como equipo está cambiando.
Y al final de quarter, que es más importante, tenemos Product Review, que es también importante no solo para equipos, es también para directores.
Porque para mí, voy a repetir, podemos tener una compañía más grande de manera descentralizada, pero como empezamos todo el mundo va a su dirección.
Y yo quería hacer un poco de otra vez, es centralizar más cosas.
Y esta capa de middle management, directores en este caso, es otra cosa clave.
La clave de todo.
Sí, sí, sí, sí.
Que tiene que tener, sí, tenemos mucha gente ahí, pero al final mi idea es que cada persona piensa en la misma dirección y está alineado 100%.
Porque con este podemos tener que, vale, cada dominio está pensando a nivel de negocio.
Ellos tienen roadmap de todo factorial en su cabeza, por eso pueden encontrar cosas, conexiones.
Y también que tiene este criterio de calidad también compartido.
Porque es que es más importante, que vale en un dominio, no puede ser que es más relajado comparado con otro dominio,
que es a nivel de calidad, de visión de producto y de todo.
No, queremos deployar y tenemos que tener factorial como una compañía, un producto.
Pero tenemos un montón de gente.
Por eso es un challenge, es un DJM y real.
Tenemos que operar cada día.
Y en este caso, directores son claves.
O sea, esta construcción de criterio compartido, que es un problema en factorial,
tenemos de 220 personas, entre 10 y 20, en el equipo de producto, de los cuales 160 son ingenieros,
25 product managers, 25 diseñadores, más o menos.
Antes he hablado de que teníamos cuatro dominios, pero luego tenemos un quinto, que no me lo olvido,
que es la parte de infraestructura, donde está el data, donde están los analytics, donde está la parte de servidores, etc.
Entonces, también quiero finalizar con Product Review, que es para qué es tan importante para directorios y para esta capa,
que al final cogemos todos los equipos y todo lo que han entregado en este quarter,
y con todos los directores revisamos que vale producto por producto, si tiene esta calidad de factorial,
si ha entregado al final, porque es importante.
Deadline es algo que es deadline en realidad.
Si no ha entregado, es un fallo grande.
Tenemos que revisar por qué está pasando, qué con este equipo no es correcto.
Y también discutir cómo precisamos cosas y cómo desarrollamos.
Es algo importante para equipos para recibir este feedback constantemente de directores y de management,
pero es también muy importante para directores para lineados.
Eso es lo que iba a decir.
La parte más importante es crear esta conciencia compartida entre los directores.
Que todos los directores pueden ser reemplazables, que puedan dar feedback a los equipos,
que entiendan la misma visión de calidad, la misma visión de factorial en su conjunto.
Y para eso sirven también los Product Reviews.
No solo para que los propios equipos reciban el feedback de su equipo,
sino para que los directores se impregnen y consensúen,
se hagan el esfuerzo de discutir y de alinear los puntos.
Idealmente, equipos tienen que recibir feedback cada día de sus directores.
Pero también tenemos que tener un momento en un quarter donde podemos parar y también alinear a todos
y revisar qué vale, estamos en ello o no.
Y dar que este es feedback un poco más oficial.
Pero la idea es que si equipo llega a Product Review con una sorpresa,
que es algo malo, es un mal trabajo del director,
que el director no está dando feedback correctamente día a día.
Y es también un señal.
¿Qué implicaciones tiene este Product Review?
Sí, también me parece que aquí tenemos que tocar variables en general.
Cosas divertidas.
Sí, cosas divertidas que no es tan popular normalmente en ingeniería.
Por cierto que el bien y el mal en producto,
o sea, el definir esto es un buen producto o un mal producto,
es de las cosas más difíciles que hay.
100%.
Y no hay objetividad ahí, 100%.
Y no es posible hacer objetividad porque siempre como ingeniería todo el mundo puede gamificar algún sistema
y si algo es gamificable vamos a encontrar hackers.
O sea, al final un producto es una implementación de una visión fuerte,
de una opinión fuerte, subjetiva.
Y eso tiene que ver con factores estéticos, funcionales, varios factores en su conjunto.
Sí, con un montón de variables que no tú puedes poner en un papel.
En teoría con AI puede ser en algún momento,
pero ahora sí es que es importante tener todas las personas en la misma sala discutiendo parte del producto
para revisar si es un producto bueno o no.
Que al final en software B2B esto se traslada en conseguir el éxito del usuario y del cliente
porque al final el B2B lo que te permite es ser bastante más objetivo y racional.
Normalmente los clientes para los que trabajamos tienen un objetivo.
O bien ahorrarles tiempo o bien enablearles a hacer cosas que no podían hacer antes sin nuestro producto.
Y todo esto con una experiencia placentera.
Exacto.
Que es muy complicado al final.
Si tú pones solo los números vas a tener Excel, que al final está resolviendo un montón de pains.
Es que Excel es la hostia.
Sí, exactamente.
Pero nadie quiere usar Excel.
Pero nadie quiere usar Excel.
Todo el mundo lo usa.
Sí, exacto.
Pero ¿por qué no hay otra?
Pero al final sí, también queremos tener nuestra visión y queremos transmitir esta visión.
Y queremos tener un equipo muy fuerte que también no solo está ejecutando qué usuario está preguntando,
porque a veces usuarios tienen soluciones hechas en papel y todo.
Pero este equipo tiene que transmitir visión de facto real.
Y por eso empezamos con directores, con la idea que al final tenemos algo centralizado,
pero después descentralizado.
Que si tenemos directores alineados, ellos pueden vender y transmitir esta idea a todos los equipos al final.
Qué difícil es esta centralización y descentralización, ¿no?
Sí, es un challenge.
Es el challenge de todo.
Y también es un challenge que es muy lento al final ver los resultados.
Porque si tú puedes...
Normalmente todo el mundo está pensando que comunicación es algo que vale.
Yo voy a grabar un Zoom o voy a transmitir este mensaje y todo el mundo está entiendo este mensaje,
está recibiendo, pero no es verdad.
Tienes que...
Yo de hecho, Ilea, yo hablo contigo y te digo, oye, arregla el producto.
¡Ya!
Exacto.
Ya, ¿no?
Pero que la cuesta, ¿no?
Lleva tiempo, ¿no?
Sí, lleva tiempo, lleva tiempo.
Es verdad.
Pero este cambio cultural es...
Normalmente, sí.
Primero, tienes que cambiar cosas de manera muy rápida.
Porque si tú llevas en coche, hay GPS.
Y si tú pones en GPS, en dirección errónea, tú vas a...
Y si tú estás de cuenta, tú vas a parar y poner a correcta.
No vas a cinco kilómetros más y después poner a correcta.
Pero en este caso, en caso de nuestro tamaño, no somos un coche.
Somos como un liner.
¿Qué es un liner?
¿Un autobús?
No, un turist liner.
Como una...
¿Cómo es?
Un crucero.
Un crucero, sí.
Grandísimo.
Si tú vas a cambiar dirección, también con inercia, tú vas como...
Lleva tiempo, en este caso.
No sé, ¿eh?
Tú has visto el podcast de Lex Friedman con Jeff Bezos, ¿no?
Tengo en mi cola.
Nada nuevo, ¿no?
Seguramente para ti.
Pero es curioso porque él habla de que, o sea, una empresa como Amazon,
donde 1,5 millones de personas, trabajadores, ¿no?
Se mueven con muchísima agilidad, ¿no?
Y con una serie de principios muy básicos, ¿no?
Pero me interesa que significa que se mueve en este caso.
Ejecutar algo en los mismos principios es una cosa,
pero cambiar algo es otro tema.
Y cambiar en el chip.
Por mí, cosas culturales se cuestan mucho.
Claro, porque tu manera de pensar es algo que tú tienes que reforzar cada día con ejemplos.
Y cuando tú tienes más de 200 personas, es tiempo.
Sí, es que hay algunos factores culturales que nosotros nos damos cuenta,
los founders de Factorial, que por el camino vamos perdiendo, ¿no?
Porque para nosotros son muy intuitivos, ¿no?
El hecho de ese sentido de urgencia, el moverse rápido, el enfocarse al detalle,
el crear, ser hands-on, estar creando siempre, ¿no?
De golpe, cuando empiezas a crecer, empiezas a incorporar middle management,
a veces te encuentras que hay mucha gente que ya no crea.
Hay mucha gente que ya no se mueve, simplemente se dedica a comunicar, a hablar, ¿no?
Y pierde esta noción de detalle, esta noción de producto, de builder,
que cualquier emprendedor técnico normalmente tiene al principio, ¿no?
De construir producto.
Entonces, claro, es lo que nos pasa, ¿no?
Cuando nosotros nos empezamos a sentir, a nos sentir orgullosos de lo que estamos haciendo.
No es que el producto de Factorial esté roto, ¿eh?
O sea, no es que no funcione el producto de Factorial.
El producto de Factorial sigue siendo la herramienta elegida para un cliente
cuando le dan dos opciones, tres opciones, o prueba varias opciones en el mercado.
Pero sí que, comparado con nuestra expectativa,
esta expectativa de un diseño placentero,
de una experiencia que pasa sola, que funciona sola, que es casi mágica,
que al principio es como empieza Factorial,
hay un momento dado donde cortando corners y gestionando scopes
y en esta falta de comunicación y de colaboración,
se empieza a generar un producto más complejo.
Sí, 100%.
Pasa esto.
Y también, sí, es como al final, no hay mala fe, como estamos discutiendo.
Sí, al final, sí, sí, sí.
Habla de manager.
No, no, estoy pensando que al final todo el mundo está pensando,
vale, pero yo estoy ejecutando mi trabajo.
Estoy haciendo 100% todo correcto.
Pero al final no es un producto que estamos orgullosos.
Porque a veces sí tenemos que parar y pensar que, vale, es algo raro,
porque ahora estamos priorizando este feature sobre, no sé, calidad,
bugs o otro tema.
Y siempre tenemos que re-prioritizar cosas porque es otro challenge.
Pero la calidad nunca se negocia.
No, 100%.
Pero sí, claro, si todo el mundo está diciendo que tenemos que traer más features,
más features, más features, todo el mundo va a pensar que, vale,
calidad no es algo que es importante para nosotros.
Claro, pero es que más features con la misma calidad.
El problema siempre es esta definición de calidad.
O sea, esto que estabas diciendo al principio,
de cómo generar esta visión unificada, esta cultura fuerte de qué es calidad.
Yo hago una charla en junio o julio, en julio,
hago una charla en facturero y hago una presentación y me pongo
fix the product.
Ya estoy acabado mi trabajo, ¿no?
Mi trabajo siempre es lo más fácil.
Sí, literazgo.
Entonces, de golpe, todo el mundo empieza a hablar de fix the product
y cada uno significa, o sea, cada uno le atribuye algo diferente, ¿no?
Sí.
A fix the product.
¿Qué es fix the product, no?
Entonces, parte de...
Hay un montón de cosas, hay un montón de cosas.
Porque para algunos es bugs y es la ley,
para otros es como esta sensación de estamos orgullosos.
De experiencia, de diseño, de arte.
Sí, hay muchas cosas, sí.
Claro, entonces, claro, hay que unificar, ¿no?
Hay que consensuar.
Yo creo que estos meses, esto que tú describes como este proceso
de review, de alignment entre directores,
es un poco la discusión, la conversación larga,
con visión a largo plazo, ¿no?
Porque, oye, esto tienes que tener paciencia, ¿no?
Donde hay, existen todas estas discusiones, ¿no?
Se empiezan a producir estas discusiones y se empieza a tangibilizar
mediante la product review, que no es un algoritmo,
y es una putada porque los ingenieros buscan algoritmos
para medir el éxito.
Product review, donde los directores se comprometen
a dar un feedback profundo, denso,
de por qué sí y por qué no, ¿no?
Exacto.
Pero también es otro punto interesante a nivel de ingeniería,
por ejemplo, en este caso.
Si estamos hablando sobre directores, directores, directores,
pero no es solo directores que también se puede transmitir
esta sensación de calidad.
Para mí es también un nivel de seniority en ingeniería.
Es exactamente esto.
Es que alguien puede decir que, vale, no podemos deployar este,
o no es una manera como desarrollamos producto.
Tenemos otra.
Y puede levantar su mano y también decir que, vale,
no podemos continuar con esto.
Y yo veo ahora, después de estos cambios,
y este cambio del chip que le da,
es también algo que no podemos quitar,
que cada día, especialmente developers como ingeniería a nivel de staff
o senior, está liderando, como estoy diciendo, en campo.
¿Está liderando el qué?
En campo, en como en día a día.
En el día a día.
Sí, en día a día.
En el terreno.
En el terreno.
Sí, todo el mundo es como, vale, no.
Si queremos estar mostrando en su ejemplo,
cómo desarrollar producto de manera que estamos orgullosos.
Y para mí es otra pata, que es muy importante en ingeniería,
y es tener estos líderes a nivel de ingeniería,
no es como managers, pero a nivel de ICs,
Individual Contributors,
que está también mostrando y transmitiendo esta cultura.
Porque si tenemos developers a nivel de senior y staff
que está cometiendo errores, no errores,
que está quitando cosas muy importantes a nivel de calidad,
claro que después juniors o mids van a ver y pensar que, vale,
si staff no está haciendo esto, yo voy a repetir lo mismo,
porque es algo normal que está pasando en compañía.
O sea, no solo coges a los directores
y les transmites esta visión fuerte, esta idea de calidad,
sino también a algunos Individual Contributors,
algunos programadores individuales,
que tienen muchísima ascendencia en el equipo
y porque tienen mucha seniority.
Para mí es una definición de seniority, al final.
Si solo pensamos en seniority es como hard skills 100%,
¿qué es la diferencia desde staff y senior?
Porque una persona que está programando muy bien,
va a programar mejor,
aquí perdemos una oportunidad.
Porque yo veo a todos los staffs como líderes al final.
Y para mí líderes es alguien que también no solo está haciendo código,
que es que está también levantando nivel general de cultura y de ingeniería.
Por eso está transmitiendo mucho, está revisando,
está mostrando qué es bien y qué es mal,
haciendo mentoring y también conectando puntos a nivel de todo factorial.
Porque también esto, alineamiento de roadmap,
puede ser hacer directores,
pero cosas técnicas yo estoy confiando mucho en mis staffs.
¿Qué significa staff?
Porque normalmente en career path de ingeniería tú tienes juniors,
meets y seniors.
Y después de seniors hay staff developers,
que es alguien con un montón de experiencia y con este nivel de liderazgo.
Y es seniority.
Es una marca de seniority en este caso.
Y para mí ellos están 100% responsables también
al levantar la cultura de ingeniería.
¿La cultura?
La cultura de ingeniería.
Y la calidad.
El nivel.
Definir la calidad.
Sí, exacto.
Es todo.
La cultura está como conjunto de todo.
En este caso.
O sea, es otra forma de liderazgo que no es funcional,
no es de reporting,
como pasa habitualmente en las organizaciones,
sino que es meritocrático,
puramente técnico de liderazgo.
Es ejemplo.
Y algunos de estos ingenieros pueden tener más impacto incluso que un manager.
100%.
Ellos solos pueden proponer una nueva forma de hacer algo
que acaba siendo lo que cambia el mercado.
Exacto.
Y es otra parte de descentralización para mí que es importante.
Si queremos centralizar el roadmap,
queremos centralizar la visión,
pero ¿cómo transmitimos esto después a todos los ingenieros que tenemos?
Para mí estas simillas, en este caso a nivel de staffs,
es una manera como muy importante para hacer esto.
Vale.
Hemos hablado de rituales.
A nivel de artefactos,
¿cuáles son los documentos en común que comparte la organización de producto
y que de alguna forma permiten seguir cómo vamos?
Es un buen tópico porque al final empezamos con un montón de artefactos,
que cada dominio tenía su artefacto, un montón de roadmaps, un montón de QRs.
Notions.
Notions, sí, sí, sí.
Hay notions para todo.
Pero al final ahora los vemos que sí, es que ¿en qué métricas estamos interesados en cada producto?
Si estamos a ver si es healthy o no healthy, si es sano o no sano.
Al final es usage, MRR y empiece, más o menos.
Es como tres que podemos ver cada producto y tener alguna, como, algún luz,
color verde o color amarillo, si todo va bien, no sé, todo va mal en este caso.
Y para mí es importante si todo el mundo puede saber como mínimo estas tres métricas.
SLA no lo has hablado, ¿eh?
SLA es otro tema, sí.
Es porque, sí, vamos a sacar esto.
O sea, me has dicho usage, que vendría a ser la métrica de éxito de un producto.
Es decir, para que este producto tenga éxito hay que hacer X acciones, eventos dentro del producto.
Esto lo define, cada equipo se consensúa con el dominio y con todo el mundo
y pasa a ser la métrica que se sigue equipo a equipo, ¿no?
Esto es usage.
Luego has dicho NPS, que básicamente es una métrica de satisfacción por parte del usuario
cuando le preguntas explícitamente qué probabilidad tendría de recomendar esta funcionalidad
a un amigo, ¿no?
Y tiene un sistema de respuestas donde, bueno, se eliminan los pasivos,
se restan los detractores a los promotores y te da un número, ¿no?
Esto es el NPS.
Y luego, la tercera cosa que has dicho era…
¿MRR?
MRR.
¡Se me ha olvidado!
¡Qué fuerte!
Que es básicamente la métrica de facturación o de revenue, de suscripción.
En el caso de MRR es monthly recurring revenue.
Exacto.
Sí.
Por cierto, te he hecho una putada hablando en español.
Normalmente hablamos en inglés.
En factorial he dicho, no, por favor, hoy es en español.
Muy bien, ¿eh?
Sí, sí, sí.
Pero al final, si quieres tocar también…
Sí, estos tres métricos son muy importantes.
Todo el mundo tiene que saber esto, no solo PM, porque a veces es otro error.
En mi equipo lleva esta métrica de MRR solo Product Manager.
No, ingeniería lleva también y diseño lleva también.
Todo el mundo está revisando esto.
Todo el mundo está responsable para esto.
Y es muy importante si queremos al final tener esto en Power Team.
Pero sí, al final yo quiero a todo el mundo que tiene esta responsabilidad y que pueda asumir
esta responsabilidad y no te puedes poner dedos.
Pero otra cosa es esa ley, es que calidad es como más de bugs que todo el mundo no le gusta.
Esa qué significa esa ley en este caso.
Si nos, como ingeniería o producto, llega un bug de un usario, depende de su importancia de este bug
algunos tiempos para resolver esto.
Si es bug muy importante, como nada, nada está cargando, nada funciona.
Claro que olvidamos todo y estamos arreglando.
Si es P1 es como 5 días, si es P2 es 15 días, vale, no es tan importante.
Pero al final cada bug está, estamos priorizando, depende de su importancia.
Y sí, al final también es muy importante para el equipo aprender que en B2B,
bugs tienen solamente otra significación que comparado en B2C.
porque cada usuario, cada empresa, tiene confianza en Factorial, pone su información muy importante.
Y esta confianza para nosotros es vital.
Si al final rompemos esto, vale, no tenemos negocio.
Y por eso si tenemos un bug y llevamos un montón de tiempo resolviendo este bug, vale,
yo voy a quitar un poco de confianza.
La confianza.
La confianza, sí, gota por gota.
Y por eso es importante aprender que bugs para nosotros es algo que no podemos olvidar 100%.
Pero también a veces es muy bien decir esto, que sí, bugs son importantes.
Por favor, ingenieros, arreglen cosas.
Ingenieros que pueden decir que sí, sí, yo quiero arreglar.
Es más, ¿están de acuerdo?
Sí, sí.
Normalmente siempre todo el mundo está de acuerdo.
Tengo mi roadmap muy grande, tengo un montón de presión de todo el mundo,
que tengo que desarrollar features nuevos.
Y cómo puedo también hacer este equilibrio, balancear, equilibrar.
Entre cosas nuevas y arreglar los problemas.
Exacto, exacto.
Por eso es un mensaje, al final, otro alineamiento que tenemos que tener a nivel de toda la compañía.
Y resolvemos esto con variables.
Con cosas no tan populares en el mundo de ingeniería.
Pero para mí no es algo de, ah, esto es otra manera como empresa puede dar dinero.
No es otra, es herramienta muy potente para enviar señales.
Pero más que variables, o sea, que estoy de acuerdo, 100% de acuerdo, objetivos, ¿no?
Son los objetivos, previo a los variables, ¿qué objetivos le ponemos a la gente?
Exacto, exacto.
Pero también sí, también tenemos que tener este señal.
Porque sí, claro, como AQR, podemos tener un objetivo,
pero si no llegamos a este objetivo y no pasa nada, no es tan importante para mí este objetivo.
Y sí, también tú puedes tener tu roadmap como objetivo y tu SLA como objetivo.
O sea que normalmente hay muchos objetivos sin consecuencias.
Exacto. Pero también es complicado día al día priorizar.
Tengo dos objetivos, roadmap y SLA.
¿Cómo puedo priorizar que es una importante o otra importante?
Por eso tenemos que resolver esto y que la gente piensa menos en este nivel
y tiene muy, como señal, muy fácil para aprender.
Y al final es un variable en este caso.
Y tenemos exactamente variable en tres partes de variable.
Primero es SLA que tenemos a nivel de todos los puntos a nivel de factorial que no podemos sobrepasar.
Si sobrepasamos, también tengo que decir que son los puntos,
estos tiempos que he comentado antes a nivel de qué es prioritario, qué es todo todo,
si sobrepasamos este deadline de cuando resolvemos el bug, empezamos a asumir puntos.
Y depende de cada bug, asumimos más puntos o menos.
Pero al final podemos ver cómo factorial, como un equipo, estamos en general tratando más resolviendo bugs.
Por eso tenemos, no sé, 2.000 puntos, 3.000 puntos, 10.000 puntos, algún número.
Y si bajamos este número, mejoramos.
Si este número crece, peoramos.
Por eso parte de...
Para resolver esto ponemos una meta, que no vamos a sobrepasar 500 puntos al final, como factorial.
En general.
Es algo compartido.
En un trimestre.
En un trimestre.
En un trimestre es algo compartido con todos los equipos.
Por eso no hay discusión si es mi bug o es bug de otro equipo.
No, no es todo para factorial y tenemos que tener esta sensación de calidad a todos los developers, diseñadores y product managers.
Están bien compartidos a todos los niveles.
Y con esto resolvemos esta discusión.
Si tengo que priorizar PM, roadmap o tengo que priorizar SLA.
Ahora tenemos una meta que está muy conectada también a tu usuario.
Si no llegamos a estos 500 puntos, nadie en producto recibe parte de su variable.
Ahí está.
O sea, ¿cuáles son los objetivos que tienen los equipos de producto?
Uno es SLA.
Uno es SLA.
Como atacan el problema de calidad técnica del producto.
Sí, exacto.
Y también es tiempo de dispuesto en este caso.
Otro tema es entrega.
Es este product review que tenemos para cada equipo.
Revisamos que cada equipo está entregando y los directores están también evaluando si este equipo tiene que cobrar su variable o no tiene que cobrar su variable.
Para mí es otro tema.
Si tenemos otra sorpresa y algo y un equipo no está comprando, no es también solo una penalización monetaria.
Es también un señal muy fuerte que en este equipo algo está roto.
Que tenemos que repensar procesos ahora porque este equipo no funciona.
O sea, por defecto en la product review lo normal es que se apruebe, digamos.
Exacto.
O sea, que todo está bien.
Se han tomado decisiones, se ha explicado el razonamiento y en este razonamiento se valora este proceso de decisión, de gestión del scope.
Y lo normal es que esto esté bien.
Pero si no está bien, entonces no solo este equipo no va a cobrar una parte de su variable, sino que además tenemos un problema estructural en este equipo.
Exacto.
Sí, es una posibilidad para directores y todo el mundo revisar qué está pasando.
Porque no puede ser que en dos quarters el mismo equipo no esté cobrando esta parte porque si está pasando algo está totalmente fatal.
Y también es otro tema que queremos hacer algo de manera muy explícita porque antes, normalmente en cada compañía está pasando exactamente esto.
Hay algunos equipos muy buenos, hay otros equipos que son malos, como ponemos en este caso.
Y aquí tenemos que mostrar a todo el mundo que vale, hay algunos equipos con problemas y tenemos que resolver esto.
Si no resolvemos es como no hay sorpresas para nada si, por ejemplo, tenemos que reestructurizar todo el equipo.
Vale, y tienen que de alguna forma los equipos ayudar a los otros, ayudarse, subir el nivel, ¿no?
Sí, sí, sí.
Para asegurarse que la calidad es la que buscamos entre todos los equipos.
Hemos dicho Product Review a nivel de objetivos.
Me has dicho la valoración de todos los directores que hacen sobre la entrega y las decisiones tomadas por un equipo.
El SLA.
¿Y el tercero?
MRR.
MRR.
MRR, sí.
Es también parte muy importante para el…
Negocio.
Negocio, sí, exactamente.
Porque al final no podemos pensar que el producto está totalmente desconectado de ventas, de Customer Success, de mercado, de todo.
Y que estamos desarrollando algo muy diferente.
Hay un argumento que se escucha mucho, ¿no?
Que es cuando le pones a un equipo de producto un objetivo de MRR, pasa a pensar a corto plazo.
Deja de pensar a largo plazo.
¿Tú qué piensas de esto?
¿Podría salir más detalles?
¿Qué significa esto?
No, bueno, a ver, es lo que dice el equipo de…
Concretamente, algunas personas del equipo de Factoria, ¿no?
O sea, dicen, hostia, pero es que si me pones un objetivo voy a maximizar el MRR, ¿no?
Y igual me voy a dejar de trabajar en cosas más a largo plazo.
Vale.
No, me gusta si alguien puede maximizar el MRR, me suena muy sano en este caso.
Pero al final yo puedo pensar qué puede ser en este…
Que vale.
Que yo puedo imaginar, si tenemos esta parte de MRR, al final podemos olvidar cosas más orgullosas de producto.
Que es verdad.
Si no vamos a pensar a nivel de animación complejos o alguna solución más general que no puede cambiar el MRR en este quarter, pero sí, claro, que puede cambiar algo en futuro, futuro.
Yo puedo ver este argumento, pero también para mí es cosa cultural.
Si pensamos que, vale, para mí es imposible ver si repetimos la misma abstracción o la misma idea siempre en diferentes partes del producto y no podemos unificar esto y decidir que no voy a hacer esto porque tengo mi variable en MRR, no vamos a comprar.
Yo tiendo a pensar que la gente es más lista que yo, en general, y más el equipo de producto, bueno, todos los equipos, pero veo el equipo de producto, gente que sabe mucho, que tiene opiniones muy fuertes.
Entonces, si yo soy capaz de balancear el corto, el medio y el largo plazo, ¿por qué no debería hacerlo un equipo de producto?
¿Por qué no deberían pensar en sus yo's dentro de seis meses? En sus yo's dentro de doce meses, ¿no?
Pero también es importante, ¿no? A veces no es priorizar, pero es también conectar, porque cuando añadimos esta variable, es una anécdota, pero al final he recibido tantas preguntas sobre negocio de ingeniería que me gustan mucho.
Cuando gente está aprendiendo variables, funnel, conversion rates, todo, es muy sano, porque al final todo el mundo erróneamente está pensando que yo no puedo influir en nada.
No, no es verdad. Si ingeniería no puede influir en nada, nadie en teoría puede influir en nada, porque ellos normalmente están desarrollando cosas nuevas.
Por eso, en este caso, para mí, no estoy comprando.
Y luego el tema también del largo plazo, al final, desde mi punto de vista, es que hay una sola vida.
Entonces, en esta vida tenemos que conseguir crear una historia, una narrativa, ¿no?
¿Qué es lo que estoy haciendo con mi vida para sentirme orgulloso?
Y tú tienes la oportunidad de estar trabajando en un producto que le va a cambiar la vida a las personas, que utilizan, en este caso, 600.000 personas en su día a día, que es de alto uso.
Y tú te estás planteando, de verdad, te estás planteando, voy a maximizar esto a corto plazo porque voy a cobrar el variable.
Yo creo que hay que pensar en cobrar el variable.
Es una parte importante porque cobrando tu variable va a cobrarlo también el resto de la organización, marketing y ventas, que viven en este quarter, que viven en este mes, que tienen objetivos.
Pero también tienes que pensar en generar esta historia y esta solución rompedora, ¿no?
Y esto requiere madurez, requiere cultura y por eso no todo el mundo sirve para trabajar en Factorial, ¿eh?
Y eso es lo que te iba a preguntar ahora, ¿eh? ¿Qué perfiles buscas tú en tu equipo?
Con agencia.
Normalmente, si, no sé, con Cristiano es el mismo.
La verdad es que no sé. Agencia es con…
Agency.
Sí.
Con iniciativa, con drive, con responsabilidad.
Para mí es una bandera muy roja.
Yo voy a preguntar por qué estamos haciendo esto y alguien me está respondiendo por qué.
Alguien me ha dicho.
Es, para mí, yo voy normalmente, tengo…
Desconectado.
Desconectado y todo es… Estoy furioso después.
Sí, pero porque es algo que me está atrigando mucho.
Y, sí, gente que estoy buscando no pueden decir esto.
Y no quieren decir esto. No es normal para ellos decir frase como esto.
Ellos están aprendiendo muy claro por qué está haciendo esto y tengo su visión, que es bien o que es mal.
Y si algo está fuera de su visión, ellos van a levantar su mano y decir que tenemos un problema aquí.
Tenemos que revisar, tenemos que repensar.
¿Se van a negar a hacer algo…
Sí.
Que no compran.
Cien por cien.
Que no es lo que pasaba.
Porque, ojo, que antes has dicho, bueno, la gente tiene buena fe, pero no está cambiando esto que ve que no…
Sí, cien por cien.
Por eso es una… un moto de Factorial que es convince o get convinced.
Que es al contrario de Amazon, ¿no? Aparentemente.
Depende.
Faltamos detalles ahí.
Básicamente el disagree and commit, ¿no? Estas dos culturas, ¿no? Disagree and commit o convince or get convinced, ¿no?
Sí, sí, sí.
Pero me parece es el mismo al final. Sí, es como falta detalles, falta marketing, pero es muy importante.
Si tú no estás comprando algo, si tú no entiendes cien por cien que estás cometiendo, tienes que tener tu discusión fuerte, muy fuerte.
Y es sano tener discusiones fuertes, pero es también importante salir a una sala después que todo el mundo está teniendo muy claro por qué tomamos alguna decisión o una decisión u otra.
Y especialmente a nivel de management, a nivel de directores, porque si ellos no están comprando algo, algunos cambios…
Es el fin del mundo.
Sí, ellos no pueden liderar después a sus equipos, porque al final también es muy importante a nivel de director que ellos no son proxys o son transmitidores de decisiones.
Ellos son líderes. Y sin agencia esto no puede pasar.
Lo mismo con staff, ¿no?
Y lo mismo con staff.
Pero en general en todo el mundo, ¿no? Porque tenemos, casualmente tenemos gente muy joven, junior, que tienen unas opiniones fuertísimas y que las batallan, ¿no?
Y que discuten, ¿no? Y esa cultura donde esto pasa, para mí es clave, ¿no?
Donde al final cualquier persona puede imponer su criterio con información, con data, ¿no?
Cien por cien, sí, sí, sí.
Pero es también que es importante, si no es solo imponer criterio, pero asumir responsabilidad.
Pero a veces sí, también es complicado.
Y a veces también la cultura de ingeniería en general que está pasando en otras compañías, que, ¿vale?
Tenemos algunos sprints, algunas cosas, estamos trabajando, pero si algo está rota…
Ah, no es nuestro. Y yo también, es otro trigger para mí, que es al final, si algo está roto y tú lo ves, tú tienes que arreglar o tú tienes que llevar a otro equipo,
tú tienes que asumir responsabilidad de todo factor y no solo de tu equipo.
¿Cómo se incentiva que alguien que tiene un objetivo de calidad, MRR y entrega del producto en su equipo en el trimestre, tal y como ha previsto y tomando las decisiones adecuadas,
¿cómo se incentiva que coja un problema común, igual fuera de su equipo, igual, ¿no? Algo genérico del producto y lo arregle?
Porque al final, gente listo está… tiene esta sensación muy clara que todo es conectado.
Si tú ves un problema que tú arreglas… y tú también tienes muy claro que es algo importante, porque a veces es no,
es muy conectada a MRR, es muy conectada a calidad y después va a quitar…
Pero igual no MRR es un producto concreto.
Sí, pero MRR de facto real, pero al final MRR de facto real.
Claro, pero esto es la tragedia de los comunes, de todos los espacios comunes.
¿Cómo se encarga? Porque luego, evidentemente, tenemos un dominio del espacio común, de core, ¿no?
Pero es imposible, por grande que fuera ese dominio, es imposible que se encargara de todos los problemas comunes, ¿no?
Sí, 100%.
Al final, ¿o es un factor cultural?
Para mí, es exactamente lo que tienen que llevar a staff, developers y más.
Porque si ellos están… claro que es para todo el mundo, pero para ellos exactamente es su job description.
Que al final, llevar cosas comunes y al final entregar impacto a nivel de todo factorial.
A veces es complicado y es también que quiero cambiar mucho, es que staffs para pensar que, vale, mi día a día es solo entregar código.
Si staff piensa esto, tenemos una oportunidad perdida, muy perdida en este caso.
Y para mí, staffs también tienen que dedicar mucho tiempo a tener contexto de todo negocio, tener contexto de otros equipos, llevar algunos, sí, revisar código mucho, revisar problemas en otros equipos en su dominio también, para buscar estos puntos, ¿vale?
Yo veo aquí algo común, yo veo ahí algo común, ¿cómo puedo arreglar esto?
Y hay un montón de soluciones, vídeos, comunicaciones, un código nuevo, abstracción nueva, hay un montón.
Pero también es muy complicado poner esto solo en description, porque para mí es que más senior persona hay, es más complicado definir su job role.
Porque, claro, hay un montón de variables, como lo mismo como en calidad.
Y para mí es también importante que la gente esté aprendiendo que, a nivel de staff y más, yo tengo que buscar oportunidades para negocio y alinear conmigo, con directores, qué significa esta oportunidad en este caso.
¿Cuántos staffs tienes en factorial?
Más 10, 12 personas, me parece.
¿10, 12 personas?
Sí, sí.
¿Y directores?
Directores, 5.
¿5?
De ingeniería, 5, sí.
Y luego tienen por debajo engineering managers, cada uno de ellos tiene entre 4 y 6 personas, ¿no?
Sí, sí, sí.
¿Qué tiene que hacer un desarrollador para promocionarse, para crecer?
Siendo que es una pregunta que mucha gente se hace, ¿no? Dentro de Factoria.
Exacto.
Y también es un challenge en todos los equipos, porque al final tenemos Career Path, es un documento que está describiendo que, vale, sí.
¿Cómo tú puedes crecer en Factoria?
Y para mí es algo sano, es muy bien que tenemos y es algo importante, pero también si tú pones, si tú haces muy, muy complicado, va a convertirse como en un juego.
Si yo voy a cerrar todos estos puntos, automáticamente me va a promocionar.
Un algoritmo, ¿no?
Un algoritmo, exacto.
Y es algo complicado a veces porque, claro, vamos a repetir lo mismo, que es en compañía, en un startup, cada día recibimos un nuevo contexto.
Y a veces solo cerrar todos los puntos no significa promoción.
Y también depende de tu manager.
Para algunos esto sí, para otros también tiene otra definición que es de cada uno de estos puntos.
Por eso no es algo que hemos solucionado 100%, es algo que intentamos solucionar, pero al final es lo mismo.
Primero, todas las promociones son públicas, que cada vez que promocionamos a una persona estamos publicando documentos por qué promocionamos a esta persona.
Y para mí es lo mismo, es cambio cultural.
Todo el mundo está revisando que, vale, tenemos una persona aquí que ahora es un señor y por qué hace A, B, C, D.
También yo voy, si yo soy un MIT, yo voy a revisar o yo voy a capiar.
Por eso, cada promotion también está revisando por director.
Y si estamos directores alineados, es muy fácil que revisamos todas las promociones.
Estamos seguros que en este documento todo es muy explicado por qué promocionamos a esta persona.
Y para mí es más importante, sí, es muy importante tener este documento que Carrier Path,
pero en realidad yo quiero que todo el mundo esté revisando por qué promocionamos gente y está conectando dots por sí mismo.
¿Quién recluta en Factorian?
Managers, en el sentido que sí tenemos reclutores en idea clásica, pero ellos están ayudando más con funnel y con algunos filtros.
Pero es también importante que todo el mundo, todos los managers, directores, están haciendo hiring.
Y también yo, porque yo estoy como un punto final en todos los hiring procesos,
porque para mí es importante, si no queremos romper la cultura de Factorian al final que tenemos y que mejoramos día al día,
para mí es importante revisar toda la gente que está entrando.
Y también es otro tema que al final es muy complicado alinearnos.
Si contratamos gente correcta, porque si tú, si estamos cinco dominios, un montón de managers y cada persona está contratando,
claro que tú tienes su visión, su experiencia de contratar y su criterio.
Que a veces al final vamos a tener un señor, una persona que es señor en un dominio que es en realidad señor,
y otro dominio que puede ser un junior, pero lleva un título de señor.
Esta inflación de títulos puede pasar.
Por eso al final resolvemos esto con la persona que está responsable de contratar a su manager,
pero también tenemos un equipo de, es lo mismo como en Amazon Bar Razers,
que es un equipo de confianza interno que está revisando todo el código de challenges que estamos recibiendo
y está poniendo su consumo de interés.
Los challenges son las pruebas técnicas que hace todo el mundo que aplica a Factorian.
Para entrar. Con este podemos también tener una expectación generalizada,
que es un challenge bueno, que es un challenge malo en este caso, y evitamos sorpresas.
Y yo como un challenge final para cada persona que está entrando.
Para mí es muy importante también enviar este mensaje, que sí estamos más o menos grandes,
y en teoría yo no puedo ser como una persona final en todos los hiring, pero no es verdad.
Podemos hacer cosas que no son escalables, pero es solo la única manera como podemos controlar al final la calidad
y revisar que cada persona que entra es muy buena persona.
¿Has rechazado algún perfil?
Un montón.
¿Por qué?
Ah, ¿yo personalmente?
Sí, a veces sí, es porque no tiene esta visión de producto, no tiene esta agencia.
Para mí es algo que yo estoy intentando verificar en cada entrevista que tengo.
Porque si todo el mundo está con energía baja en este sentido, que no tiene esta iniciativa,
es también algo que está cambiando a su alrededor.
Por eso yo estoy buscando también gente que tiene un montón de iniciativas y puede explicarme en su puesto anterior
qué cosas han cambiado.
Es también importante.
Un Empower Team, ¿no?
Que le llamamos.
Sí.
¿Cómo está formado?
¿Quién hay en un equipo que lleva una parte del producto?
Esta parte no hemos cambiado.
Al final tenemos Product Manager, Product Designer, Engineering Manager, Engineering Manager también.
Y un equipo de ingeniería.
¿Cuántos?
Depende, pero máximo seis.
Seis o ocho en algunos equipos.
Pero sí, al final es como máximo de manager en este caso.
Y para mí Empower Team significa lo mismo que hemos discutido.
Que ellos tienen muy claro que tienen que resolver todos los problemas de usuario.
Están controlando su scope y están entregando.
¿Cuál es para ti el rol del Product Manager?
Es encontrar pains, encontrar problemas de usuario y hacer go to market.
Porque este es también muy importante al final.
Y que estamos fallando un montón de equipos.
Están fallando en general, no es solo en Factorel.
Que estamos ceñando y haciendo cosas muy buenas.
Que tenemos un buen feedback de usuarios.
Pero no sabemos cómo vender esto.
Y cómo después podemos mostrar a todo el equipo de go to market.
Cómo vender a todo el mundo.
Y esta para mí es una responsabilidad del Product Manager.
Liderar el proceso de go to market.
Exacto.
Empezar a ser los pioneros del go to market.
Sí, sí, sí.
¿Y el Product Designer?
Para mí es un mejor amigo de ingeniería.
En el sentido de que ellos siempre tienen que trabajar juntos.
Porque siempre que yo, cuando yo veo que todos los features nuevos están empezando con High Fidelity Designs.
Para mí es algo erróneo 100%.
Porque ingeniería y diseño, cuando trabajan juntos, están haciendo un montón de prototipos.
Verificando cosas.
Discutiendo cómo podemos solucionarlas de manera más rápida.
Porque es muy importante entregar algo a usuario final para recibir feedback.
Antes de este momento, tú estás solo pensando cosas.
Pero que al final tiene sentido este feedback de usuario.
Cuando tú muestras algo que no es solo prototipo en Figma.
Que ellos pueden tocar y usar en su día al día en su empresa.
Por eso este tiempo, time to market, pero time to prototipo, en mi cabeza, es algo muy importante.
Y que tenemos que mejorar en cada equipo.
Pero solo una manera para hacer esto es diseño.
Estar trabajando juntos con ingeniería.
Tienen que ser uno, ¿no?
Tienen que tener la visión tecnológica muy clara.
Exacto, exacto.
No pintar pantalla.
Pero es también importante, estoy pensando esto a nivel de que es empower team.
Que es empower dominio en este sentido.
Porque si solo continuamos con esta manera.
Pero cada equipo es un silo.
Que está tocando solo su parte del producto.
Y está planificando todos los challenges y pains.
Solo su parte del producto.
Vamos a continuar con lo mismo.
Por eso es importante que ellos estén revisando scope de todo el dominio que tenemos.
De todos los challenges a nivel de como una familia de productos.
Y porque a veces está pasando que tú tienes una iniciativa o una oportunidad más grande.
Más derecha.
En otro equipo o en otra parte del dominio.
Y tú puedes sacar esto, arreglar esto.
Y al final llevar más MR, más usage, más...
Todo más.
¿Cuáles son los principales retos de cada año que viene?
Pregunta así muy...
Sí, también lo estoy pensando, sí.
Muy abierta, ¿no?
Pero si tuvieras que encontrar cuáles son las cosas que más te preocupan.
O las mayores oportunidades de cada año que viene para el equipo de producto de Factorium.
Para mí es continuar con este alineamiento de directores.
Que ellos, sí, es como...
Tenemos que buscar a algunas personas.
Pero tenemos que encontrar algunas perfiles.
Y alinear todo el mundo.
Y después...
Cambiar este chip cultural.
Porque yo veo algunos cambios ahora después de estos cinco o seis meses.
Pero no estamos ahí.
Tenemos que trabajar más.
Y al final, para mí es un challenge que a nivel de directores, a nivel de staffs.
Quiero otra capa de...
Staff developers que yo puedo confiar mucho.
Que ellos van a levantar en cultura.
Que ellos van a liderar algunas iniciativas desde bottom-up.
Sí, y...
Por eso.
Continuar con el proceso que tenemos.
Pero escalar, escalar, escalar.
En este caso.
Muy bien.
Oye, pues yo creo que te he preguntado casi todo.
No sé si me he dejado algo.
Bueno, lo que no te he preguntado es cómo fue tu experiencia previa, ¿no?
Tú montaste un negocio.
Sí.
Sí, he intentado.
He intentado montar un negocio.
¿Y qué pasó ahí?
Sí, fue una experiencia parcialmente brutal.
Pero es también que yo, si yo pueda...
Si yo voy a tener una Time Machine, yo voy a repetir lo mismo 100%.
Al final, yo tengo...
O sea, volverías a hacerlo, ¿eh?
Sí, 100%.
100%.
Porque antes de eso, o sea, tú estudiaste informática en Rusia.
Sí.
Robótica.
¿En robótica?
Sí, sí.
Robótica, ¿eh?
Sí.
Automotización.
Automotización, sí.
Vale.
¿Qué hiciste antes de RedBuds?
Rápidamente, brevemente.
Antes de RedBuds, vale.
Inicialmente, he aprendido a hacer programación haciendo mi propio startup.
Porque yo quería hacer un to-do list en manera muy diferente.
Qué raro, ¿eh?
Un ingeniero haciendo una herramienta de to-do list.
Nadie lo hemos hecho.
Sí, sí, sí.
Pero totalmente diferente.
Era totalmente diferente.
Siempre pensamos eso.
Sí, sí, sí.
Es verdad.
Y al final, sí.
Y mi motivación fue, vale, me falta esto, yo quiero tener esto, ¿cómo puedo?
Aprendí a programar.
También he montado un equipo, he encontrado un diseñador, otro programador, todo sin pagar
nada porque sí fue 100%.
¿Eran gratis?
¿En Rusia son gratis?
Todo es gratis, sí, claro.
Comunismo, ¿sabes?
El señor es gratis.
Porque sí, estamos en España.
Vale.
Y al final, sí, es...
No, es porque pensamos en idea, sí, motivamos gente, no cobramos a nuestros usuarios, pero
al final...
Cómo arranca todo.
Sí, sí, sí, cómo arranca todo.
Startup 100%.
Pero al final hemos tenido un éxito.
Es año 2008, 2009.
Es que cuando publicamos algunos portales como Product Hunt ahora, es en la misma noche
tenemos un mil de usuarios, sí, un montón de...
¿Mil?
Mil, sí.
En ocho horas, sí, es como hace doce años.
¿Doce años?
Doce años, sí.
Es como internet en Rusia totalmente fue diferente y todo.
Pero sí, fue un primer de estos to-do lists con web 2.0, totalmente con Ajax y todo, es
muy diferente y tenía un buen de pinta.
Pero después desarrollamos tiempo libre para dos más años y hemos vendido este proyecto.
Sí, al final fue como un primer éxito con...
¿Vale?
Desde cero he recibido algunos...
Algún dinero y fue como...
¡Ostras!
Sí, un buen ejemplo para...
¿Vale?
Yo puedo montar equipo, yo puedo encontrar una idea, yo puedo vender.
¿Pero durante los dos años nadie cobró?
No, nadie.
Porque es imposible.
En este momento en Rusia no había esta experiencia de pagar...
¿Los programadores?
Ah, no, no.
Sí, porque al final...
Digo, la gente que trabajaba, ¿eh?
¿Los programadores?
Pero todo el mundo tiene una parte de este proyecto.
Es como un...
¿Ah, sí?
Sí, al final fue como tres programadores, un designer, por eso ese equipo fue muy pequeñito.
Pero al final sí, cuando vendimos, claro que cada persona recibía parte de su dinero.
¿Y fue un buen éxito?
Sí, claro que es todo relativo, pero para mí en este momento sí, sí.
¿Te cambió la vida?
He comprado coche, por eso.
¿Vale?
En 21 años y eso fue como un...
Claro, no es tan éxito grande, pero al final no cobramos.
No fue un negocio, es solo un proyecto con algunos usuarios, con miles de usuarios, pero
vale, no es algo...
¿A quién lo vendéis?
¿Ah?
¿A quién lo vendisteis?
Una...
Una...
¿Cómo?
No sé cómo es...
Venture Builder al final del momento.
Y después me gustó mucho esta...
Sí, experiencia con startups, pero continuaba a trabajar como un desarrollador en remoto, haciendo freelance.
En algún momento he intentado trabajar por una agencia, en dos meses entendí que es imposible porque
al final es como fue...
Ellos venden mi tiempo, por eso tengo un proyecto para dos meses, resolviendo en dos días y después
ellos me están diciendo que vale, tú tienes que sentar y pensar que...
Tienes que hacer ver que haces cosas.
Exacto, pero no hacer nada.
Y para mí es algo, no, no, no, es imposible.
Y al final he encontrado otra startup que me gusta mucho que se llama Barisium App, que
la idea fue que en un clic tú puedes conectar su LinkedIn, Facebook o algo y vamos a generar
un resumé, un CV, infográfico, no es un texte, pero es como sí, infográfico y tiene muy buena pinta.
Tecnólogicamente también fue muy, muy, muy complicado y me gustó mucho.
Empezó como Team Lead allí y trabajaba allí por tres años y en algún momento fui a Barcelona
para hablar en una conferencia y he encontrado Redbox.
¿Qué conferencia?
Ah, eso fue sobre Ember.js, es como sí, un framework de JavaScript en este momento.
Vale.
¿Y hablaste ahí?
Y hablaste con Jordi.
¿Y conociste a...?
Sí, he hablado con Jordi.
¿A Jordi?
Sí, y después a Pau.
Entonces te hicieron el lío y te viniste a Barcelona a vivir.
Sí, exactamente.
Y al final sí, como siempre estoy discutiendo que mudamos por trabajo, pero al final quedamos
por ciudad porque me gustó mucho Barcelona.
Ah, se no era por Jordi Pau.
Perdona Jordi Pau.
No, pero al final sí, cuando Jordi Pau se fue, también sí, se ha cambiado puesto, pero
sí pensamos que con mi mujer siempre podemos volver a Rusia, pero no queremos, no voy a
hablar sobre política, pero también sí, porque nos gusta mucho Barcelona, España y...
No, no es mal, no es mal.
Entonces, en un momento dado, sales de Redwood y entras en Camalún, pasas un tiempo en
Camalún como CTO y en un momento dado decides emprender.
Sí.
Que es este mixed feeling, ¿no?
Cuando alguien te dice, bueno, voy a montar mi negocio, ¿no?
Y dices, hostia, qué putada, por un lado, ¿no?
Porque, pues pieza clave, ¿no?
De Camalún.
En aquel momento Juan casi tuvo una depresión.
Y, pero al mismo tiempo dices, bueno, pero qué ilusión, ¿no?
Es que, al menos, pues aquí estamos todo el día hablando de emprender, ¿no?
De arrancar cosas y tal, y vas a montar lo tuyo, ¿no?
Y además, con financiación, muy temprano, ¿no?
Sí, sí.
Al final fue totalmente muy natural, natural, pero también he tenido una idea en este momento
de COVID, cuando estamos todos muy en remoto y todos trabajando desde casa, que yo he encontrado
que, vale, mi día empieza a las ocho o nueve, finaliza a las ocho o nueve y doce horas
solo mirando a mi laptop, igualmente, así, muy cansado, sin energía, sin nada.
Y estoy pensando, pero mi calendario también está sabiendo mi día a día.
Todas las reuniones que tengo, todos los, como, time blocks que tengo también.
¿Por qué no está haciendo como un coach?
Vale, tú tienes mucho en su plato, tú tienes que quitar algunas cosas, replanificar, o ir a gimnasio, o, vale.
Pero sí, cambiar mis hábitos es que yo...
De salud.
De salud, sí, de día.
Porque he intentado hacer como prototipos, como puede ser, como podemos ver esto.
Por cierto, que eso tú lo utilizas hoy.
Sí.
¿No?
¿Eso es tu app, la que tú utilizas?
Sí.
Ah, vale, porque yo lo he visto en tu pantalla, que de golpe te dice, tienes que levantarte, no sé qué.
No, para ahora, para de trabajar.
No, no, es otro, es otro, es otro, es otro, es otro, es otro, es otro, es otro prototipo.
Pero, vale, sí, y al final, como he intentado, sí, he empezado a hacer estos prototipos y he publicado cosas en Twitter.
Que a mí, mira, tengo esta idea, tengo esta idea, mira cómo puedo ser.
Y he recibido una llamada, ¿vale?
Estamos en una Venture Fund, que también estamos pensando lo mismo, como calendario, como Smart, o AI calendario, no sé cómo podemos.
llamar este que tenemos que hablar y al final hablamos es que al final con idea
levantando dinero y oportunidad que crear un producto desde cero dinero es
casi un millón de euros un poco menos pero sí de entrada que recibe una
llamada y te voy a dar un millón de euros para que montes esta app que has
puesto en twitter pero también no es también solo de tweets y yo voy a
recibir pero sí a crear en público a veces tiene sentido porque todas las mis
conexiones fue por twitter jordi es twitter al final este experiencia de
emprendedor también twitter por eso sí hacer cosas en manera pública tiene
sentido pero al final fue business plan fue como un montón de charlas no es solo
un tweet que levantó tanto dinero pero si dos dos años intentando buscar creando
equipo creando producto pensando a nivel de go to market si también poniendo estos
gorras de yo no soy solo un programador o sitio también si yo tengo que pensar a
todos los niveles de negocio y si negocio tiene sentido es cambia tu perspectiva
mucho y también cuando tú tienes si es claro que he tenido dinero pero no es solo
dinero para años y años al final es pero contrataste mucha gente no mucho pero como
un máximo tenemos como 11 personas pero y al final si tú ves tu tu runway es
también no es indefinido y tú tienes que tener algunas cosas en un proceso
pensamos que vamos a hacer videos y clásico que vamos a tener un producto que
vamos a vender a customers que ellos van a pagar con la suscripción y encontramos al
final que es muy complicado primero es el mercado de performance como productivity es
algo muy raro que no voy a nunca a decir que tienes que ir ahí porque así es como
reducción 100% y también y si vía y es como muy muy bajo para gente es normal que
comprar algo para dos o tres o cinco euros por año y cambiar aplicaciones cada
mes es espacio normal pero ese chorn es muy alto y es muy bajo pero también crack es
imposible alto en este caso por eso pensamos pensamos pensamos revisamos que es muy complicado
y encontramos otra manera que en teoría podemos entrar a B2B porque a todo el mundo está
especialmente hace dos años pensamos que vale tenemos un montón de equipos en remoto
burnout es fue una palabra de moda de moda exacto y hay un montón de coaches que está
haciendo este coaching para cada equipo para cada equipo que vale cómo podemos trabajar cómo
podemos evitar burnout si podemos encontrar manera mejor a su día a día cómo planificar tu
schedule y por eso pensamos que esta app que está sacando un montón de datos de tu de tu móvil de
cómo tú duermes cómo tú estás moviendo cómo que es tu calendario está conectando todo y puedo
mostrar y junto con un coach que puede también explicar a ti por qué es importante revisar todos estos
datos puede ser una pareja ideal y al final sí también ahora estoy revisando que hay algunos negocios
que está creciendo mucho en este espacio pero también mi inversor en el momento está diciendo
que vale tiene sentido ahí vemos que eso es una idea pero estamos 100% pero si quieres continuar vamos a
buscar buscar a alguien nuevo que puede inversor que también puede ayudarte con experiencia B2B porque
es totalmente otro mundo es pero después de dos años también mi co-founder en este momento tenía su
primer hijo y fue como un momento muy complicado para no podemos levantar otra ronda también no
estamos 100% seguro si queremos continuar con esta paz y paramos un proyecto y yo he recibido una llamada a ti
muy bien muy bien menos mal por la parte de factorial si es una putada cuando cuando ves que no sale un proyecto pero bueno fue fue relativamente breve no o sea visteis relativamente rápido que no no ibais a dedicaros a hacer esto
pero si al final esto todo que es conectado a calendario es muy complicado porque gente está personalmente trabajando con tiempo totalmente diferente depende de su nivel depende de su seniority depende de un montón de cosas por eso encontrar un patrón que está repitiendo para cada persona en su app es muy complicado y si tú no puedes encontrar ese patrón es muy complicado monetizar este por eso a nivel de negocio es también un challenge en general
¿Tú te ves CEO en el futuro o CTO? ¿Te ves echándome de factorial lo cual estaría bien?
Al final es lo mismo como en este Empower Team yo estoy pensando y creando a nivel de overlap si todo el mundo tiene que hacer un overlap y si vamos solo vale sitio llevando ingeniería si están llevando solo negocio va mal por eso para mí no es tan importante que es mi
título al final si producto al final si producto funciona si negocio también funciona y si yo veo que algo está roto yo voy a hablar también vale yo no veo este negocio yo no veo esta dirección
por eso si yo tengo esta libertad y nadie me está diciendo que vale tú solo ingeniería trabaja en ingeniería yo estoy estoy cómodo
muy interesante muchas gracias por contarnos tu historia y un poco como estamos construyendo producto en factorial y bueno seguiremos contando y cada equis tiempo vamos contando lo que aprendemos y lo que vamos probando que es un proceso de experimentación constante que llevamos siete años y la verdad es que hemos aprendido un montón
y mucha gente dice oye pues no es lo mismo ahora que la empresa es grande y ya no es lo mismo como los viejos tiempos para mí es al revés o sea este reto que tenemos ahora no de conseguir
esas personas con tanto talento no tengan el espacio para crear para construir para hacer historia es súper interesante 100% sí y más cuando tanta gente del mercado le interesa lo que hacemos no y están dispuestos a utilizarlo
y a pagar por ello sí sí sí y para mí y me parece tenemos esta libertad que yo estoy comentando que nadie va a decir que tú solo en un ingeniero por eso toca código y nada más no tenemos una
libertad que si tú quieres crear un producto que tú estás orgulloso sí me parece factorelo es un lugar ideal para esto perfecto
call to action final vendemos un poco muy bien pues nada hasta la semana que viene
somos un ecosistema de startups tech de barcelona creadores de camalún equipo y factorial entre otras
ofrecemos más de 5.000 metros cuadrados de coworking a startups y organizamos eventos diarios para discutir negocio y tecnología hasta la saciedad
desde itnick fund invertimos en equipos con capacidad de construir grandes productos y negocios te esperamos