Los Retos de Producto de Factorial con Ilya Zayats #311

Yo soy Bernat Farrero y esta semana estoy con Ilya Zayats.

Hola.

¿Qué tal, Ilya?

Buenas tardes.

Ilya, con este apellido no es de Reus . Es ruso, ¿no? Eh, viniste a España hace...

Nueve años.

Nueve años ya. Y, y fue precisamente, eh, para trabajar en TeamBox, que era la empresa donde-

Ahora Redbus en este momento.

Y ahora Redbus, ¿no?

Sí.

Vale. Que era una empresa de Jordi Romero y Pau Ramón antes de venir aquí a Factorial, eh, trabajaron, ¿no?

Sí.

Eh, posteriormente a esto-- luego entraremos en tu historia, ¿eh?, pero posteriormente a esto, eh, viniste a Itnig, trabajaste en uno de los proyectos de Itnig como CTO-

Mhm.

Camaloon, ¿no? Luego emprendiste, montaste tu empresa, ehm, levantaste bastante dinero de entrada muy ta-- muy, muy temprano, construiste un producto muy difícil, consumer, luego nos explicarás. Eh, y finalmente te recuperamos aquí en Itnig, en Factorial.

Todo correcto.

Y has llegado un año, eh, especialmente complicado. Ha sido un año para Factorial bastante dificil de cambios, eh, donde tú entraste en febrero, ¿no?

Mhm.

Eh, entraste como líder tecnológico o director de inje-ingeniería del dominio de finance, que era un dominio nuevo, eh, que habíamos creado en Factorial. Y poco a poco, eh, bueno empezaría a haber cambios y hasta el punto que habría una reestructuración, un cambio, una reorganización digamos de-- en el equipo de producto, una forma de trabajar y saldría el CTO, mi socio Pau Ramón.

Eh, después de siete años decidió que quería hacer otra cosa, estaba cansado, eeeh, que le superaba la escala, que no le apetecía, eh, y decidió hacer otras cosas, con lo cual tú te convertiste en, en su sustituto, ¿no?

Ehm, y hoy eres el, hoy eres el líder de tecnología de, de Factorial, ¿no? Entonces yo quería preguntarte, Ilya: —¿cómo, cómo se vive esta situación donde de golpe un cofounder 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-

Mhm.

...y de golpe tú eres el next guy?

Ah, me estoy riendo porque sí, con Pau es un patrón. Porque sí claro sé que tú quieres tocar mi historia un poco adelante Pero en RedBus pasó exactamente lo mismo Ah 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 Ilya Ahora tú Eres un CTO De RedBus

De RedBus

Sí por eso Aquí Vale En factorial Paso Lo mismo Tengo una experiencia No pero es verdad Si 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 De Esta manera perfecta Para crecer Al final si Tú Quieres 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 Y-

Pero es Un challenge Del que Para mucha Gente Huiría Un Poco ¿No? Porque Es muy Difícícil De Golpe En un entorno Así De Cambio Ehm Asumir esta Responsabilidad Con Gente Que Está Con las Urpas Unpoco 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 Pero pau En factor Hoy es Una especie De Semidiós ¿No?

No Pero depende De Cómo tú Ves Esto Si es Si tú Crees en Un equipo Si tú crees En una Idea Sí Claro Que hay Algunas Cosas Y algunas 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 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 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 Tú O sea cuáles Son las vara Rápidamente Dices Sí No Voy a hacerlo

En Mi Historia Normalmente Si Este Tiempo Para pensar Es algo Falso Al Final Porque normalmente Yo tengo Respuesta En cinco Segundos Pero también Después Quiero racionalizar A mí Porque es Una buena respuesta Pero mentalmente 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 Em Y el equipo De Producto De Factorial Aquí somos Muy transparentes Explicamos siempre Siempre Todo Y creo Que es bueno Então entonces ¿Cómo te Encuentras El equipo Y Cuáles son Tus primeras Lo que haces En el Primer mes Dos meses

Aquí Challenges Principal Claro Como tú Estás diciendo Que Pau Es una Persona Muy fuerte Que yo tengo Un montón De Confianza Y respeto Y es También Es claro Que todo El mundo Va a comparar 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 que También Aprender Mucho Porque claro Que Para Mí es 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 entra está pensando que no es escalable.

Pero para mí idea fue que vale, yo voy a coger todos los managers que tengo, todos los directorios que tengo y voy a aprender qué es un producto, qué es un dominio, qu-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 vale, cosas más culturales, porque me parece aquí podemos empe-empezar un poco sobre qué cambios hemos hecho ah, y, y por qué lo hemos hecho.

Si yo voy a hacer como un repaso, ¿Qué, qué he visto personalmente? Es quien en mamen-- en cada compañía pasa en esta historia, que t-- y si tú vas a escuchar un montón de pódcast siempre pase esto: Ah, estamos en fase hypergrowth. Por eso, ah, buscamos un montón de gente encontramos un montón de gente y después no sabemos cómo podemos manejar-

Profesionalizar.

Exacto, cien por ciento. Y es algo muyyy, que, que pasa mucho. Y en este caso me parece Factorial no fue diferente, porque a-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 cien personas un año, aaah, es normal que al final se-

Se rompan cosas.

Rompan cosas y es muy complicado alinear este tan, tan tamando, ese tama-tamaño de personas. Ah, por eso en este caso al final pasó, pasó lo mismo, que para mí algo que fue muy significativo es que cuando ha entrado esta dominion de finance es-- yo entendí que vale, es-- yo entiendo, entiendo esta idea que al final podemos centralizar cosas y descentralizar cosas.

En momento cuando yo he entrado todo está muy cen-- descentralizado. La idea fue que vale, vamos a crear una compañía dentro de una compañía. Aaah, tenemos un CEO, tenemos un CTO de, de dominio y tiene su idea, tiene su visión de todo. Pero al final, mmm, teníamos seis o cinco estas compañías sin hablar de todo, sin hablar de nada.

Y al final cada, cada esta compañía va a su, su dirección. Quien te-

Antes expliquemos igual lo que es un dominio.

Sí.

Eh, por e-- en nuestro caso, el producto está dividido en, en cuatro dominios, ¿no? Eh, cuatro dominios, cuatro partes, eh, muy diferenciadas. Igual demasiado en aquel momento. Muy di-- muy diferenciadas de, del producto. Una es la parte de, 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 desarrollo de talento, que es donde hay la evaluación del desempeño, pues el engagement y el recruitment principalmente. Eh, la otra es Finance, que es todo lo que es a día de hoy gestión de gastos, notas de gastos. Em, y la cuarta es una parte más meta, que es lo que es mucha gente le llama plataforma, que es básicamente el producto per se de factorial.

Es donde s-- donde los dominios construyen, donde las abstracciones comunes, donde hay todos los espacios, eh, que, que unen las... El pegamento que une todas las, todas las distintas funcionalidades de Factorial, ¿no? También pues la A-- la API, ¿no? Y, y bueno, las partes estructurales, la parte de reports, ¿no?

Todo esto es core, ¿no? Entonces estos cuatro dominios les llamamos dominios. Era como estaban dividida, eh, el equipo de producto y cuando, 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, un GM.

Un GM, un general manager por dominio, a quién reportan tanto los ingenieros como los diseñadores como los product managers.

Sí Exactamente. Y al final la idea fue como es-- separamos todo. Es como ca-- 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. Eso es como Faktor al final.

En papel todo perfecto.

Perfecto. Cada uno tiene un objetivo también de ARR.

Sí, a nivel de dominio. Sí, en teoría a nivel de equipo sí, pero en realidad OKRs y todo es como si es un, un, una herramienta, pero sin nadie estaa usando este correctamente. Está usando como herramienta y pone como, una i-una idea es, es algo que solo decidimos una vez a, a quarter y después no sabemos.

Claro que con nuevo contexto y todo repensamos que vale, este OKR no tiene sentido, pero vale, tenemos este OKR. Y looo mismo con todos roadmaps y 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 sub-- un subgrupo dentro de un dominio. Hay unos seis por dominio, ¿no? Seis o siete por dominio, eh, y cada uno tiene una misión.

Sí, una misión. Y también es como un, es un trío de director de PM, es product manager, un diseñador y engineering manager. Y con engineer manager, inge-- cada engineer manager lleva cinco, seis, siete ingenieros. Por eso es como equipo multifuncional que tienen todos el del mundo. Pero al final es si tienes esta separación tan muy definida y esto todo es muy tan distribuido.

Ah, y al final este Conway Law clásico es que tú vas a tener tu producto como tu estructura de, de compañía. Y paso lo mismo, porque al final tenemos algunos productos que desde 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 desde un punto de vista usuario todo es un caos Porque yo entro en un lugar ah es para mí un producto de time por ejemplo uno sé qué bueno de finance Y al final hay otra pestaña y tercera pestaña también lo que no comparte datos y yo no entiendo por quéPorque para mí es un Factorial Todo es factorial

Que prefieren los equipos hacer su propio subproducto supempresa incluso pestaña dentro del producto con toda su funcionalidad que colaborar con otros equipos que que no tienen una línea directa de reporting ¿no? 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í sí Es normal Y desde luego colaborar con otros seres humanos probablemente no sea no sea lo más fácil

Sí porque al final todo es como un proceso Tienes su roadmap otro equipo tiene su roadmap y emm por eso es como mu-- Alinear roadmaps es muy complicado También pasa cada día Si quieres romper algo es también tienes que levantar su mano Es también otro challenge Y al final sí status quo tú vas por su 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 a día mira estamos creciendo Estamos- Esto es otra cosa que pasa cuando crecen los equipos y no le pasa solo a Factorial Le pasa a muchas empresas que es que de golpe la división de responsabilidades empieza a parecer

la complacenciaEs decir la gente dice: "Bueno alguien se encargará" Mjm NoEl producto no va bien Yo ya se lo he dicho a alguien Ya se lo he dicho al de al lado Eh no me gusta cómo se ha hecho la última navegaciónNo me gusta el último design systemNo me gusta la tabla La abstracción de la tabla que hemos hecho Pero como me queda lejos pues eh no lo puedo cambiar Y otro tema que es también es un cambio chi tu chip un poco porque está todo el mundo ahora está pensando que vale estamos tan grandes Como estamos un enterprise No puede no no hay otra manera diferente Es solo que es- O sea asimilarlo como un como un hecho incambiable ¿no?- ExactoSomosYa

somos EnterpriseCon lo cual esto ya es lo normal Sí sí sí Somos tan grandesPor eso cambiar algo es un es un reto grandísimo Por eso no vamos a atacar estoPorque yo como una persona no puedo porque son¿Cómo Cómo se cambia eso TanTan horrorosoqueEstamos describiendo ¿no?Como Qué haces para cambiar eso?NoAl final no es tan horroroso porqueOye EsoEso es terribleHorroroso síTú vesEn estaManerapero nadie En ennnoHay comoiniciativa mala enEstoNadie EstáPensando queValeVamosa hacerestoSíSíPero essalgo quetenemos queCambiaralfinales increíblecómo osea sinmala fésí exactose puedeah ir aa nosedéaldisastresítodo elmundo cadapartecon buenafe y todoycadapersonaestá haciendosu

trabajosu trabajodefinitoclaroclaro tienuna ideamuy fuertede cuálesutrabajodónde empieyay dóndeAcabano peroesochallengeprincipal aquíes comosiempreen todosloscompañíasespecialmentegrandesmás grandescomoess comunicacióny alineamentocómo podemosalineartodos estospersonas sitenemósde doscientospersonascómo podemoasegurarque ellostrabajanen lamismadirecciónes primeroesonunchallenguegrandísimool finalquéQuéhemos hechohamy paramíes untrabajo clavedemiddle managementdedirectores eneste casoporque escómoellos estánennuestrocaso esmanagersdemanagersEstánresponsables dealineartodos losdominiosy vervaledonde

tenemosestospoduntode conexiónym si timetieneconexiónconcora Cora Tienealgúnapendenciacon people Nosé esteesu trabajo principalyno pasó antes yal finalahorame pareceque estamósmasen mejorlogarcomparadohace seismeses ensentidoperoel primerpuntoparaparestructurarloYo claroEstoymuymetidotono Perola gentequenosescuchaigual nono entoncesel primerpunto esconstruirunacapademanagementnode directoresem quê sepisa unpoco nookequetrabajaenen mismoprojectosen conjuntoen construirunsologproductonooexactoperotambiénen estetecason temosqueromperestascosascomofalsosal

finalqueactual estangrande que nopodemosmertodotoro mapdefactorielen cabezade unapersonaporque estofuécómoun truismaantesmantra mantraMantraQuese repetía noe s quede demasiadograndeDemasiadocomplejoExactoe yesno esverdadporquesiclaroqueestamos grandePerono tangrandeque esimposiblepara unrevisarquequéva apasar entodor factoriahlpor esosprimeroqueprimerrequerimientoquetodos losdirectorestienen quesaber roadmapdetodo FactorialPorquesoloen estetecaso podemobuscarestospoduntasy overlapsdetodos Los dominiosSi esteno pasanon Claroquenuncapodemassegurarque anivel dehaysío anivelde

equipoaellospelopen teneresta estasestas conexionesporeso esprimerosegundaes tambiénharevezarnuestrasritualesynuestra cadenciasPorque alfinalsiestamotangrandestenemosque buscarunasoportunidaddescommunicaratoto lototal totalacompañía yatota totagente poeso ahoratenemoseh cómoyen cadacuartertenemosunaseriade eventosquè estamosasegurandoquereal finalestamosenl mismavamosalmisma direcciónPrimerosescadarommapen primera decuatroCadarommapquetenemosestápublicadoenslaquetodoelmundo

puedesverdenivelde equipeA niveldominioQuesmuy importanteporqueziproducteal finalnosoloparaproductoes paraventases paracustomsuccessparatudomundoEllostienencuetenerytienequetenerestaposibilidad deinfluirqué vapasaraeste quarteryhnormalmentetodomundoestadiciendoquecadadíaestoespasaEstaestapasandonormalmentepero nose verdadaveseceses complicadosavecestenedimosdíaal díaporeso esthotenuneruna oportunidadcuander Publicamos todos los roadmaps y todo el mundo puede ver, y ver si vale.

Ahora este equipo está pensando atacar es-este pain-- ah, ese challenge. Ah, es mejor y da oportunidad a todo el mundo enten-entender y cambiar algo en este momento.

Mhm.

Otro tema que es importante es también porque estoy saltando un poco al final de q-- para mí yo qui-quiero volver, yo estoy un... Yo creo mucho en deadlines. Para mí es algo muy, muy importante ahí, y esta también es una oportunidad pa' alinearnos con otros equipos.

Por eso ahora tenemos la como timeline o timeslot normalmente son a nivel de queue. Si todos los equipos están entregando algo al final del quarter y es como un deadline nor-normal que está pasando. Revisamos todas las e-entregas a nivel de quarter por eso es algo no es tan popular a veces en la-- en el mundo d-de ingeniería, porque todo el mundo está pensando que tenemos que deployar cuando estamos seguro que tiene calidad muy alta pero n-yo no, yo no compro esto .

Porque normalmente tenemos tres variables que podemos incluir recursos: scope y time. Si fijamos dos de estos por recursos, porque normalmente tienen tamaño de equipo más o menos está definido a deadline pues va-vale, tenemos que entregar algo seis semanas sobre un quarter solo una cosa que podemos influir es un scope y es algo que es llave al final porque si queremos un equipo-

Clave Que es clave. Sí.

Sí, sí, porque si queremos equipo que sabe qué está haciendo, que está alineado ellos tienen que aprender cien por cien que es un challenge de usuario Al final ¿por qué creamos este feature? O ¿Por qué hacemos este refactoring? O ¿por qué hacemos algo? Ah, hay alguna razón dentro de esto, mmm, y sin aprender esto en detalle tú no puedes encontrar el scope porque si tú no sabes porqué esto siempre.

Cómo tu puedes decir si yo tengo que hacer parte de este feature o en glo-- mmm, algo más global o puedo quitar estas co--, o puedo quitar esta esquina, Es cortar algo si tú no sabes a dónde vas.

Mhm.

Ah, por eso si para mi es algo clave otra vez es que si gente tienes su control cien por cien si equipos tienen ci-- control cien por cien de Scope. Ellos autónomamente empiezan a emprender a por qué estamos haciendo esto Y para mi equipo no es solo ingeniería o diseño o solo PMs al final es conjunto de todos.Porque a veces en el mundo pasa, ah, qu-que proceso normal de desarrollo de producto es con lo que yo normalmente estoy llamando McDonald's ,es que PM está encontrando un pin y está preparando un documento,

un artefacto Está describiendo. Vale solución ideal es esta vamos a añadir estos botones Vamos a dirigir esas pantallas ya está Después pasa esto al diseñador El diseñador coge solo este artefacto Sin conocimiento de usuarios Sin conocimiento nada Está pintando high fidelity screens y después pasando esta idea a ingeniería Ingeniería están desarrollando algo y deployando Al final En cada paso de estaaa, de esta cadena introducimos más y más ruido Y idea inicial que puede ser También No es tan buena de PM Al final conver-- se convierte en algo totalmente roto Totalmente diferente que usuario no quiere Por eso para mí uno Una manera Como construir producto sana es hacer overlap

De todas estas partes Que ya me tienes Esta Tiene muy claro el paint de usuario Y puede explicar Solo paint no La solución Y después pasar esto A equipo de Diseño y equipo de ingeniería Y ellos en un Timebox de seis Semanas de un Quarter Tienen que llegar a una solución Pero tener en Claro primero Input es Un problema Un problema de Usuario y no una Solución Y Normalmente Este funciona Mucho Mejor comparado Con McDonalds

Y ese concepto Del Overlap Es interesante Porque Eeel 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 O sea Eh Al Final el Construir un Proyecto es una es un Trade off Es una dicotomía O una tricotomía Entre eh El alcance El tiempo Y Los Recursos Utilizados Para construír el Producto EntoncesComo Esto es Muy difícil Determinar a priori Porque Hay muchas varia-varia

VariablesEn muchísimas DimensionesQue Pueden Aparecer en la construcciónDe un ProductoLe das el ownershipAl EquipoPara queellos Dinámicamentedecidan en basea lainformación queVan recogiendo Trabajen Juntos PisándoseConstruyendo unasolución en Conjunto Aunque elDiseñadorse encargaMásdeldiseñoY elel Ingeniero más delaingenieríayElproduct managermásDelProblema Lostres olostres rolesporque en realelequipo Puede Sermás grandeSiHay máisingeneriosTrabajancomo unsol equipoPensandocomo unsol equipoDecidiendocomo unsolequipono Y alfinal acaban teniendoelproducto óptimo Sique Noahaspodidoterminara prioripero Quéconfíasenelequipoque eselproductoóptimocon eltiempo yercursosno Y poresoesimportante queeltiemposeaunade

losfactoresQuese determina ytúdicesbueno eneste trestparámeteros dealcane yRecursos emYo tefijo eltiempo ylosrecursosNo Esoestás diciendo quesonlaspersonas queformanpartedeequipo yetiempo entonces tedejoolscope Tedoylaresponsabilidaddelalcanceparaquetudecidas hastadóndepuedesllegarno Yclaro icuáleselincentivodelequ ipodellegarlejos Porquesdicesoye Puesvoyaser muyconservador voyhacerpoquitacosa

SíPero esNormal tambiéntambiénhayotraOtra Cosa queEs Ques Noesvariable yaparamío quieroHaceresto muyFijoesestasensacióndeCalidad Que también significa-- vale, esta ficho es parte de Factorial. ¿Y qué significa calidad de factorial aquí? Esto es, eh, como criterio interno, es algo que es muy complicado mostrar o poder-

Describir.

Es describir, es verdad. Si tú no tie-- tú tienes o no tiene, pero es algo que tú puedes aprender, eh, pero normalmente se transmite a nivel cultural que tú ves, ¿vale?

Tradición oral.

Como historias, sí.

Como la cultura misma.

Sí, sí, sí, sí, sí. Pero es verdad. Tú ves qu-qué está pasando en otros equipos, cómo estamos decidiendo que vale, es un buen producto, 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 este, este variable, no podemos d-decidir que va a decir que vale, pues solo seis-

Como es difícil de medir, pues no lo, pues no lo vamos a medir, ¿no?

Sí. O, otra tema es como excusa. Es solo seis semanas, tengo recursos limitadas, es problema muy com-complicado. Exacto.

Pero es porque es que realmente no tengo más tiempo, ¿no?

Sí, sí, sí, sí, sí. Pero también es importante que a-aprender que, vale, puede ser solo un botón, pero botón que funciona cien por cien de veces y estar resolviendo el pain de usuario. Vale, eso no es algo muy flashy, es un botón, pero exactamente. Usuario cree quiere este, este botón. Pero otro, otro tema que es a veces está pasando es estamos invirtiendo inver-- ah, em...

Invertiendo.

Invirtiendo, sí, gracias. Un montón de tiempo en algo muy complicado, pero no podemos traer en ese seis semanas o en un quarter y por eso estamos casi ahí, pero no sabemos si va a funcionar. Es algo muy, muy complicado. Usa-usuarios no lo entiende y al final es también, ah, motivación de equipo.

Está totalmente en su suelo. Porque sí, claro, claro, ellos que no pueden tra-traer algo a producción. Ah, pero al final esto pasa porque no tenemos este challenge dentro de un equipo. Si de-diseñador no pueden trabajar con ingeniería, ingeniería no pueden decir que vale, porque no es, no tiene sentido desde mi punto de vista, porque todo el mundo no tiene en su cabeza esta visión final de usuario.

Y cuando est-tú estás cambiando esto, magia, magia, empezará normalmente.

Mhm. Vo-volvemos al principio donde yo te he preguntado-

Mmm.

Em, ¿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 factoría, de cómo se construye producto cambia, ¿no? Entonces has hablado de bueno, hay una serie de rituales.

Sí, sí.

Básicamente, en general, en producto hay los rituales, hay una serie de artefactos-

Mmm.

Que la gente construye y mantiene. Eh, hay una serie de incentivos, ¿no?

Sí. Vale. Finalizamos con ri-

La cultura también, ¿no? Pero puede ser-

Ha-hay un montón de cosas, pero finalizamos con rituales porque sí, al final tenemos esta mita, ah, principio de Q, ah, esto kickoff, mmm, se llama, es que todo el mundo está publicando su, su roadmap.

Un Q, cuando dices un Q para gente que no, no está metida en la jerga, es un trimestre.

Ah, trimestre, gracias. Sí, sí, sí, sí, sí. Un trimestre, sí.

Es como funciona el equipo de producto piensa en trimestres.

Exacto. Sí, es como...

Cuatro al año.

Sí, sí. Ellos como un calendario, si ya está definido las partes y normalmente, así estamos entregado en ca-cada quarter. Claro que deployemos más cada día, pero al final que medimos y que revisamos es como un quarter.

O sea, o sea, el quarter es la unidad, eh, de, de valoración de los resultados hechos. No es cuando se lanza el producto, ¿no? Tú lo has dicho, él se lanza constantemente, se está creando-

Sí, sí, sí, sí.

Se está cambiando el producto.

Sí.

Pero al final del quarter es cuando se evalúa.

Sí, también paramos y pensamos a dónde vamos. Va-- la dirección correcta o no. Es también es importante tener algunos puntos en, en su día a día, que cuando vale todo esto día o esta semana estoy totalmente en manera revisar cosas.

Vale.

Am, y tenemos tres. Primero, si es como este kickoff que todo el mundo está pensando que vale-

Estos son los rituales.

Sí, rituales.

Los eventos que pasan en la organización de producto.

Exacto.

De sincronización. Eventos de sincronizacion.

Primero es vamos c-con este plan, es nuestro roadmap. Mitad de trimestre es a donde publicamos primeros resultados que cada equipo está diciendo que vale. Nuestro plan inicial era esto. Ahora estamos en esto, en este estado. Es mira, ah, puede ser una figma o puede ser un demo real o algunos nú-números nuevos.

Es vale, si gente va acá día a día aprendiendo contexto nuevo, ellos están reprocesando este contexto, está 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 han hecho.

Sí.

¿A quién le muestran?

Sí, a todo el mundo, en realidad, a toda la compañía. ¿Por qué es importante?Porque si todo el mundo está empezando, que vale. Claro que tenemos algunos, ah, podemos tener algunas dependencias con clientes, con, con ventas, pero también todo el mundo puede empe-- em, em, aprender cómo desarrollamos producto y cómo pensamos y por qué priorizamos algunas cosas sobre otras.

Ah, y, y también que es importante es, es 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 pensa-- que pensáis hace seis semanas. Por eso es normal que decir que vale chicos, totalmente repensamos nuestra roadmap, pero mira por qué.

Tenemos una, una documento, una lógica detrás. No es porque no podemos entregar, es porque ai--tenemos otra oferta más grande. Y es otro momento donde es normal decidir decirle a todo el mundo que nuestra roadmap como equipo está cambiando. Y al final de Quarter, que es más importante, tenemos product review, que es también importante não sólo para equipos, es también para directores, porque para mí es, voy a repetir, es, ah, 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 este, mmm, capa de middle management, directores, en este caso es un otra cosa clave que-

Clave de todo.

Sí, sí, sí, sí. Que tiene que tener. Así tenemos mucha gente allí, pero al final Mi idea es que cada persona piensa en la misma de-- la misma dirección y está alineado 100 %. Porque, eh, con este podemos tener que vale, cada dominio está pensando a nivel de negocio. Ellos tienen su roadmap de todo Factorial en su cabeza y por eso pueden encontrar cosas o conexiones.

Y también que tiene este con criterio de calidad también compartido, porque es qué es más importante que vale en un dominio tene-- ah, no puede ser que es más, 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 tener, tener factorial como una compañía, un producto, pero tenemos un montón de gente. Por eso es esto un challenge. Esto dejo también real. Ah, tenemos que operar cada día y en este caso directores son claves.

O sea, esta construcción de criterio compartido-

Mhm.

...que es un problema. En Factural tenemos ya doscientas veinte personas, doscientos entre diez y veinte, eh, en el equipo de producto. De los cuatrocientos sesenta son ingenieros, eh, veinticinco product managers, veinticinco diseñadores más o menos, ¿no? Antes he hablado que teníamos cuatro dominios, pero luego tenemos un quinto que se que, que, que no me lo olvido, que es la parte de infraestructura donde está el data, donde están las, ¿no?, los analytics.

Dónde está, eh, la parte de servidores, etcétera, ¿no? Em, entonces, em, espérame, he olvidado lo que iba a decir.

No, estoy-- También quiero finalizar con Product Review, que es para qué es tan importante para directores y para esta capa que al final, ah, cogemos todos los equipos y todo que han hace-- que han, han entregado en este quarter y con todos los directores revisamos que vale producto por producto si tiene esta calidad, ah, calidad de Factorial, si ha entregado al final porque es importante.

Deadline es algo impor-- que es deadline mmm, en realidad si no ha entregado es un, un fallo grande. Tenemos que revisar por qué está pasando, qué está-- qué con este equipo no es correcto y, y también discutir cómo priorizamos cosas o 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 guiarse.

Claro, eso es lo que voy a decir. O sea, lo-- la parte más importante es crear esta conciencia compartida-

Sí, sí.

Entre los directores, ¿no? Que todos los directores puedan ser reemplazables, que puedan dar feedback a los equipos, que entiendan la visi-- la misma visión de calidad.

Sí.

¿No? La misma visión de Factorial en su conjunto, ¿no? Y para eso sirven también los product reviews, ¿no?

Sí, sí, sí, sí.

No solo para los propios equipos reciban el feedback de su equipo-

Exacto.

Sino para que los directores se impregnen y consensúen, se hagan el esfuerzo de discutir y de alinear los puntos.

Exacto. Idealmente, equipos tienen que recibir feedback cada día-

Claro.

De, de, de sus directores. Pero también tenemos que tener un momento en un quarter donde podamos parar y también alinear a to-a todos y revisar que vale, estamos en ello, ah, o no, y dar que este es feedback un poco más oficial. Pero la idea es que e-si equipo llega a Product review con sorpresa, que es algo mal, ah, ma-- que es algo malo, es mal, mal trabajo del director, que el director no está diciendo-- dando feedback correctamente día a día.

Ah, y es también una señal que no estás-

¿Qué implicaciones tiene este product review?

Sí, también me parece aquí tenemos que tocar cosas 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 este es un buen producto, un mal producto-

Sí.

Es de las cosas más difíciles que hay.

100 %

¿No? Osea..

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, vamos a encontrar hackers.

Si al final un producto es una implementación de una, de una visión fuerte, de una opinión fuerte-

Sí, sí, sí.

Subjetiva, eh, ¿no? 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, puedes poner en un papel. Es en teoría con IA puede ser en algún momento, pero ahora sí es, que es importante tener todo, todas esas personas en la misma sala discutiendo partes de producto para revisar si es, es un producto bueno o no.

Que al final en software B2B esto se traslada en, en, en conseguir el éxito del usuario y del cliente, ¿eh? Porque al final el B2B lo que te permite es ser bastante más objetivo y racional, ¿no? Normalmente los clientes para los que trabajamos tienen un objetivo. Nosotros podemos o bien ahorrarles tiempo o bien enablearles a hacer cosas que no podían hacer antes sin nuestro producto, ¿no?

Y todo esto con una experiencia placentera.

Exacto. Que es muy complicado al final. Si t-tú pones solo núm-los números vas a tener Excel que al final está resolviendo un montón de pains. Pero no-

Es que Excel es la hostia.

Sí, exactamente. Pero nadie quiere usar Excel. Pero nadie quiere usar Excel.

Pero todo el mundo lo usa.

Sí, exacto. Pero porque no hay otra. Sí, ah, pero al final sí, también queremos que-- tener nuestra visión y queremos transmitir esta visión y queremos tener una equ-- 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 y...

pero están-- este equipo tiene que transmitir visión de factoría 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. Y es-

Qué difícil es esta centralización y descentralización, ¿no?

Sí, es un challenge.

Es el challenge de todo, ¿eh?

Y es ch-- también es challenge que, hm, es muy lento al final ver los resultados, porque si tú puedes-- normalmente, como 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á, ah, entendiendo este mensaje estaréis viendo. Pero no es verdad.

Tienes que-

Yo, yo de hecho, Ilya, yo hablo contigo y te digo: "Oye, arregla el producto". Ya.

Exacto.

Ya, ¿no? Pero claro, cuesta, ¿no? Lleva tiempo, ¿no?

Sí, lleva tiempo. Sí, lleva tiempo, es verdad. Pero es-- este cambio cultural es, am, es Normalmente sí es-- primero tienes que cambiar cosas muy, en manera muy rápida. Porque si tú llevas un coche hay G-GPS y si tú pones el GPS en dirección errónea, tú vas a... Y si tú estás de cuenta, te vas a parar y poner correcta.

No vas a mmm cinco kilómetros más y después eh, poner la correcta. Pero en este caso, en caso de nuestro tamaño, es no somos un coche, somos como un liner en océano o como tourist line.

¿Un autobús?

No, turist liner Como una , oh, ¿cómo es?

Un, un crucero.

Un crucero grande. Sí, ah, grandísimo. Si tú vas a cambiar dirección también con inercia tu vaaas, como lleva tiempo en este caso.

No sé. Tú has visto el podcast de Lex Fridman con Jeff Bezos, ¿no?, Que bueno..

Tengo en mi cola.

Nada nuevo seguramente para ti. Pero es curioso porque él habla de que sea una empresa como Amazon de uno coma cinco millones de personas trabajadores se mueven con muchísima agilidad y con unos, con una serie de principios muy básicos, ¿no?

Pero me interesante qué significa "se mueve" en este caso Ejecutar algo en los mismos principios es una cosa pero cambiar al es otro tema y cambiar en el chip. Para mí cosas culturales se cuesta mucho porque tú es ma-- tu manera de pensar es algo que tú tienes que reforzar cada día con ejemplos.

Y cuando tú tien-tú tienes dos más de 200 personas uf, es tiempo.

Sí, es que hay algunos factores culturales que nosotros nos damos cuenta. Los founders de Factorial que por el camino vamos perdiendo. Porque para nosotros son muy intuitivos el hecho de ese sentido de urgencia al moverse rápido, el enfocarse al detalle, crear ser hands on estar creando siempre De golpe Cuando empiezas a crecer empieza 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 y hablar y pierde esta noción de detalle Esta noción de producto de builder emm que cualquier emprendedor técnico normalmente tiene al principio

de construir producto Entonces claro Es lo que nos pasa cuando nosotros nos empezamos a sentir a no sentir orgullosos de lo que estamos haciendo No es que el producto de factorial esté roto O sea, no es que no funcione El proyecto factor del proyecto factorial sigue siendo la herramienta elegida para pa-para un cliente cuando le dan dos opciones Tres opciones o prueba varias opciones en el mercado Pero sí que comparado con nuestra expectativa Esa expectativa de un diseño placentero de una experiencia que pasa sola, que funciona sola, que es casi mágica Que al principio es cómo empezó Empieza factorial En 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 Ah, no hay mala fe como estamos discutiendo Sí Al final sí sí sí No estoy pensando que al final todo el mundo está pensando vale Pero yo estoy ejecutando mi trabajo Estoy haciendo 100% correcto pero al final no es un producto que estemos orgullosoPorque a veces sí tenemos que parar y pensar que valeEs algo raro porque estamos ahora Estamos priorizando este feature sobre calidad bugs u otro temaY siempre tenemos que repriorizar cosasporque es otro challenge que....

Pero la calidad nunca senunca se negocia.

No 100 %. Pero sí ClaroSi todo el mundo está diciendoque tenemos que traer más featuresmás features Más featuresTodo el mundo va a pensarque Vale Calidad noesalgo que es importante para nosotros

Claro pero esque másfeaturescon lamisma calidady el problemaEl problemasiempre esaesta definicióndecalidadeOseaesto queestabasdiciendoalprincipio decómo Cómo generaresta visiónunificadaEsta culturafuerte deque escalidadYo hagouna charlaen junioo julioEn juliohago unacharlaan Factoryy hagouna presentaciónde pongoFix the productYa he acabado mitrabajoMi trabajode modeloes másc FácilLiderazgoEntonces degolpetodo elmundoempiezahablarde fixtheproductycadauno significacada unulaatribuyealgo diferenteSíQuefix the productQué esfix the ProductEntoncesparteHay montón decoasasHay montóndecosasPorquepara algunoses bugsy

SLAPara otrasescomoestasensaciónestamosorgullososDe experienciade diseeño y dede arteSíhay muchas cosassí Claroentoncesclaro hay que unificar nohay que consensuarYo creoque estosmesesesto quetúddescribescomoeste procesode reviewdealignmententre directoresEs un pocola discusiónla conversaciónlarga convictiona largoplazoPorqueoye estetienesquetener pacienciadondeexiste todas estas discusionesSe empiezan aproducir esasdiscusionesy seempiezatangibilizarmediante laproductreviewQueno esunalgoritmoy es unaputadaporquelosingenierosbuscana algoritmosparamedireléxitoProduct

ReviewDonde loseirectoreessecomprometenadarfeedbackprofundodenso deporquésíyporquéno Exactopero tambiénotra puntointresanta aniveldeingenieríaPorejemplo enestecaso siestamoshablandosobredirectoresdirectoresdirectorasperono essólodirectoresque tambiénssepuedetransmitirestasensaciónde cálidadParamíes tambéunna unnivel deseniorityengenieríaEs exactamenteeeostoesque alguienpuedededecir quevale nopodemosemployarEste ono esunamanneracómodesarrollamosproductoTenemos otra ypuedelevantarsumano ytambiéndeceque valeno podemoscntinuarcon

estoY yokeoa ahoradespuésde estescambiosy estecambiodelchipquecredaestá bienEsalgoo quenopodemosquitarke cadadíaespecialmentedeveloperscomoo ingenieríasaniveldestaff oséniorEstáliderandocómo estoydiciendoin campoEstá liderandoel Quéen campocomen endía adíaEndía a díasin endía atierrain terenotodoelmundo escómovale Nosiquereromostaan

Mostrando en su, ah, ejemplo cómo desarrollar producto de manera, manera que estamos orgullosos. Y para mí es otra pata que es un-- muy importante a ingenierías y es tener estos, eh, tener estas líderes a nivel de ingeniería. No es como managers, pero a nivel de ICs, individual contributors-

Mhm

...que, que está también mostrando y transmitiendo esta cultura. Porque si tenemos developers de nivel de senior staff que está cometiendo errores, no, no errores, como está-- que está quitando cosas muy importantes a, a nivel de calidad, claro que después juniors o mids van a ver y pensar que vale, sí, staffs no está haciendo esto y yo voy a repetir lo mismo porque es algo normal, ah, que está pasando en compañía.

O sea, no solo coges a los directores, em, y, y les transmites esta visión fuerte, esta idea de calidad-

Mhm

... sino también algunos individual contributors, algunos in-- eh, programadores individuales que tienen muchísima ascendencia en el equipo y porque tiene mucha seniority-

Exacto Para mí es una definición de seniority. Si al final, si solo pensamos si seniority es como hard skill 100 % y po-- ¿qué es la diferencia desde staff senior? Que una persona que está programaando mmmuy bien va a programar mejor? Aquí perdemos una oportunidad, porque yo veo todos los,啊，como staffs, es u-- es como un li-- un leaders al final.

Eh, y para mí leaders es alguien que también no solo está haciendo código, que es Qatar tambié-también, am, levantando nivel general de cultura y de ingeniería. Por eso está trasmitiendo mucho, está revisando y está mostrando qué es, qué es bien y qué es mal, ah, haciendo mentoring y también conectando puntos a nivel de to-de todo factorial.

Porque también esto alineamiento de roadmap puede ser hacer directores, pero cosas técnicas es-- yo estoy confiando mucho en, en mi, en mis staffs, porque ellos-

¿Staff? ¿Qué significa staff?

Eso da. Porque es como nor-normalmente en carrier path de ingeniería tú tienes juniors, mids y seniors, y después de seniors no hay-- hay unos staff developers, que es alguien con un montón de experiencia y con este, este nivel de liderazgo. Ah, y es, es seniority. Es, es una marca de seniority en este caso. Y, ah, y para mí es-- ellos están 100 % responsable también al levantar cultura de ingeniero.

La cultura.

La cultura de ingeniería.

Mhm. Y la calidad, el nivel, definir la calidad.

Sí, exacto. Es todo. Cultura está como conjunto de todo al final.

Mhm.

En este caso.

Vale. O sea, es, es un, es un-- es otra forma de liderazgo que no es funcional, no es de reporting, ¿no? Como pasa habitualmente en las organizaciones, sino que-

Es ejemplo

...meritocrático, puramente técnico, de liderazgo.

Es ejemplo.

Y, y algunos de estos ingenieros pueden tener más impacto incluso que un manager, ¿no? Un director. O sea, pueden tener-- 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. Sí, cosas que queremos centralizar Roadmap, queremos centralizar la visión, pero ¿cómo transmitimos esto después a tod-todos los ingenieros que tenemos? Es, para mí es estos semillas, en este caso de a nivel de staffs, es maneira, am, como muy importante para hacer esto.

Mhm. Vale. Hemos hablado de rituales. Em, a nivel de artefactos, ¿cuáles son los documentos, ¿no?, en común que comparte la organización de producto y que, 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, cada dominio tenía su artefacto, un montón de roadmaps, un montón de QRS y-

Notions

... Notions, Notions. Sí, sí, sí, sí. Hay Notion para todo. Aaah, pero al final ahora los vemos que sí, es que nos-- ¿Qué métricas, en qué métrices, ah, estamos interesados en cada producto? Si estamos ver si es healthy o no healthy, si es sano o no sano. Al final es usage, MRR y NPS, más o menos.

Es como tres que podemos ver ca-cada producto y tener alguna, como algún luz color verde o color amarillo si todo va bien o si todo va mal en este caso. Y para mí es importante si todo el mundo pueda saber como mínimo estos tres métricas. Y-

De SLA no has, no has hablado, ¿eh?

El SLA es otro tema. Sí, espérate. Vamos, vamos a sacar esto.

O sea, me, me has dicho Usage, que vendría a ser la métrica de éxito de, de un producto. Es decir, para, 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, y con, con todo el mundo y pasa a ser la métrica que se sigue por equipo a equipo, ¿no?

Este 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, eh, los, los, los pasivos, eh, se restan los, los detractores a los promotores y te da un número, ¿no?

Eso era NPS. Y luego, eh, 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 y he dicho: "No, por favor, hoy es en español". Pero muy bien, ¿eh?

Merci, merci.Pero al final, sí, si quieres tocar también, sí, esos tros --tres métricos son muy importantes. Todo el mundo tiene que saber esto, no solo PM, porque a veces es otro error. Ya en mi equipo lleva esto 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 por esto.

Y es muy importante si queremos al final tener esto empower team. Ah, pero sí, al final yo quiero todo el mundo que es Que tienes esta responsabilidad y que puedes asumir esta responsabilidad y no después poner dedos. Ah, pero otra cosa es SLA, es calidad, es como más, más de bugs que todo el mundo no, no le gusta.

¿Ese qué significa SLA en este caso? Si nos, nos como ingeniería o producto llega un bug de un usuario, tenemos 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 cinco días, si es P2 quince días. Vale, no es tan importante, pero al final cada bug está, ah, estamos priorizando dependiendo de su, de su importancia. Y sí, al final también es muy importante para equipo aprender que en B2B, bugs que tienen totalmente otra significación que comparado en B2C, porque cada usuario, cada empresa está-- tiene confianza en Factorial, pone su información muy importante y esta confianza para nosotros es, es vital.

Mhm.

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, pues yo voy a quitar un poco de-

La confianza se pierde.

La confianza, sí. Gota por gota. Y por eso es importante aprender que bugs para nosotros es algo que no podemos olvidar 100 %. Y tambi-- Pero también a veces es, es muy bien decir esto, que sí, bugs son importantes. Por favor ingenieros, arregla-arreglen cosas. Ingenieros que pueden decir que sí, sí, yo quiero arreglar.

Es más, es más, están de acuerdo. Normalmente siempre todo el mundo está de acuerdo.

Pero tengo mi roadmap muy grande. Tengo un montón de presión de, de todo el mundo que tengo que desarrollar features nuevos y cómo puedo también hacer esto-

Balancear entre cosas nuevas y arreglar los problemas del sistema.

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, es con cosa no es tan popular así en mundo de ingeniería, pero, pero para mí no es algo de: "Ah, esto es otra manera como empresa puede ganar dinero". No, es otra-- es herramienta muy potente para enviar, enviar señales.

Pero más que variables, o sea, que estoy de acuerdo, o sea, 100 % de acuerdo, eh, objetivos, ¿no? Son los objetivos dentro previo a las variables.

Sí, sí. Exacto, exacto. Pero también, sí, también tenemos que tener, ah, esta señal, porque si claro, como OKR, podemos tener un, un objetivo, pero si no llegamos a este objetivo, no pasa nada, no es tan importante para mí este objetivo. Ah, y sí, también tú puedes tener tu roadmap como objetivo y tu SLA como objetivo.

Sí.

Normalmente hay muchos objetivos sin consecuencia.

Exacto. Y, pero también es complicado día a día priorizar. Tengo dos objetivos, Roadmap y SLA, ¿cómo puedo priorizar qué es uno importante u otro es importante? Por eso tenemos que resolver esto y que gente piensa menos, ah, en este nivel y tiene muy, muy como señal, muy, ah, muy fácil para aprender. Y al final es, es una variable, ah, 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, ah, que no podemos sobrepasar. Si pre-- sobrepasamos, mmm, también tengo que decir que esos los puntos. Estos tiempos que he comentado antes a nivel de qué es prioritario, qué es to-todo, si sobrepasamos ese deadline de cuando resolvemos el bug empezamos a asumír puntos.

Ah, y depende de po-- de prio-prioridad de cada bug asu-- vamos, asumimos más puntos o menos, pero al final podemos ver que como Factorial, como un equipo, ah, estamos en general tratando más resolviendo bugs. Por eso tenemos, no sé, dos mil puntos, tres mil puntos, diez mil puntos, algún, algú-algún número.

Y si bajamos este número mejoramos. Si, ah, crece, este número crece, empeoramos.

Mhm.

Por eso parte de,啊， de para resolver esto ponemos una meta que no vamos a sobrepasar quinientos puntos al final como Factorial en general. Es algo compartido-

En un trimestre.

En un trimestre. En un trimestre es algo compartido para con todos equipos. Por eso no hay discusión si es mi bug o es bug de otro equipo, ¿no? No, es todo para Factorial. Ah, y tenemos que tener esta sensación de calidad a todos los developers, pro-- diseñadores y product managers. Es también compartida a todos los niveles.

Mhm.

Y con esto resolvemos esta discusión. Si tengo que priorizar PM, roadmap o tengo que priorizar SLA. Ahora tenemos un, ah, una meta que está muy conectada también a tu salario. Si no llegamos a estos quinientos puntos nadie en Producto recibe parte de su variable.

Está.

O sea, ¿cuáles son los objetivos que tienen los equipos de producto? Uno es el S-SLA. Cómo atacan el problema de calidad técnica del producto.

Escalera técnica. Sí, exacto. Y también es tiempo de respuesta en este caso. Otro tema es, ah, entrega. Este es tu Product Review que tenemos para cada equipo. Revisamos que cada equipo esté entregando y s-- y 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á cobrando, no es también solo una penalización monetaria, es también signal muy fuerte que en este equipo algo está roto, que tenemos que repensar procesos ahora porque vale, este equipo no funciona.

O sea, por defecto en la Product review lo normal es que se apruebe digamos. . O sea que todo está bie-- o sea que está bien. Se han tomado decisiones. Se ha explicado el razonamiento, ¿no? Y, y en este, y en este razonamiento pues se valora este proceso de decisión, de gestión del scope, ¿no?

Y gene-- Lo normal es que esto esté bien, ¿no? 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, no puede ser que en dos quarters el mismo equipo no está cobrando esta parte. Porque si e-e-esto está pasando algo está totalmente fatal. Y también Es otro tema que a-a, as-- queremos hacer algo de manera muy explícita.

Porque antes es normalmente en cada equi-- en cada compañía pasa-- está pasando exactamente esto. Hay algunos equipos muy buenos y hay otros equipos que son malos, ponemos en este caso. Y aquí tenemos que mostrar a todo el mundo que vale. Hay algunos equipos con problemas y tenemos que resolver, resolver esto. Si no resolvemos, es como no hay sorpresas para nada si por ejemplo, tenemos que reestructurar todo el equipo

Vale. Y tienen que de alguna forma los equipos ayudar a los otros, ¿no? Ayudarse.

Exacto, sí.

Subir el nivel, ¿no?-

Sí, sí, sí. Sí, sí, sí

...como tú decías antes, ¿no? Para asegurarse que la calidad es, es, es la que buscamos.

Exacto.

Entre todos los equipos.

Y-

A ver si hemos dicho product review a nivel de, de in-- de objetivos. Me has dicho la valoración de todos los directores eh, qué hacen sobre l-- sobre la entrega y las decisiones tomadas por un equipo LSL A.

Mhm.

¿Y el tercero?

MRR.

MRR.

El MRR Es también parte muy importante para ellos.

Negocio.

Negocios. Sí, exactamente. Porque al final no podemos pensar que estamos-- que producto está totalmente desconectado de ventas,-

Mmm

...de customer success, d-dе mar-- de mercado, de todo.-

Mmm.

Y que se-- estamos desarrollando algo mu-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ías dar más detalles? ¿Qué significa esto a corto plazo?

No, bueno, a ver, eso lo, lo que dice- ...el equipo concretamente de algunas personas del equipo de Factorial, ¿no? Pues di-- o sea dicen hostia pero es que si me ponen un objetivo voy a maximizar el MRR, eh, ¿no? E igual e me voy a dejar de trabajar en cosas más a largo plazo.

Vale. No me gusta así. Algo alguien puede maximizar MRR es-- m-me s-- me suena muy sano en este ca--so. Pero, pero al final yo puedo pensar que qué puedes ser en est ah, que vale, ah, que yo puedo imaginar si tenemos esta parte de MRR, al final podemos olvidar cosas más orgullosos de producto Que va q-que es verdad.

Sí, Ah, no vamos a pensar a nivel de animaci-animación complejos o alguna solución más general que no puede cambiar MRR en este quarter. Pero sí claro que puede cambiar algo en futuro futuro Yo puedo ver este argumento, pero es también para mí es cosa cultural. Si pensamos - Exacto ...que sí, vale, si revie-- estamos-- ah, si pensamos que es v-vale para mí es imposible ver si repetimos el mismo abstracción o el misma idea siempre en diferentes partes de producto.

Ah, y no podemos unificar este y decidir d-- decidIr que pos-- que no voy a hacer esto porque tengo mi variable en MRR.

Mmm.

Más n-no vamos a comprar.

Yo tiendo a pensar que, que la gente es más lista que yo.

Mhm.

En general, ¿no? Y más el equipo de producto. Bueno, todos los equipos, ¿no? Pero veo el equipo de producto Gente que sabe mucho, que tiene opiniones muy fuertes, ¿no? Entonces, si yo soy capaz de balancear el corto y medio largo plazo, ¿por qué no debería hacerlo un equipo de producto, no? ¿Por qué no deberían pensar en sus yos dentro de seis meses? En sus yos Dentro de doce meses?

¿No?

Pero también es importante. No es.-- Es a veces no es prio-priorizar, pero es también conectarPorque cuando añadimos esta variable es una anécdota. Pero al final he recibido tanto pues preguntas sobre negocio de ingeniería-

Exacto

...que me gusta mucho. Claro. Cuando gente Está aprendiendo variables funnel conversion Conversion rates Todo es Muy sanoporque Al finalTodo el mundo erróneamenteEstá pensandoQue yo no Puedo influir Nada. No esVerdad. Si Ingeniería no PuedeinfluirNadaNadia enteoríaPuedeInfluirnadaPorqueEllosNormalmenteEstándesArrollandoCosasnuevas.

PorEsoEnEsteCasopara MíNo estoy comprandoesto.

Y luego eltemaTambién delaDeltemadelLargoplazoal FinalDesde mipunto devistaEsquehayun Hay unasolavidaEh entoncesenEstaVida Tenemosque ConseguirconseguirCrearunaHistoriaunanarrativa. QuéesloqueEstoyHaciendoconMiVidaparasentirmeorgulloso. YtútieneslaoportunidadDeestartrabajandOenUnproductoQulevacambiarlavidaaLaspersonasQuetutilizan enestecaso600milPersonasenSudía adíaquesealtouso.

Ytutete estásplanteandeverdadTeestásPlanteAndovoyamaximizarestocortoplazoporqueehPorquevoyacobrarvariableVoyAcobrarelVariableyo creoquehay quepensarencobrar VariableeseUnaparteimportanteporquèconCobrandoTuVar iableVácobrarlotambiénelRestodeLaorganizaciónmarketingyventasQuvivenEuestecuartoQuvienenesteMesquetienenObjetivosPerotambientienesquePensarengeneraresahistoria yhastasolució Nrompedora.

YEstorequiereMadurezRequiereculturayporesoNotodelmundoserveparatabajar enfactoriale Yesoloqueteiba apreguntarAhoraquéperfilesbuscastuéntuequipo.

ConagenciaEsnormalmentesi noséS ConCristianesse Elmismo.

Agencia Essecon..

Agency.

Sí.

Ahpero valeyogaboJoClar CONpropiainiciativasísísí perotambiénresponsabilidadpara míes unabanderamuyrojaSi yuvoipreguntarpourquéestamoshaciéndoeStoyAlguien meestárespondi endoporquealguienMehadichoEsparamí YomoyaNormalメントengosiessDesconectadoydicestodoesestoyfuriosoDespuéssípEroporqUÉESalgoquemetrIgastrigandomuchoahi SIgenteQue Estoy buscando nopuedendesirestoynoquierandesirestenoes Normalmentenoes normalParaellosdecirFraseComoestaEllosestánaprendiendomuyclaroporqUEestáhaciendoeSto ytengoSuvisiónQuesbien

O quesmalysiAlgoestafueradesus visión ellospaarlevantarsumano ydircerttenemosunproblemaaquitene mosquerpensartenemosQUerepensar. Sevananegarahaceralgo. Síquenocompran

Que, que no es lo que pasaba. Porque ojo, que antes has dicho: "Eh, bueno, la gente tiene buena fe", pero no están-

Sí, cien por cien

...no está cambiando esto de que no.

Por eso me-- es una, un, un motto de Factorial que es convince o get convinced, a-

Mhm. Que es al contrario de Amazon, ¿no? Aparentemente .

Depende. Falta, faltan más detalles ahí.

Básicamente el disagree and commit, ¿no? Y se-- estas dos culturas, ¿no?, disagree and commit o convince or get convinced, ¿no?

Sí, sí, sí. Pero me parece es el mismo al final, si es como falta de detalles, falta marketing, pero es, es muy importante. Si tú no estás comprando algo, si tú no entiendes 100 % qué, qué estás com-cometiendo, ah, tienes que tener esta discusión fuerte, muy fuerte. Y es sano tener discusiones fuertes, ah, pero es también importante salir una sala después que todo el mundo está en, em, está teniendo muy claro por qué tomamos alguna decisión o una decisión u otra.

Y especialmente a nivel de management, a nivel directores, porque si ellos no están comprando algo, algunos cambios-

Se defiende el mundo.

Si. Es--ellos no pueden liderar después a sus equipos, porque al final es también es muy importante a nivel director, que ellos no son solo proxys o son transmi-transmisores de decisiones, ellos son líderes. Y sin agencia, esto no puede pasar.

Lo mismo con staff, ¿no?

Y el mismo con staff.

Pero en general, en todo el mundo, ¿no?Porque tenemos, casualmente, tenemos gente muy, muy joven, junior.

Sí.

Eh, que tienen unas opiniones fuertísimas y que las batallan, ¿no? Y que discuten, ¿no? Y ese--esa cultura donde esto pasa para mí es clave, ¿no? Donde al final cualquier persona puede, eh, imponer, 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 el criterio, pero asumir responsabilidad.

Mhm.

Pero a veces sí, es también complicado. Y depende--a veces también cultura de ingeniería en general, que está pasando en otras compañías, que vale, tenemos algunas sprints, algunas cosas estamos trabajando, pero si algo está roto, ¡ah! Eso no es nuestro. Ah, y yo también es otro trigger para mí, que es al final, ah, si algo está roto y tú lo ves, tú tienes que, no--tú tienes que arreglarlo, tú tienes que llevar a otro equipo, tú tienes que asumir responsibilidad de todo Factorial y no solo tu, 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, eh, ha pre-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 este sensación muy clara que todo es conectado. Si tú ves un problema que tú are--y tú tie--también tienes muy claro que es algo importante, porque a veces es no, ah, es muy conectada de MRR, es muy conectada de calidad y después va a quitar-

Pero igual no MRR de ese producto concreto.

MRR de Factorial, pero al final MRR de Factorial.

Claro, pero esto es lo que la tragedia de los comunes, de todos los espacios comunes. Cómo, cómo se encarga, porque luego evidentemente tenemos un dominio del espacio común de core, ¿no? Pero es imposible, por grande que fuera este dominio, es imposible que se encargara de todos los problemas comunes, ¿no?

Sí, cien por ciento.

Al final hoy es un factor cultural.

Para mí es exactamente es que tienen que llegar staff developers y más, porque si ellos ya 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 t-todo Factorial. A veces es complicado y porque, y es también que quiero cambiar mucho es que staffs para pensar que vale mi día a día es solo entrar código.

Si staff piensa esto, tenemos una oportunidad perdida, muy perdida en este caso. Y para mí es staff es también tiene que dedicar mucho tiempo a reve--tener contexto de to-todo negocio, tener contexto de otros equipos, llevar algunos, sí, revisar código mucho, revisar problemas en otros equipos en subdominio también para buscar estos puntos.

Vale, yo veo aquí algo común, yo veo allí algo común. ¿Cómo puedo arreglar esto? Y hay un montón de soluciones, vídeos, comunicaciones, có--un código nuevo, abstracción nueva. Hay un montón. Pero también es muy complicado poner este solo en description, porque para mí es que más senior persona hay, es má-más complicado definir su, su job rol.

Porque claro, es--hay un montón de variables, como lo mismo como en calidad. Y para mí es también importante que gente esté aprendiendo que a nivel de staff y más, ah, yo tengo que buscar oportunidades para negocio y alinear conmigo, con directores, qué significa esta oportunidad en este caso.

Mmm. ¿Cuántos staff tienes en Factorial?

Ah, más diez, 10, 12 personas, me parece.

Diez, 12 personas.

Sí, sí.

¿Y directores?

Directores cinco.

Cinco.

De engineering cinco, sí.

Y luego tienen por debajo engineering managers. Cada uno de ellos tiene entre cuatro y seis personas.

Sí, sí, sí, sí.

Em, ¿qué tiene que hacer un desarrollador para promocionarse, para crecer? Siento que es una pregunta que mucha gente se hace dentro de Factorial.

Exacto. Y también es, es un challenge en todos los equipos, porque al final tenemos career path. Es una--es un documento que está describiendo que vale, si, cómo tú, tú puedes crecer en factorial y para mí es algo sano, es muy bien que tenemos y es algo importante, pero también, ah, si tú pones, si tú haces muy, muy complicado, va a convertirse como en un juego.

Si yo voy a po--cerrar todos estos puntos automáticamente me va a promocionar.

Un algoritmo, ¿no?

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-- del manager. Para algunos, ah...

esto sí para otros nooo También es realmente tiene otra definición que es, eh, de cada de estas partes, mmm, puntos. Por eso no es algo que hemos solucionado 100 %, es algo que intentamos solucionar pero al final es el lo mismo primero todas las promociones son públicos que ca-cada vez que te promovemos una persona estamos publicando documento por qué promocionamos a esta persona y es para mí es lo mismo es cambio cul-cultural si todo el mundo está revisando que vale tenemos una persona aquí que ahora es un senior ¿y por qué hace A B C D?También yo voy si soy un mid yo voy a revisar o yo voy a copiar.

Por eso cada promotion también está revisando por director. Y si estamos directores alineados es muy fácil, ah, que revisemos todos los promotions. Estamos seguro que en este documento todo es muy explicado, ah porqué promocionamos personas y para mí es más importante sí es muy importante tener ese documento career path Pero en realidad yo quiero que todo el mundo esté revisando porque promocionamos gente y está conectando dots, ah por su mismo.

¿Quién recluta en Factorial?

Managers En sentido que si tenemos recruiters 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á haciendo hiring Porque y también yo porque pa--yo estoy como un punto final en todos los hiring processes porque para mí es importante si no queremos romper cultura de Factorial al final que estamos que tenemos y que mejoramos día a día para mí es importante realizar toda la toda la gente que está entrando Y también es otro tema que al final es muy complicado aliñarnos Es

Vale Si contratamos gente correctaPorque si túsi estamos sin cinco dominiosun montón de managersY cada persona está contratandoClaro quetú tienesSu visiónSu experiencia contratarY su criterioQueA vecesAl finalVamos a tenerUn señorPersonaque esseniorEn undominio quees enrealidadseniorY otradominio quePuede serun juniorPero llevauntítulo deseniorEsta inflaciónDe títulosPuedepuede pasarPor esoalfinal resolvemosestoConahpersona QueEstá responsableContrataresmanagerPerotambién TenemosUnequipo DeComoEs lomismo ComoAmazonBar raisersQue esequipode

ConfianzaInternoque EstáRevisandotos LosTodo códigodeChallenges QueEstamos recibiendoYestá Poniendo SuSome deinterés

Las challengesSon Las pruebasTécnicasSí Sísí Quehacetodo ElMundo QueExactoparaEntrar

ConEste PodemosTambién TenerUnaExpectaciónGeneralizadaQue esQue es UnChallengeBueno QueEs Un ChallengeMaloEn Este CasoYEvitamos SorpresasYo comoun challengeFinal paracada PersonaQue estáentrandoPara Mí Eso MuyImportanteTambiénEnviarEse mensajeQueSi estamósmás O menosGrandesy enteoría YoNo puedoSercomo UnaPersona FinalEnTodos loss hiringspero No EsVerdad espodemosHacer CosasQueno Sonescalables peroes soloÚnica ManeraCómoPodemosControlarla AlfinalLa calidadYrevisarque cadapersona Queentra Esesmuy

buenPersonay muychula

¿Has rechazadoAlgún perfil?

Unmontón

¿porQué?

Ah yoPersonalmenteSíaVecessí esporqueNotiene Estevisiónde productoNo tieneno Tiene Estaagenciaeso Esparamí esAlgo queYo EstoyIntentandoverificar encadaencadaentrevista QuetengoPorque sitodoEl MundoEstáconeg energíaBaja enesteSentidoquenotieneesta iniciativaestambien Algoque estácambiandosusuedrededorporeso yoEstoybuscandotambiéngentequettiene unmontónde iniciativasypuedaExplicarmeensupuestoanterior Quéha cambiadoquécosashancambiadoestalbiénimportante

mhm UneEmpower teamnoquele llamamoscómo cómo Cómoestà formado quiénhayEen unequipo quelleva unaparteDelproducto

esteparta nohemos cambiadoo esal finaltenemoss productManagerproduct designerEngineering Managerengineering managertambiénye unequipot deingenieriacuántosdependeperomáximoseis seiso ochoenalgunosexiposperosi alfinales cómomáximo demanageren estetecaso yaparamíes empowermean significalomismoque Hemosdiscutidoque ellostienenMuy claroquitiennentqueresolver todolosproblemasdede usuarioestáncontrolandsucope yhastaan entregando

Cuál esperatiel rol DelProduct manager

esencontrarchallenge encontrarpainsencontrarle problemas Deusarioyhacer go tomarketporqueesteestimbién muyimportanteal finalyque estamosfallandoum montón deemquiposestán fallandoengeneral nosolo enfactorielque estamosdiseñandoy haciendocosas muybuenas quetenemos unbeenfedback deusarios perono sabemoscómovender estoy cómodespuéspodemosmostrar atodo elequipo degoto marketCómovendereya totelmundoy estesparamí esosuna responsabilidaddel productmanager

Liderarel procesode gotomarketexactoejemplo empezarserlospionerosdelgotomarketsísiproductosy el producedesigner

parami és unmejor amigode ingenieríaen sentidoqueellos siempretienenquetrabajar juntos porquesiempre queyo cuando yoveoquetodoslosfeaturesnuevosestán empezandoconhigh fidelitydesigns paramiesalgo erróneocien poresientepoqueen ingenieríaydiseño Cuando trabajan juntos están haciendo un montón de prototipos, verificando cosas, discutiendo cómo podemos solucionar esto de manera más rápida.

Porque es ma-- 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 es, no es solo prototipo en Figma , que ellos puedan, ah, tocar y usar en su día a día en su empresa.

Por eso este tiempo time to market pero time to prototipo en mi cabeza es mu-es algo muy importante y que tenemos que, ah, mejorar en cada equipo. Pero solo una manera para hacer estos diseño trabajando junto con ingeniería.

Mhm. Sí tienen que trabajar, tienen que ser uno, ¿no? Tener la men-la visión tecnológica muy clara. Exacto, exacto. No pintar pantallas.

Sí, sí, sí. Pero también lo importante es estoy pensando esto a nivel de qué es empower team, ah, qué es empower dominio en este sentido. Porque si, si solo comvemo-- continuamos con esta manera, pero cada equipo es un silo que está tocando solo su parte de producto y está planificando todos los challenges y pains en s-su pa-- solo su parte de 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 familia de productos. Y para porque a veces está pasando que tú tienes una iniciativa o una oportunidad más grande, m-más derecha en otro equipo o en otra que, ah, o en otra parte del dominio, y tú puedes sacar esto o arreglar esto y al final llevar más MRR, más usage, más...

Todo, todo más.

¿Cuáles son los principales retos de cara al año que viene?

Pregunta así muy...

Sí, ya también 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, eh, de cara al año que viene para el equipo de Producto de Factorial. Para mí es continuar con este alineamiento de directores que ellos sigue. Es como tenemos que buscar algunas personas, pero aún tenemos que, sí, encontrar algunos perfiles y alinear todo el mundo.

Y después, ah, cambiar este chip cultural. Porque yo veo algunos cambios ahora después de estas cinco o seis meses, pero no estamos ahí, Tenemos que trabajar más y al final me, me, para mí es un challenge que a nivel de directores, a nivel de staffs quiero otra capa de que, ah, de staff developers que yo puedo confiar mucho, que ellos van a levantar acá en cultura, que ellos van a liderar algunas iniciativas desde bottom up.

Ah, sí, y por eso continuar con el proceso que tenemos, pero escalar, escalar, escalar en este caso. Mhm. Muy bien. Oye, pues yo creo que te he preguntado casi todo. No sé si me he dejado algo. Bueno, lo que me-- Lo que no te he preguntado es cómo fue tu, tu experiencia, eh, previa, ¿no?

Tú montaste un negocio. Sí, sí. He intentado. He intentado montar.No sé.

¿Qué pa--qué pasó ahí?

Ah, sí, es-- fue una experiencia parcialmente brutal en, pero es también que yo, si yo pueda, si voy a tener una time machine, yo voy a repetir lo mismo cien por cien. Al final es yo ten-

O sea, volverías a hacerlo, ¿eh? Volverías a hacerlo.

Cien por ciento, cien por ciento,sí.

Porque antes de eso, se-- tú, tú estudiaste Informática-

Sí.

Ennn, en Rusia.

Sí. Robótica.

En robótica.

Sí, sí.

Robótica, ¿eh?

Sí. Automatización. Automatización, sí.

Vale. Eh, ¿y qué hiciste antes de Red Booth? Rápidame-brevemente.

Eh, pff, antes de Red booth. Am, vale. Inicialmente aprendido a hacer programación haciendo mi propio startup porque yo quería, sí, yo quería hacer un to do list muy, ah, como, mu-- en manera muy diferente.

¡Qué raro! Un ingeniero haciendo una herramienta de to do list.- Nadie lo hemos hecho.

Sí, sí, sí,- ...Pero totalmente diferentes, realmente diferentes. Totalmente diferentes Siempre pensamos eso. Sí, sí, sí, esa es verdad. Ah, y al final sí. Mmm. Y mi motivación fue: Vale, me falta esto. Yo quiero tener esto. ¿Cómo puedo? Aprendí programar. Ah, también he montado un equipo. He encontrado un diseñador, ot-otro programador.

Todos sin pagar nada. Porque sí, fue su cien por cien.

Eran gratis. Ahí en Rusia son gratis.

Todo es gratis. Sí, claro. Comunismo.

Pues no eres gratis.

Em, porque sí, estamos en España. Ah,vale. Ah, y al final sí, es, ah, no es porque pensamos en idea. Si motivamos gente. No nos cobramos nuestros usuarios, pero al final..

Como arranca todo.

Sí, sí, sí, sí. Cómo arranca todo. Startup cien por cien. Pero al final hemos tenido un éxito. Pues fue años dos mil ocho, dos mil nueve. Es que cuando publicamos alguns portales como Product Hunt, ahora es en el mis-misma noche teníamos un mil de usuarios y un montón de- Mil. Mil. Mil.

Sí. Ah, bueno, en ocho horas. Sí, es como hace doce años. Como Doce años. Doce años. Sí, es como Internet en Rusia. Realmente fue diferente y todo. Ah, pero sí, fue un primer de estos to do lists con web 2.0, totalmente con, con Ajax y todo es mu-muY diferente y fue tenía buen pinta, pero después desarrollamos tiempo libre para más, dos más años y hemos vendido, hm, este proyecto.

Sí, al final fue como un primer éxito con, vale, Desde cero he recibido algunos, algún dinero y fue como- ¡Ostra! Sí, un bue-un bu-buen ejemplo para, vale, yo puedo mandar equipo, yo puedo encontrar una idea y yo puedo vender.

Pero durante los dos años nadie cobró.

No, nadie, porque es imposible. En ese momento en Rusia no había esta experiencia de pagaaar, ah- Los programadores. Ah, lo pro-- no, lo pro--, em, sí, porque al final- Digo, la, la gente que trabajaba, ¿eh?, los programadores. Pero todo el mundo tiene un parte de, de este, de este proyectos.Es como un...

Ah, ¿si?

Sí, al final fueron tres, tres programadores, un dese-diseñor. Por eso es equipo muy pequeñito. Pero al final sí, cuando vendimos, claro que ca-cada persona recibía parte de su dinero.

¿Y fue un buen exit?

Sí, claro que es todo relativo. Pero ne-- para mí en este momento sí, sí

¿Te cambió la vida?

Ah, he comprado coche por eso

Vale

En 21 años y fue como un-

Hostia

...sí, un vale. Pero claro no es tan éxito grande pero al final no cobramos No fue un negocio solo un proyecto con algunos usuarios Con miles de usuarios pero Vale ah, no es algo-

¿A quién lo vendéis?

¿Ah?

¿A quién lo vendisteis?

Oh una como no sé cómo está aa venture, venture builder al final de-

Vale

...al final del momento Ah, mmm y después mi, me gustó mucho esta-

Normal

...si experiencia con startups y eh, pero empe-empe continuaba trabajar como desarrollador en remoto para haciendo freelance Eh, algú-en algún momento he intentado trabajar por una agencia Ah, me máximo Como 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 re-resolviendo en dos días Y después ellos me están diciendo que: "vale tú tienes que so-sentar pensar que ahm"-

Haces hacer ver que haces cosas

Exacto Eso pero no hacer nada y para mí es mal No, no, no es imposible Pero y al final encontrado un otro startup que me gusta mucho Que se llama, que se llama Resume Up Que la idea fue aquí en un clic Tú puedes conectar su LinkedIn Facebook o algo y vamos a generar un resume Un CV, ah, infográfico No es un texto pero es como si Infográfico y tiene muy buen pinta tecnológicamente También fue muy, muy, muy complicado Ah, y me gustó mucho Empezó como team lead ahí, ah, y trabajaba allí do--por tres años y en algún momento fui a Barcelona para hablar en un conferencia y he encontrado RedBus

¿Qué conferencia?

Ah Es Fue sobre Ember JS Es como sea una framework de JavaScript En este momento

Vale Y, y hablaste ahí-

Y hablé con Jordi Sí He hablado con Jordi

A Jordi

Así Después a Pau

Entonces te hicieron el lío y, y te viniste a Barcelona a vivir

Exactamente Y al final sí Como estoy siempre estoy escuchando que a-- nos mudamos por trabajo pero al final quedamos por ciudad Porque me gustó mucho Barcelona

Ah, se vino por Jordi Pau

No Perdona, Jordi Pau No, pero al final sí Cuando Jordi pau Se fue también Si ha cambiado puesto Pero sí pensamos que si con mi mujer Siempre podemos volver a Rusia pero no queremos No voy a hablar sobre política pero también sí Porque a nos, nos gusta mucho Barcelona España y-

Muy normal Muy normal Entonces e-en un momento dado sale este Redwood y entras en Camalooon Pasas un tiempo en Camalooon como CTO

Mmjm

Eh, y en un momento dado decides emprender

Sí

Que es este mixed feeling, ¿no? Cuando alguien te dice: " bueno y voy a montar mi negocio," ¿no? Dices: "hostia qué putada."Por un lado, ¿no?Porque pues pieza clave, ¿no?, de Camalooon

Mjm

En aquel momento Juan casi tuvo una depresión Eh, 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, y vas a montar mmm lo tuyo, ¿no? Y además con financiación muy, muy temprano, ¿no?

Sí, sí Al final fue totalmente muy natural Ah NaturalPero también he tenido una idea en ese momento de COVID cuando estamos todos muuuy en remoto y todo trabajando desde casa Aaah, que yo he encontrado que vale Mi día empieza a las, las ocho nueve Finaliza a las ocho o nueve y sss--dos horas doce horas Solo mirando a mi laptop Actualmente sí Muy cansado sin energía Sin nada Estoy pensando pero mi calendario también Está sabiendo mi día a día Todas los reuniones que tengo Todos los mmm, ah, como time blocks que tengo también ¿Por qué no está haciendo

como un coach? Que vale Tú tienes mucho en tu, en su plato Tú tienes que quitar algunas cosas replanificar o ir al gimnasio O bueno pero sí cambiarme Cambiar mis aaagh-

Hábitos

Hábitos schedule

De salud

De salud, sí, sí De día Porque y he intentado hacer como prototipos Cómo puede serCómo,cómo podemos ver esto Ah-

Por cierto que eso tú lo utilizas hoy

Sí

¿No?-

Sí

¿Esa es tu app la que tú utilizas?

Sí

Ah, vale Porque lo visto en tu pantalla que de repente dice:"tienes que levantarte no sé qué" ¿No? Para ahora para de trabajar Y digo qué hace-

No, noEso es otra cosa Otra vez Otra es otra Es otro prototipo

Ah, vale

Am, pero vale Aaahg, sí Y al fi-al final como mm, in-in-he intentado Sí He empezado a hacer estos prototipos y publi-y publicado cosas en Twitter Que mira Aquí tengo esta idea Tengo esta idea Mira cómo puedo hacer Y he recibido un Una llamada que vale Estamos unaaa venture fund que también estamos pensando Lo mismo como calendario como smart Eh, o ella hay calendario No sé cómo, cómo podemos llamar Este que tenemos que hablar y al final hablamos Es que al final con idea, ah, levantando dinero y oportunidad que crear un producto desde cero

Dinero es casi un millón de euros, ¿no?

Sí, sí más o menos

Osea es-

Un poco menos pero sí

O sea de entrada que alguien recibe una llamada y te voy a dar un millón de euros para que montes esa app que has puesto en Twitter

Sí No pero también no es También solo de tweets Yo voy a recibir un millón de euros Fue un común-

La gente va a empezar a twittear esa -

Sípero sí A, a crear en público a veces tiene sentido porque todas los Mis conexiones fue por Twitter Jordi es Twitter Al final este, este experiencia de emprendedor también Twitter Por eso sí Hacer cosas en pu-- manera pública Tiene sentido Am, pero al final, am Fue business plan, fue como un montón de, de charlas.

No es solo un tuit que levantó tan-- tanto dinero. Pero sí, dos, dos años intentando buscar... creando equipo, creando producto, pensando a nivel de go to market. Sí, también poniendo estos gorras de yo no soy solo un programador o CTO, también CEO. Ah, tengo que pensar a todos los niveles de, de negocio y si negocio tiene sentido, es cambia tu perspectiva mucho.

Y-

Totalmente.

Sí, y también cuando tú tienes... sí, es claro que he tenido dinero, pero no es solo dinero para años, años. Es al final es tú ves-

¿Pero contrataste mucha gente?

Ah, no mucho, pero a, al f-- como en máximo tenemos como once personas. Am, pero... y al final, sí, tú ves co-- tú, tu runway también no es indefinido y tú tienes que tener ah, algunas cosas en, en proceso. Pensamos que vamos a hacer B2C clásico, que vamos a tener un producto, que vamos a vender a customers, que ellos van a pagar con su suscripción.

Y encontramos al final que es muy complicado. Primero es am, mercado de performance, de como productivity. Es algo muy raro que no voy a nunca a decir que tienes que ir ahí, porque sí, es como reduction 100 % y también, aaah, ACV ahí es como muy, muy, muy bajo.

Ah, ge-- para gente es normal comprar algo para dos o tres o cinco euros por año y cambiar, ehmmm, aplicaciones cada mes. Es, es más normal, pero ese churn es muy alto y el ACV es muy bajo. Ah, pero también, ah, CAC es imposible alto en este caso.

Ah, por eso pensamos, pensamos, pensamos, revisamos que es muy complicado y encontramos otra manera que en teoría podemos entrar a B2B, porque todo el mundo está especialmente hace dos años, pensaba que vale, tenemos un montón de equipos remoto. Burnout es-- fue una palabra deeé...

De moda.

De moda, exacto. Y hay un montón de coaches que está haciendo este coaching para cada equi-- 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, ehm, tu schedule. Ahm, 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 qué es tu calendario, está conectando todo y puedo mostrar a, mmm, y junto con un coach que puede también explicar a ti por qué es importante revisar todos esos datos, puede ser una pareja ideal.

Aaah, y al final, sí, también ahora estoy revisando que hay algunos negocios que están creciendo mucho en este espacio, pero también mi inversor en este momento está diciendo que vale, tiene sentido. Ahí vemos que es, es una idea, pero estamos 100 % B2C. Por eso, si quieres continuar, vamos a busca-buscar alguien nuevo que pueda-

Un inversor nuevo.

O un versor nuev-- o un inversor nuevo que también puede ayudarte con experiencia B2B, porque esto realmente otro mundo. Es... Ah, pero después de dos años, también mi cofounder en este momento tenía su primer hijo y fue como unos momentos muy complicados para: Vale, no po-no Podemos levantar otra ronda. También, no estamos 100 % seguros si queremos continuar con esta paz.

Y paramos un proyecto y yo he recibido una llamada de a ti.

La mía, ¿no? La mía, ¿no? Intentar recordar si era Pau o yo.

Sí, sí, sí.

Vale. Muy bien. Menos mal, menos mal por la parte Factorial, ¿no?

Sí, sí, sí.

Es una putada, eh, cuando, cuando ves que no sale un proyecto. Pero bueno, fue, fue relativamente breve, ¿no? O sea, visteis reciente rápido-

Mhm.

Que no is-- no ibais a dedicaros a hacer esto, ¿no?

Sí, sí, sí, sí, sí. Pero sí, es al final esto todo q-que es conectado mu-- a calendario es muuuy 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 patrones, es muy complicado monetizar esto. Por eso a nivel de negocio es también un challenge general.

¿Tú te ves, eh, CEO en el futuro o CTO? Te ve-te ves echándome de factorial, lo cual sería, estaría bien.

Al final es lo mismo como en Este Empower Team. Yo estoy pensando y creando a nivel de overlap. Todo el mundo tiene que hacer un overlap. Y si vamos solo, vale, sitio llevando ingeniería, SEO están llevo solo negocio, va mal.

Por eso para mí no es tan importante que es mi título. 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. Ah, por eso si yo tengo esta libertad y nadie me ma--me está diciendo que: "vale, tú solo ingeniería, trabaja en ingeniería", mmm, yo estoy cómodo.

Mhm. Oye, muy interesante. Eh, muchas gracias por contarnos, eh, tu historia y, y un poco cómo estamos construyendo producto en Factorial. Y bueno, seguiremos contando, ¿eh? Aquí cada X 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, ¿no?

Sí, sí, sí.

Y, y mucha gente dice: "Oye, pues no es lo mismo ahora que esa empre--la empresa es grande y ya no es lo mismo como en los viejos tiempos". Para mí es al revés, ¿no? O sea, este reto que tenemos ahora, ¿no?, de conseguir esas personas con tanto talento, ¿no?, tengan el espacio para crear, para construir, eh, para, para hacer historia-

Mhm.

Eh, es superinteresante.

100 %. Sí.

Y más cuando tanta gente del mercado le interesa lo que hacemos, ¿no? Eh, y están dispuestos a utilizarlo y a pagar por ello, ¿no?

Sí, sí. Y para mí-- y me parece Tenemos esta libertad que yo estoy comentando, que nadie va a decir que tú solo ingeniero, por eso toca código y nada más. Ah, no, tenemos una libertad que es si tú quieres crear un producto que tú estás orgulloso. Sí, me parece Factorial es un lugar ideal para esto.

Perfecto. Call to action final.

Exacto. Vendemos un poco.

Muy bien. Pues nada, hasta la semana que viene. Chao.