Devin AI, Tiktok BAN y los Product Designers | Jueves de Itnig

Aquí estamos como todos los jueves. Hoy en un nuevo setting. Hemos cambiado al otro lado de la calle para inaugurar este espacio que todavía no está inaugurado, pero bueno, ya hay alguna startup como Genedy. ¿Qué tal, Genedy? ¿Cómo, cómo va el espacio? Bueno, todavía, todavía está medio vacío.

Oye, la semana pasada se me criticó llevar una sudadera de un inversor y hoy me he asegurado de llevar una de una participada.

Es increíble la cantidad de spam que hacemos desde Genedy.

No, tú has empezado tú. Aquí no pone nada, esto es una sola solo.

Bueno, ahí estamos con César Migueláñez, Jordi Romero. Y tenemos aquí un pequeño panel de producto de Factorial: René Galindo, Jonathan Centeno, Alba Hornero. Eh, y estaría muy guay... Estamo-- estaba escuchando una discusión arriba sobre, sobre el product designer, la figura del product designer, ¿no?, que es una de las mil discusiones recurrentes que hay normalmente en las empresas de producto y común en Factorial.

Y, y creo que podría ser interesante empezar por aquí, por repetir esta discusión que estemos teniendo en Factorial, ¿no? Porque estamos en un momento donde estamos replanteando mucho cada uno de los roles que tenemos en Factorial y uno de los roles, eh, clave en Factorial, de hecho fue el primer empleado de Factorial que marcó bastante el ADN de Factorial, fue César, eh, con el rol de product designer.

Y, y de hecho René me dijo: "Oye, mmm, ¿me puedes presentar a César? Porque quiero entender..." Eh, ¿no? Ayer justamente, ¿no?

Y les has sentado a seis metros.

Sí, exacto. He dicho:" Sí, pero en directo". ¿No? Entonces, em, bueno, vues-vuestros roles. Tú eres design lead, project design lead. Design lead en el dominio de People. Presentaros, presentaros vosotros mismos.

Soy René.

Hay que, hay que encender el micro antes. No, la UI kit, la UI kit es complicada, hay que... Es prolongado.

Ah, vale. Design Lead también, Jonathan Centeno, en Time y Payroll. O sea, estamos divididos en varios, en varios equipos.

Hostia. Qué mal.

¿Puedes venir aquí, Alba? Puedes venir para aquí que hay como tres metros vacíos si quieres. No es muy cómodo, ¿eh?

Sí.

La evaluación de desempeño, que le llamamos aquí.

Muy bien. Oye, pues hay, hay un debate y le he pedido, de hecho... Ah, bueno, te lo quedas. Le he dicho también a Alba que bajara para dar su opinión como PM, eh, sobre cuál es el rol, dónde empieza y dónde acaba esta línea imaginaria entre el product designer y el product manager, ¿no? Em, hay escuelas de pensamiento que creen que el product manager, pues tiene que participar mucho en la solución, de hecho directamente escribiendo los specs, ¿no?

Y casi diseñando wireframes y que el diseñador es, es quien luego pinta. Me veo la cara, he visto la cara. Y luego están los que piensan que el, que la, el PM, eh, es negocio puro, eh, tiene que entender impacto y costes, pensar la P&L, ¿no?

Y a partir de aquí cuando decide esto es una oportunidad, entra el ingeniero que no está aquí representado, porque no podemos tener tanta gente.

Bueno, a ver, tú y yo podemos hacer de ingenieros, ¿no?

Y el product designer y se encargan de todo, entre comillas, ¿no? Y aquí es donde Alba hace la cara de: "¿Cómo?".

Hay muchos grises. Que es donde...

E iremos al rol del, del PM. Igual PM daría para otro pódcast. Vamos a hablar del PD hoy. Vamos a hablar del PD. Eh, René, ¿puedes explicarnos qué es para ti un product designer? Tú, por cierto, puedes dar un poco de contexto, que tú empezaste como uno de los primeros empleados en Cabify. Quieres hacer un briefing.

A ver, pequeño contexto. O sea, cumplo dos meses en Factorial.

Una eternidad ya.

Sí, ya se siente largo. Eh, antes de eso estuve, eh, principalmente en Cabify, eh, hasta hace ya bastantes años. Fui el segundo product designer y me tocó, eh, junto con Mark McKay, que se une a Factorial también, gran noticia, eh, eh, crear el, el equipo de producto, ¿no?

El equipo de diseño de producto. Em, pasamos un poco por la fase de, de caos total, de no tener PMs y donde el product designer, eh, adopta un poco esa figura de, más de producto, hasta ir metiendo roles más especializados de product managers. Una fase de fricción clara, ¿no?

Porque es un poco algo que antes el product ma-- el product designer creía que hacía. Ahora llega uno más especialista que, que se empieza a meter en ese terreno. Personalmente tuve mucha fricción ahí en esa parte. Eh, y después, bueno, quizás esa fricción me llevó a pasar como a otros proyectos dentro de Cabify, en el área new business, que fue Movo, las, las motos que ahora están en parte de, de Cabify.

Eh, después una fintech que se convirtió en su propia empresa, que fue Lana. Y ya no como Cabify, pero el último proyecto fue Invopop con Sam, con quién sería interesante que hablara igual. Eh...

Que era el CTO de-

CTO fundador de Cabify y de Lana también.

¿Cuál, cuál era la fricción exactamente? Esa fricción que tú viviste, ¿cuál era?

A ver, creo que era una fricción personal en mi caso, ¿eh? O sea...

Vale, tampoco, o sea-

Quizás era, era una-- un momento de muchísima hambre, ¿no? De, de quererme ganar un puesto en, en Cabify y en la industria. Eh, y quizás una falta de tacto. Yo a veces lo llamo política, a Bernat no le gusta esa palabra, eh, pero sí de, de, de crear relaciones con, con los otros product managers, ¿no?

O sea, no me gusta porque la, la, la usas en positivo.

La uso en positivo, claro.

Lo puste como algo bueno.

Y lo he hablado con Alba también. Eh, sí, esto tiene una muy mala connotación. Quizás tengo que pensar en una nueva palabra. Pero para mí es ese, es esa capacidad de crear relaciones con otros roles, con otros departamentos y, y de tener mucho tacto. Eh, a veces cuando tienes muchas ideas y mucha creatividad, te sale, eh, puedes parecer un poco tóxico, ¿no?

Y crees que estás haciendo lo mejor por la empresa, pero tu, tu energía te rebasa y, y, y puede sonar que, bueno, que estás metiendo, eh, ambiente tóxico en el equipo, ¿no? Eso me pasó un poco en Cabify a mí personalmente. Aprendí muy cara mi lección, porque, bueno, me tocó ir cambiándome de proyectos, que al final algunos salieron bien, otros peor.

Pero lección aprendidísima y ahora intento ser un poco más, bueno, canalizar un poco más mi energía creativa, ¿no?

Más allá de tu, de tu visión personal y tu situación personal, esta fricción-

Sí.

Cuando entran los product managers, no se produjo solo en Cabify. Se produce en muchas compañías, ¿no? O sea, es un momento donde parte del rol que hacían los generalistas, ya no solo en product manager y product designer, en general, cuando aparecen los especialistas o gente más especialista y poco a poco van reemplazando funciones de los generalists, que son normalmente los que empiezan las compañías, ¿no?

Sí, así es. Y creo que en ese momento, como, o sea, en Cabify, como en muchas otras empresas, no estaban claras las, las, las líneas entre un rol y otro, ¿no? Y mi perfil personal quizá raya más en un product designer que está más cerca de producto o de querer tomar decisiones estratégicas para la empresa.

Y, y bueno, hay que saber en tu, en tu line up de product designers que tienes quién tiene qué característica particular, ¿no? Y saberlo acomodar en un lugar donde... O sea, no todos los product designers son iguales. Creo que eso es lo primero que, o sea, que hay que recalcar. A veces parece, como en el modelo del trío, del product manager, product designer, engineering manager, que todos son exactamente iguales y que-- y ahí creo que hay muchísimas sutilezas.

Total.

Y encontrar esas sutilezas y saberlas acomodar es muy complicado. Es más fácil meter en una caja tres aquí, tres aquí, tres aquí, tres acá.

Ese es el error que yo creo que se hace muchas veces cuando se quiere escalar equipos de producto. Creo que es un error que hicimos también en Factorial, donde haces un grid, ¿no? Y entonces la gente ya no es gente, ya no son personas, son, son roles. Entonces, empiezas a rellenar roles, ¿no? Igual como no hay dos ingenieros iguales, porque hay un ingeniero que igual es más backender, ¿no?

Y se le da mejor, pues yo qué sé, las bases de datos o, o el mundo infra. Eh, y hay otros que son más front-end. Igual hay di-- ba-- hay developers que les gusta diseñar, ¿no? Hay, hay perfiles muy diferentes, ¿no? Pues lo mismo pasa con los product designers y pasa con los PMs. O sea, al final...Entonces, el problema es cuando las cosas se convierten en un grid de roles y hay que empezar a rellenar roles, es cuando se empiezan a generar Frankensteins, ¿no?

Eh, que no digo que sea nuestro caso.

También creo que hay una, hay una-- hay un problema, que nosotros lo estamos haciendo ahora fuera deeel día a día de las decisiones de negocio, ¿no? Lo estamos haciendo aquí un poco para compartir nuestras experiencias con el público del podcast Itnig. Pero hay equipos que pierden más tiempo discutiendo qué tiene que hacer el designer, qué tiene que hacer el ingeniero y qué tiene que hacer el product manager, en lugar de discutiendo qué tiene que hacer el usuario o, o cómo podemos cambiarle la vida al usuario, ¿no?

Yo creo que esa es un poco el principio del fin de la política mala. Antes hablabais de política. La política mala es estar discutiendo más rato. De si tú, Alba, te puedes meter en el wireframe o no te puedes meter. Y si tú tienes algo que decir, en qué problemas solucionamos o, o te callas y dibujas, ¿no?

Hay que poner una casilla de Química en el Excel.

Yo creo que la mejor señal de un equipo que funciona es el equipo en que se pisan la gente y no lo ven como un problema. Están todo el dia pisándose. To-- El, el ingeniero está pensando en el diseño, el diseño, el diseñador pensando en la tecnología y nadie lo ve como algo personal, ¿no?

Que eso es la startup early stage, ¿no? O sea, esta es la actitud

Estáis todos haciendo de todo, eh, dudo que nadie esté documentando qué hace cada uno.

No, total. Y de hecho es algo que, que también yo puséo mucho, ¿no? El-- pues a veces estamos trabajando, yo qué sé, ahora que hemos sacado un, un producto open source. Tenemos una librería de componentes y algunos componentes que utilizamos ya algunas piezas por dentro, que más o menos el diseño, pues queda bien, ¿no? Em, pues yo muchas veces le digo a-al developer que está implementando algo: "Hazme una propuesta, hazme una propuesta de diseño", porque nosotros estamos con otra cosa, eh, y no, no podemos cambiar el foco ahora mismo a esto.

Y seguro que tú vas a ser capaz de hacer algo con sentido y, y luego ya yo, pues sí que te puedo orientar, te puedo poner algún constraint, te puedo decir: "Bueno, pues esto quizás lo hacemos de esta otra forma". Eh, pero la propuesta inicial muchas veces viene del developer. Em...

Me están viniendo flashbacks de lo contento que estabas cuando Pau Ramón, eh, se inventaba diseños. Porque tú eras siempre el cuello de botella. Siempre los diseños era lo que tardaba más. Y Pau, que iba muy rápido programando, era en plan: "Hostia, no hay diseño, me lo invento." No estás muy contento tú, ¿eh?

Depende, depende. Yo creo que si el sistema de diseño, si empiezas con un buen sistema-

No había sistema de diseño. Bueno, copiar la web de Stripe.

Estos son secretos que, que no se dicen. No, em, no, yo creo que cuando, por ejemplo, nosotros, o sea, por hablar de casos prácticos, eh, estamos utilizando por dentro una librería que se llama ShadCN, em, que son una serie de componentes de front-end que, que ac-actúan de sistema de diseño. Entonces, hacen mucho el trabajo de sentar las bases, de qué pinta tiene que tener una interfaz, ¿no?

Entonces es muy fácil entre esto y otra herramienta que se llama Tailwind, que ya más o menos, pues también te, te orienta mucho a hacer las cosas de una forma, em, pues generalmente las cosas quedan bien de, de primeras. Entonces, cuando tienes una base de diseño muy sólida, es más fácil conseguir que el developer haga una propuesta que esté más cerca del producto final, que, que sea otra cosa, que vaya por otra dirección.

En cualquier caso, no había ninguna fricción. O sea, tú juzgabas el diseño que hacía Pau y luego lo arreglabas. Pero íbamos a, a todo gas haciendo lo que podíamos, ¿no? Que es lo que esperamos de la química de los equipos de, de producto, que en lugar de tener estas líneas tan claras, tiren millas.

Una de las cosas que estamos en el momento en que estamos hoy en Factorial es intentando que el, el product manager adquiera una posición más estratégica, de sc-- más scope, eh, y que los, y que los productos tengan más product designers, ¿no? Estamos contratando más product designers y por eso hemos hecho todo este proceso de, de definir qué es y qué no es un product designer y un poco cuál es el, el perfil que queremos, ¿no?

Podemos explicar qué es y qué no es para nosotros hoy. Pues vosotros dos representáis el leadership de Product Design en Factorial, ¿no?, entre los dos. Eh, y sé que incluso entre los dos tenéis en algunos ámbitos divergencias de opiniones, ¿no? ¿Podemos definir, eh, o intentar definir entre los dos qué es y qué no es un product designer para Factorial hoy?

Sí, sí. Entrando más en detalle, la discusión que teníamos hoy, o sea, era hasta qué punto el, el product designer tiene que liderar esos esfuerzos de research o de discovery. Eh, en mi caso, eh, soy más de la opinión que el product designer no debe ser quien lidera estos esfuerzos de research.

Debe estar expuesto a ellos y debe estar en todo momento ahí presente viéndolos como fuente de información. Pero liderarlo es un proceso muy complicado. Eh, creo que un buen product designer naturalmente va a tender al sesgo de querer validar sus propias ideas. Y hay algunos que quizás tienen la habilidad particular de ser muy buenos researchers, pero por lo general los product designers son gente que tiene opiniones muy fuertes y que necesita justo estas fuentes de research para formar esas opiniones y para dar una solución, eh, que lo resuelva.

Pero, o sea, si, si me preguntas qué es lo más importante que tiene que ser un product designer, no es ser un excelente researcher, no es ser excelente en negocio, no es ser excelente programador. Es ser excelente resolviendo problemas muy complejos de maneras muy simples. Y eso en sí es un, es, es parte ciencia, parte arte, muy difícil de describir, muy difícil de enseñar y creo que la única forma de aprenderlo, mi teoría, es, eh, o al menos como yo lo he visto, son personas que, que les apasiona usar software, que les apasiona usar apps Y esto es como la música.

O sea, los músicos que, que más escuchan músicas es que la música les brota en las venas, ¿no? Los product designers que les encantan las apps, que les flipan, pues naturalmente tienen miles de referencias y cuando llegas con un problema, con poquito, a la que se asomen por la ventana, tienen un montón de referencias para resolverlo.

Ahora, entramos en detalles con Jonathan sobre problemas muy concretos de payroll, de localización y claro, necesitas mucho más contexto. Pero creo que el diseñador debe pasar más trabajo diseñando, el diseño es acción, que investigando. Y esa investigación debe ser facilitada, creo, por otras personas.

Es muy curioso, porque cuando me estabas explicando eso, estaba, estaba viendo el retrato robot de César . O sea, César-

Por eso lo quería conocer

... no es un super researcher. O sea, no, no le encanta-- sobre todo el César de antes, igual hay un nuevo César, pero no le encantaba ir ahí, an-- toda la complejidad, le aburría un poco la complejidad de, de los miles de negocios y tal. Él, una persona intuitiva, muy rápido, por poca exposición a un problema, te venía con una solución, ¿no?

No, pero la clave es que yo creo que has, has soltado dos perlas que me han encantado. Eh, una es lo del, el diseño es acción, que me la apunto cuando viene a veces, ¿no?, diseñadores demasiado académicos. Y la otra, que es, eh, construyendo sobre esto, César siempre, eh, nos estaba enseñando productos, ¿no?-

Siempre.

Diciendo...pero de cualquier cosa, ¿eh? O sea, una app de su vida privada, eh, un, un negocio financiero, un negocio de media, ¿no? Y decía: "Hostia, mira qué patrón de experiencia de usuario hay aquí. Mira qué, mira qué interacción con el multitouch, eh, han creado aquí. Mira qué..." ¿No? Y esa exposición que comentabas tú ahora, René, ¿no?, de-- el, el diseñador bueno que está obsesionado con descubrir diseños, entenderlos y luego intentar, pues imitar partes de estos diseños en casa, es lo mismo con el programador, que está todo el rato descubriendo frameworks, lenguajes de programación, herramientas y tal.

Eh, luego ha resultado clave en el hiring, ¿no? Cuando, cuando ves gente que ves que le brillan los ojos y está más rato hablándote de lo que ha hecho el fin de semana que de lo que ha hecho de lunes a viernes los últimos cinco años en una entrevista, dices: "Esta, esta persona, eh, la quiero, porque si le oriento bien, estará de lunes a domingo pensando en nuevas maneras, nuevos patrones de, de usabilidad, de interacción de usuario, de código, de lo que sea que tiene que hacer".

Has dicho una cosa clave, que esta persona el, el fin de semana normalmente hace-- está haciendo side projects. Una cosa que también hablamos mucho, ¿no? Los side projects.

Sí.

O sea, ¿cómo puede haber un developer o un product designer que no esté haciendo side projects?

Sí. Que pueden ser relacionados con el trabajo o no relacionados. A veces hay suerte. No, o sea, nosotros tenemos casos, tenemos gente, pues sí que sé que está probando una API o una, un modelo de inteligencia artificial encima de Factorial y, y si mola, pues luego nos lo cuenta y quizás lo intenta meter en el roadmap o lo está haciendo con su app de pasear perros.

Da igual, ¿no? El tema es que esté jugando constantemente.

Sí, para mí el side project es un indicador clave. De hecho, acabamos de ajustar el formulario de aplicación de product designer en, en Factorial y esa es una pregunta, porque no solo te habla de que tiene una pasión por crear apps, que es indispensable, pero creo que el, el crear side projects también te da una noción de lo que cuestan las cosas.

O sea, cuando tú estás en una empresa que levantó pasta de BC, parece que hacer cosas es como gratis, ¿no? Parece que tú quieres hacer algo y están los developers y lo haces. Cuando tienes un side project o tienes que liar a tu amigo developer pa'que lo haga en las noches, eh-

O tienes que aprender a programar.

O tienes que hacer algo no code y ahí te vas dando cuenta de lo costoso que es todo. Entonces, naturalmente, vas reduciendo el scope por necesidad, porque no tienes otra forma de hacerlo, ¿no? Entonces, esta noción como de minimalismo por, por necesidad, eh, o sea, imperativa, creo que forma una forma de pensar que, que después cuando llegas a una empresa, pues lo tienes, eh, de casa, ¿no?

Ya naturalmente piensas en, en hagamos esto de la forma más minimalista posible. Ese es el-

Uno de tus side projects es Blank Page, ¿no? Tú cuando te conocí, ¿no tenías un side project de una Blank Page?

No lo sé.

¿No tenés un blog o un generador de blog? Una-

Eso fue más adelante. Sí, ¿Cómo se llamaba lo que hacía...? El CMS. Hiciste un CMS.

Ah, sí, sí. Bueno, hiceee-

Eso fue en Factorial.

Hice Typehat.

Eso, Typehat.

Que era un CMS supersimple, eh...

Es que era muy parecido.

Porque, porque estaba-

Es un pattern este Blank Page.

Eh, est-estaba harto de los CMS complejos como WordPress y, y todos estos, y, y yo quería, pues montarme un blog, quería montarme, pues un sitio de links que me parecían interesantes, eh, y me monté un CMS que la verdad que estoy bastante, bastante orgulloso de cómo quedó.

Sí.

Ehhh, y de hecho, mmm, conseguí incluso facturar con él. Eh, lo publiqué en un sitio de estos, se llama Appsumo, eh, que es de lifetime deals, y me saqué, no sé, diez mil pavos o algo así.

Diez mil pavos.

Gente comprando lifetime deals, eh...

Que tu precio hora seguramente fue una mierda porque le echaste horas a eso.

Mmm, va, pero yo... Al final es una inversión porque también aprendí un montón. Lo-

No es una inversión, es una diversión.

Da-- pero es una inversión también en, en mis skills y mi conocimiento. Porque-

¿Sigue vivo?

Sí, sí, sí, sigue funcionando.

Porque claro, vender lifetime deals está muy bien, pero luego hay que mantenerlo.

Sí, pero fíjate que la mayoría de gente que compra lifetime deals luego nunca lo usa. Entonces, no está mal, no está mal el deal. Como para empezar y tener un peu de base, eeeh, no, no va tan mal.

¿Tú vendes lifetime deals? No, haces donaciones.

Hago... Sí, acaba-acabamos de empezar con Buy Me a Coffee Memberships y, y One Off Coffees, ¿no?

¿Y la gente paga?

Pues tenemos desde enero acá catorce members, que puedes elegir entre uno, cinco o diez dólares al mes y como ochenta y tantos, eh, coffee donors, ¿no?

Un saludo a los catorce members. Uf.

Uno de los-

Oye, están cerca de pagarnos. O sea, estamos cerca de ser rentables, ¿eh? O sea, es... es muy bonito poder pagar.

Bueno, ese es otro costo, puesto, porque el coste hora tuyo lo paga Factorial.

El coste hora se lo voy a regalar, por cierto. Está, está mecado.

Nosotros tenemos, eh... Jonathan fichó en Factorial, ¿no? a Hazim, que ha estado también aquí, se acota-- se agoladó algún día, que es el rey de los side projects también ¿No? Arrancando ahí desde cero y tal. Te da mucho contexto. Estoy de acuerdo en que te da muchísimo contexto, sino que vale un peine

Hay como factores... Deberíamos fichar gente que tenga side projects.

Claro, es, es lo que voy a decir. Hay mucha correlación entre capacidad, curiosidad, skills, etcétera, etcétera, eh, y tener side projects. Pero también es verdad que encontrar este talento es muy jodido, porque la mayoría de gente no, no hace-

Pero tenemos bastantes, ¿eh? Ca-ca-casualmente.

No, bueno, y, y me exige sense, porque además cuando te traes uno, generalmente, pues conocen a dos o tres que también t-- se van a venir, ¿sabes? Porque ven que, que es un tipo de rol que, que gusta mucho, ¿no? O que dentro de la empresa funciona muy bien. Em, pero es difícil de encontrar.

Un, un, un debate que, que yo creo que ent-- es lo que tuvisteis entre vosotros dos es que está muy bien para hacer apps relativamente superficiales o photo sharing apps, podríamos decir, ¿no? Eh, el pum, pum, pum, hago side project, aquí lo tienes.

La mitad de Internet es photo sharing apps. Claro, pero cuando tú haces una, una aplicación para tener, eh, un balance actualizado de lo que es el tiempo trabajado anual, teniendo en cuenta las leyes alemanas, de Alemania, esto, eh, claro, ahí hay una parte de research importantísima, ¿no?

Eh, entonces, ¿quién hace el research en esos, en estos casos, no? Es un poco el, el dilema que tenemos en algunos dominios de Factorial que tienen mucha profundidad.

Uy, Alba, hemos introducido un nuevo altavoz.

Yo muy poco. O sea, desde que he entrado he hablado con dos clientes, así que…

Cuarenta.

Por eso la, la relación con CX también es muy importante.

Claro, ¿no?, que es la, la parte que falta. O sea, porque el, el product manager puede hablar con algún cliente.

Pero luego hay muchos clientes.

Y cada uno tiene sus historias.

Pero no puede estar todo el mundo hablando con clientes. Alguien tiene que estar produciendo también.

No, sí, distintas frecuencias. Sí que se pueden hacer. Y, o sea, para mí hablar con clientes es como de un check de realidad.

¿Sabes? Y, y cuando tú estás en la cueva picando código todo el día durante meses y meses y meses y no te has enfrentado a esa realidad que es la persona que va a usar tu software...

Pero tienes una realidad que es el account manager soplándote detrás de la oreja.

No, pero es que tú, o sea, esto te ha cambiado, tu visión te ha cambia-- pero tú estás, tú eres muy de cueva.

Sí, pero ya sabes que yo, yo soy de opiniones fuertes, pero...

Pero idlas cambiando cada semana. No, pero tú eres muy de cueva, ¿no? Yo, yo, yo creo que en general el perfil product designer e ingeniero son perfiles introvertidos. No son, no son gente de, de estar siempre fuera, ta, ta, ¿no? Son gente más de cueva.

No, total. Y, pero hay formas de, de hacer esto. Puedes grabar las llamadas, eh, y que luego, pues la, la mayoría de interac-- no interacción, sino la mayoría de input de cliente, pues venga de ahí. Pero el hacer el, el reality check, el mirar a la cara ese efecto dice-

Sí, pero el account manager también puede generar empatía. O sea, hay una cosa peligrosa con esto que nos pasaba, me acuerdo, en los primeros días de Factorial, y seguro que nos pasa ahora también, que un día te arrastraba a ti y a Pau de la cueva a ver a un cliente y lo que fuera que decía ese cliente iba a misa

Sí.

Pero la gracia tuya, Jordi, aquí era llevarlos al cliente correcto.

Te la juegas, pero, pero eso es toda la gente que está aquí escuchándonos. O sea, todo el mundo está hablando con clientes. Yo cada vez le, le, le cojo un poco de rabia esto de que: "Eh, que he hablado con muchos clientes". So what?

¿Sabes? ¿Y qué has hecho en esa conversación? ¿Y qué ha pasado ahí? ¿Sabes? O sea, el hecho de hablar con clientes no correlaciona con encontrar la solución. Eh... Al final nunca será representativo.

Es entender el problema.

¿Y qué problema quieres resolver? Porque hay muchos a resolver, ¿no?

Mi pregunta es-

Crees que esto no es una función que tiene que hacer el diseñador, no es una skill que tiene que tener un diseñador. El decir que no a los bias es el darse cuenta de cuáles son, el entender cuál es la motivación real de la persona que quiere resolver algo.

Y el PM. O sea, lo que tú hacías llevándolos a este cliente estaba haciendo el rol de PM, porque estabas diciendo: Esto es representativo.

Era muy importante dónde los llevabas en aquel momento. En qué reunión.

Es-esto sí que l-l-lo escuché antes y, y quiero hacer doble, eh, doble clic, como dicen ahora. Em, ¿qué significa el designer tiene que estar diseñando? ¿Qué significa diseñar?

Claro, pero es que fíjate, yo con el tiempo, eh, me he dado cuenta de que soy mucho más exitoso cuando mi proceso de diseño es ochenta por ciento, eh, entender, pensar, conseguir más inputs, etcétera, etcétera. Y el veinte por ciento, implementar la solución que ya he pensado de primeras, em, y probarla con el cliente.

Eso es.

Ya no es el cien por cien del tiempo diseñadoando, entre comillas, ¿no? Eh, porque la parte de los inputs para mí es diseñar. Para mí, el entender la motivación del cliente, el entender los problemas que tiene, entender e-el producto actual...

Lo que es interesante es la gente que-- los diseñadores que piensan diseñando. A mí eso me fascina, ¿eh? O sea, van sacando exploraciones pum, pum, pum, ¿no? Y van viendo la reacción en la gente. Esto a mí me fascina.

Claro.

Estoy cien por cien alineado con eso.

Tengo trastorno de estrés postraumático. He dicho "payroll" y me han entrado calores.

O sea, eh, cuando digo de d-d-diseño en esa acción, me refiero a todos estos edge cases que surgen, es que te los encuentras diseñando. Tú puedes haber hablado lo que quieras con un cliente y tenerlo clarísimo y entiendes su problema, pero hasta que no sacaste una primera versión del diseño y lo empiezas a jugar con un prototipo, te empiezan a salir montón de lugares donde se rompe.

Entonces, tie--o sea, ahí es donde me refiero. Tiene que estar diseñado pa' encontrar esas cosas. Quizás ahí vale la pena volver al cliente, volver a tener input de alguien más, pero después volver a diseñar. O sea, es este proceso de iteración constante. No me refiero a que estén todo el día en Figma dándole vueltas a sus propias ideas, no. O sea... Pero cre--eh, o sea, como lo de la frase que es: "La inspiración debe encontrar trabajando", pues la solución te vas a encontrar diseñando.

Eso no sirve para nada. Yo desconfío mucho de, de cuando un diseñador está repitiendo discovery y validación, y discovery y validación, y discovery... Empiezo a dudar. O sea, ¿dónde está tu talento para resolver el problema? Estas palabras a mí me, me crean ruido, la verdad. O sea, prefiero que me enseñe cosas y me diga: "Esto no me encaja porque algo me falta, más input, me falta..." Pero es que me falta más validación, me faltan más disco.

O sea, no, me mata.

Y, y tiene que ver ya con la propia metodología de desarrollo de producto. Eh, cuando volvemos a estos discoverys infinitos, ahí no hay iteración. Ahí, ahí hay un riesgo brutal, porque estás construyendo algo que va, va a ver la luz en X tiempo, has perdido un mes, el cliente no, no, no le va a funcionar, vuelve al discovery.

O sea, yo creo toda la gente que es capaz de construir cosas rápidas y sacarlo, sacarlo y, y, y ver cómo funciona, es la gente que tiene éxito, ¿eh? En producto.

¿Quién hace el copy? Esa es una buena.

Joé, yo pensaba que teníamos que cambiar de tema ya y...

Que la traducción siempre es un problema, ¿no?

O sea, ahí, ahí te hará falta alguien. Pero, o sea, en general, lo que s--lo que siempre acabamos convirgiendo es: cuanto más generalistas sean los perfiles, mejor. Gente del renacimiento, oye, que programe, diseña y toque violín.

Sí, pero lo, lo de escribir, eh, es básico, ¿eh? O sea, habilidad número uno pa'mí de un product designer es increíble escribiendo. Tanto describiendo su solución antes de siquiera hacer un wireframe, como escribiendo los copies y los labels. Al final, tú ves una interface, más de la mitad de los elementos son--es texto.

Entonces, esta idea de que el diseñador, eh, hace un layout y después se lo pasa a un UX, eh, content writer o lo que sea, me, me, me mata. O sea, tiene que ser el propio diseñador el que tiene la opinión más fuerte sobre las palabras exactas que usar. Y después, sí, claro, darle consistencia, traducción, lo que tú quieras involucrar al especialista.

Venga, pregunta para desnudarnos un poco: ¿cuál creéis que es nuestro principal reto de diseño en Factorial?

Vale, pues está clarísimo. O sea, eh, bueno, yo llevo dos meses, pero conozco que los últimos años Factorial creció muy rápido. Abrió muchísima superficie para resolver muchos problemas, pero esta superficie la tuvo que abrir rápido y sin miras a que todo fuera una experiencia consistente.

Entonces, el reto número uno importantísimo que tenemos ahora es unificar esta experiencia y encontrar una única forma de hacer las cosas en Factorial, en cualquier producto, que quizás es un poco naíf que lo podamos llegar al cien por ciento, pero sí que creo que podemos lograr un ochenta/veinte, donde el ochenta por ciento de las cosas se hacen igual y donde no buscamos que cada diseño sea una obra de arte en sí, sino que sea igual de consistente que el otro.

Em, o sea, que es un, un reto enorme y para el cual estamos buscando product designers excelentes y que tengan esta mentalidad de, de diseño de producto como una forma de, de lograr consistencia y no tanto como de lograr cosas que, eh, capantallen o que se vean muy bien, ¿no? O sea, de, de llegar a esta unidad

Para mí, no sé

Yo, yo diría justamente que en Factorial hablamos mucho de un-- del concepto de abstracción. De cómo muchos problemas granulares terminan en una única solución que, que permite, eh, ser una experiencia intuitiva, justamente, ¿no? Eh, el problema, ¿no?, el gran reto que tenemos ahora es cuando creas un producto tan grande, el volumen de abstracciones ya no es pocas, ¿no?

Ya, ya nos dejan-- ya no son abstracciones, ya es otra cosa. Eh, y ahora tenemos ese reto de cómo abstraemos la abstracción en u-en un paso más allá.

Muy bien, hoy llegando a la abstracción ul-ult-última, nos hemos dejado la lista entera de temas que teníamos hoy, eh, que han pasado esta semana, ¿eh? Tenemos, eh, el BAN de TikTok, eh, Devin AI. ¿Queréis hablar de algo, de esto? ¿O pasamos al Q&A?

Eh, bueno, puedo comentar-

Stripe annual letter

Devin. Devin, Devin es, es bastante impresionante. Creo que merece la pena, por si alguien no lo conoce, comentarlo junto con César.

Em, vale. Eh, bueno, esta semana han anunciado, eh, un nuevo producto que está en early access. O sea, no, no se puede usar aún.

Beta privada, ¿no?

Hay una... Sí, hay una, hay una lista de espera. Estoy apuntado, ya os avisaré cuando, cuando entre. Em, pero básicamente, lo que, lo que proponen es, eh, esta plataforma que se llama Devin, que es un developer AI, ¿vale? Em, que no es un developer tipo, pues Copilot, que te ayuda a escribir código, sino que realmente es un LLM, o sea, un Large Language Model-

Es un agente.

Em, sí, que-- con comportamiento agéntico. Es decir, que tiene, eh, capacidad de hacer una serie de funciones, ¿vale? Entonces, tú le dices un prompt de lo que quieres construir, ¿no? Quieres construir una feature en tu producto, quieres construir un producto entero, em, cosas de este tipo. Y lo que hace es, eh, dispara varios agentes que hacen, eh, en un proceso multipaso, estoy traduciendo en mi cabeza en tiempo real, eh, un proceso multipaso, em, donde, pues, por ejemplo, se va a Google y busca, eh, pues la API del producto que estás intentando utilizar, eh, y la mete toda en el contexto para poder utilizarla después.

Se hace un plan de implementación del software que le, que le has pedido, de la aplicación que le has pedido. Em, y vas viendo como poco a poco va construyendo todas estas piezas de contexto que acaban resultando en el producto final construido, ¿vale? Y no solo eso, sino que además, pues si le falla, eh, una, un código que ha generado, eh, es capaz de detectar el fallo, utilizarlo como parte del контекsto y lo arregla también.

Y te lo, te lo va enseñando todo en tiempo real. Los vídeos la verdad que son bastante, bastante impresionantes. Me ha hecho gracia porque en Twitter hemos empezado a ver algunos developers que, que se nota que, que tienen un poco de miedo. Eh, y además, de hecho, alguna gente que decía: "Ah, los artistas que, que no se están uniendo a, a, em, la IA generativa y tal, porque tienen miedo de perder su trabajo y tal".

Pues estos mismos ahora están diciendo: "No, pero esto nunca va a sustituir un developer, eh, siempre necesitarás tal y cual", mmm-

Y el resto del mundo diciendo: "Los developers nos habéis substituido a todo el mundo hasta ahora."

Os vais a cagar .

Ya os toca.

Oye, es muy chula la demo, porque hay una cosa que no has comentado, pero yo creo que es muy visual. La pantalla está... O sea, tú lo que ves, ¿no? Hay vídeos, no se puede probar si no te dan acceso, pero hay muchos vídeos. Tú ves una pantalla dividida en cuatro, donde arriba a la izquierda tienes el prompt, que es donde tú hablas con este agente, ¿no? Con este developer que se llama Devin.

Arriba a la derecha tienes el editor de código, donde tú vas viendo los ficheros de código que van apareciendo y tal. Abajo a la derecha tienes, eh, la terminal, ¿no? O sea, un desarrollador normalmente tiene una terminal, una consola donde ejecuta el código, ¿no? Arranca el servidor, tira los tests y cosas así. Y abajo a la izquierda tiene el navegador.

En caso de que estés haciendo algo que sea web, que es gran parte del desarrollo que hay hoy en día, vas viendo los resultados. Y, y ves, ¿no? Escribes una frase, dos frases en el prompt, ves el código, ves cómo se ejecuta, sale un error, vuelve al código, lo edita, va al navegador, busca documentación, vuelve al código, lo edita, ejecuta, funciona, va al navegador.

Es increíble.

Sí.

Es pair programming, ¿no? O sea, es estar como con otra persona programando, ¡pero no hay otra persona! Es una máquina. Y realmente hay varios ejemplos, que me lo he apuntado antes, que, que son bastante chulos, que me han gustado, de, de cosas que no sabes si está un poco trucado o no, ¿eh? Porque son vídeos grabados. O sea, que es difícil, eh-

Tiene pinta de que está bastante trucado.

Es, es difícil saberlo, esto. Em, pero por ejemplo, uno me ha gustado mucho porque pilla el enlace de, de un blog post donde alguien generaba unas imágenes de esas muy chulas, no sé si habéis visto usando, eh, inteligencia artificial generativa, que puedes hacer la imagen de unos rascacielos donde en realidad las sombras hacen el logo de Factorial, por ejemplo, ¿no?

Pues había un blog post que explicaba cómo hacer esto.

Mmm, sí.

Y, y el prompt era: Este es el blog post, quiero hacer esta palabra, ejécutamelo todo, ¿no? Bájate las librerías, haz varios test, no sé qué, y funciona. Otro que es: aquí tienes un superrepositorio y un proyecto open source tochísimo, arregla este bug. Y lo hace. Y otro que es, va a Upwork, que no sé si conocéis, pero es una plataforma para contratar freelancers, donde nuevamente el cliente pone una tarea, ¿no?

Y una tarea podría ser, por ejemplo, ¿no?: Quiero un scraper, ¿no? Un código que se chupe todos los contactos de LinkedIn y me encuentre no sé qué y ta. Pues le manda el enlace a Upwork y dice: Hazme esta tarea. Y lo hace.

Y cobra por ella.

Y cobra, y cobra.

No sé-

Sí, sí, sí, yo, yo lo leo que cobra.

Ah, bueno, en el, en el caso del ejemplo sí. No sabía.

Y de hecho, para dar-

Aquí es donde se empieza a acojonar la gente. El momento que cobra.

Porque claro, eh, pones ahí cien euros de GPUs y va trabajando, ¿no?

Em, para dar algún dato, eh, que, que ha sacado la empresa esta, em, han hecho pruebas con, em, issues de GitHub Eh, o sea los proyectos open source que están en GitHub pues te-tienen una sección de issues. Que es básicamente los bugs y features nuevas que eh, quieren añadir al proyecto ¿no?

Em, y han dado el dato de que Devin es capaz de resolver eh, de todas las que han dado un 13,7 %, si no me equivoco, em, de issues que a priori no parece muy impresionante un trece por ciento tampoco... O sea no van a dejar a muchos developers sin trabajo.

Bueno no sé cuántos developers pueden solucionar más del trece por cien también .

Pero es interesante la comparación con los modelos existentes porque tienes a Claude tres que me parece que es un cua-- tres cuatro por ciento. Tienes a GPT4 con un uno coma ocho por ciento algo así. Me estoy inventando números pero estamos así. Sí Es un orden de magnitud correcto Y esto es el principio esta gente empezó la empresa hace unos meses.

Es una startup que se llama Cognition sí Eh Que ha levantado veintiún millones de dólares de Founders Fund y como curiosidad.

Que es Peter Thiel. El fondo de Peter Thiel. Peter Thiel es el promotor de Founders Funds sí Yyy me hace mucha gracia porque siempre destaca que los fundadores han ganado diez medallas de oro de las olimpiadas de informática Como gran.

Y eso es una locura porque puedes ver salió un vídeo también del founder hace quince años. Picando ahí hackeando en una competición de estas frikis de toda vida . Es muy impresionante recomiendo buscarlo se llama por si os habéis olvidado Devin D E V I N No sé si tenéis alguna opinión sobre eso Está apagado Lo que me llamó la atención es que es como un primer caso de hacerle un bundle a ChatGPT ¿No?

O sea como que hay esta idea de que eh, los large language models pueden terminar en algo como supergeneralista que te resuelven cualquier cosa o en algo muy específico que te hacen una tarea en concreto Creo que aquí es un primer caso de un unbundle que lo personificaron eh, en un programador que te resuelve tareas ¿no?

Y eso me pareció que fue lo brillante de ellos que te dicen como: Si quieres contratar a Devin llena este form O sea puedo ver que ahora van a empezar a salir más casos de unbundle de si te gusta escribir Pues tienes un editor que tiene un training set de un montón de novelas o de ensayos y lo contratas para que te edite un libro Si te gusta yo qué sé dirigir películas habrá Este caso del unbundle me parece pionero y creo que va a haber más.

Sí Esto yo creo que es donde OpenAI ha pinchado un poco la verdad Porque sí que sacaron los Los gpt. Los gpts Gpts Em que iban un poco por esta dirección dónde podías promptearlos configurarlos tal Pero es una capa por encima muy sencilla. Es que al final necesitas un UI como decías Para ser un developer necesitar la consola para ser un editor de libros Necesitarás un algo que te highlight sustantivos verbos Al final necesitas UI adhoc Hablando de abstraccionesCreo que se van a editar cosas ad hoc ¿Cuántos GPTS habéis usado que no sea chatgpt punto com desde que salió el app store hace unos meses Cero.

Cero He probado un par y fail total Yo sí que hice alguno pero dejé de usarlos Creaste más que usaste Bueno DallE está puesto como un GPT No pero no cuela Te lo muestran ahí como unen teoría es uno más

Si no parece queno vaya a tirarOjalá Oye teníamos muchos temaspero los dejamos para semana que viene Vamos Antes de las preguntasYo quieroMe hace mucha ilusiónme he traído un regalo Un oyente clásicoque normalmente nos escuchaDesde Suiza¿no Por ynos comenta en YouTubesanamente locoNo sé sipodéis enfocarestoLos queestáis aquíen el públicoLuego ose acercáis amirarlo Peroes unataza quetiene la imagenperdona ladejo aquíquietavalePorque sino novais apoder enfocarque tienela imagende ese memedel perroen llamasQuese estáfundiendoPero enlugar deperro enllamashay unseñorcon barbaQue interpretoque esunacaricatura

míaQue poneThis is fineTodo estabien ques unpoco lametafóradelas startupso delemprededorDe estar todoen llamascaótico ymemehace muchailusióny ademásestapersonizadapone my dailylife at FactorialsíUn díaen Factorialyhayuna pequeñataza deFactorialahí enel backgroundAsí quemuchasgraciasSanamentelocome hacemuchailusiónEstá hechaCon AI Con AILa imagen ConDallE Eso nolo sabía Muy finaMuy meta Usosenproducciónya DeinteligenciaartificialEsto seva parapara casa nose queda ena oficinaMuy bienoye vamos ala Tenésmás regalosno Ja ja jase próximo

díano

Yo a Product DesignnoA Customer Experience síEstamos teniendoun crecimientobastante buenoy mi pregunta escómo seescalasanamenteunequipo deCustomerExperienceOseaqué estrategia sepuede usarpara escalarunequipode customer experience quenose acontratarmás genteeeh Es unabuenaprgunta TenemosaquíagenteagentedecustomerexperienceEm averyo creoque o seasdifícilplantarescalar unequipode go to market singenteee O seaalfinaligualainteligencia artificialsustituiratodo ehtambién dependedequétipode customerexperienciessimás consultantesmásaorientadaconsultoríaques lo que hacemosenlas empresadesoftwareSaaS

BTobo es máspurosoportede BTCqueehes probablementemásautomatizableHay muchascapasde automatizacióncon chatbotsetcéteranoEn nuestrocasoen factorialhemos escaladocon personasIgualcomo enventash hemosescaladoconomvendedoresSí queal mejorarlos win ratela eficienciael ratiovendedoreurosvendidosva mejorandoEen elcaso decustomerexperiencenosotrosescalamosconpersonasyla cuestiónsiempreescual estamañode lacarteraidoneo Es decir, cuántas, cuántas cuentas tiene que

llevar, eh, cada persona y en función de qué, ¿no? Cuál es la complejidad del cliente, ¿no?, cómo se reparten la complejidad entre los distento-- los distintos reps, ¿no? Eh, pero no-- ahí no hay magia, ¿eh? O sea, no hay nada fuera del otro mundo, ¿eh? O sea... Y, y en el caso de software esto nunca es un problema en general, es más un problema en ventas que en customer experience, porque el margen es muy alto.

O sea, generalmente un benchmark clásico es que el quince por ciento del revenue se invierte en el propio servicio al cliente de software, ¿vale? Eh, entonces, eh, esto es un benchmark que te puede servir o no-

Sí.

Depende del modelo, depende de mil cosas, pero este es el benchmark que utilizamos.

O sea, yo voy a decir que hay una cosa que es, es muy fácil, eeeh, a diferencia de en ventas, ¿no? En ventas cuándo escalar no es nada obvio.

Nada.

Eh, se puede escalar demasiado temprano y quemar pasta y frustrar a todo elmundo, o demasiado tarde y que te pille el toro, ¿no? Y que te gane el competidor. Es, es-

Hay riesgo y hay saltos, funciona por saltos.

Exacto. Pero en cambio en experiencia de, de cliente, customer success, customer experience, como lo quieras llamar, pues te van llegando los clientes, te vas saturando y vas es-- contratando, ¿sabes? O sea, es a posteriori. Y al principio, pues el primer customer support, pues es el equipo. O sea, me acuerdo al principio, pues era yo, cuando yo no podía me echaban un cable, pues los que estamos en el equipo, no sé qué.

Luego el de marketing, te dabas cuenta, el que estaba haciendo más tickets que blog posts, empezabas a contratar a una persona solo para hacer support tal. Quiero decir que no es muy complicado saber cuándo hay que escalarlo, porque a medida que te van entrando clientes y te va entrando volumen, y cuando ya petas, pues vas, vas creciendo el equipo. Eh, nosotros no hemos usado mucho AI hasta, hasta ahora.

Eh, si podemos usar AI para hacer más eficientes a los equipos y dar mejor soporte, pues mejor que mejor, ¿no? Pero que en general, en una empresa de software, si es B2B, tal, son habas contadas.

Pasa el micro, pasa el micro.

Si es depende del momento, no hay que escalar nada, ¿eh? Seguramente. O sea, tiene que ya estar bastante claro antes de escalar.

Pero corto plazo, el por-- ah, el corto plazo es muy putada, ¿eh? En, en customer experience, porque-- y eso es lo que estarán pensando la gente que nos está escuchando detrás de customer experience,porque a veces, pues cuando Ventas tiene buenas noticias, está celebrando, en el, en las mesas de al lado normalmente se están poniendo las manos en la cabeza. Tienes un buen mes, esto a corto plazo es un problema de onboarding, es un problema de saturación.

Sobre todo si el producto no va, que en, en las primeras etapas acostumbra ser el caso.

Claro, cuando estás empezando el onboarding puede ser más o menos crítico, pero sí que hay que ir acompasando, ¿no? Cuando va creciendo la demanda, cuando vayan entrando más clientes, ir contratando más customer experience y acabar aplanando esas curvas. Pero sí que a corto plazo es un pain, ¿eh? Sin duda.

Venga, más preguntas. Por aquí hay una. A ver. ¿Queréis una cerveza? Sí. Sí, una pa-- una para cada uno. Mira, ¿eh?

Vale, eh, a ver, onboarding... Bueno, es un tema muy general dependiendo del tipo de producto que tengas, pero lo que he visto que funciona o personalmente me gusta son estos onboardings que te van preguntando un poco qué quieres antes de empezar el onboarding, ¿no? Como para qué vas a usar el producto, cuál es tu expectativa y de ahí puede que tengas varios flujos según la elección del usuario, ¿no?

Em, claro, depende totalmente del producto, ¿eh? Pero...

Que haga una primera acción antes de-

Cien por cien. O sea, lo que pueda hacer antes de tener que hacer un login, eh, permítelo.

O sea, los logins son la muerte, o sea...

Yo los odio .

Sí, em, yo por, por ser un poco contrarian, em, hay una pregunta que mucha gente no se hace cuando se pone a diseñar un, un onboarding y es: ¿necesito que el produto haga el onboarding? Y luego: ¿puedo conseguir que el producto haga el onboarding? ¿Por qué? Porque cu-- te pones en la práctica y ves muchos casos y, y pruebas muchos softwares.

Em, nosotros estamos muy acostumbrados como pues diseñadores, developers, eh, ge-gente que monta productos de, para startups, em, a ser muy autosuficientes, ¿no? Probamos muchas cosas, pues hacemos nuestro research, no queremos hablar con nadie, em, y nos buscamos nuestras propias habas. Em, pero la realidad es que la mayoría de gente no es así.

Y entonces depende mucho de la industria en la que estés, del producto, eh, que, que estás intentando vender, de cuál es tu estrategia de captación, de conversión, etcétera, etcétera. Porque hay muchas industrias donde directamente no puedes, eh, pensar que con un producto que hagas self-onboarding vas a conseguir cerrar clientes.

Em, y hostias, yo la, la verdad que después de haber estado en Factorial, aquí me, me cambió bastante la visión, porque yo también era muy, muy de pensar: bueno, yo es que, o sea, para usar un producto no quiero hablar con nadie, no quiero que venga aquí nadie a venderme la moto ni, ni yo tener que salir de la cueva, ¿sabes? Em, pero la realidad es que luego te pu-- te pones a ver el productoy te das cuenta del problema de la gente y, y que eres su última preocupación cuando está probando el software, em, y dices: Hostia, pues igual le chapo el onboarding y, y le meto alguna llamada.

Hace poco, eh, por si quieres referencias, los de Equals, eh, me parece que fueron, eh, escribieron un blog post donde explicaban que... Igual es una plataforma que es, eh, como una alternativa Excel, pero en, en la nube, ¿vale? En, en una web. Em, y explicaban la curva de crecimiento y cómo se había parado o estaba completamente flat mientras tenían el, el onboarding, auto-onboarding, o sea, que, que la gente podía hacerlo.

Em, lo chaparon, obligaban a todo el mundo a ir a una llamada y la curva de crecimiento empezó a hacer así. Em, y esto es un producto que en principio se presta mucho a, a que el propio producto te haga el onboarding. Em, entonces, pruébalo, pero sobre todo sé muy consciente de el tipo de cliente que tienes, porque si no es un developer o un product designer, hacer un producto que te haga el onboarding solo, eh, es jodido que funcione.

Eh, nosotros mismos incluso hemos probado onboardings distintos tipos y nosotros vamos a gente técnica, gente de datos, gente que está acostumbrada a probar productos nuevos, etcétera, etcétera. Y tío, es que no, no levantamos la activación por encima del cincuenta por ciento. O sea, no...

Hay más ejemplos, ¿no? Del, de esto que decías tú. Por ejemplo, Superhuman, eh, también famosamente hacía una llamada de cuarenta y cinco minutos para, para hacer el onboarding y ahí garantizaban, eh, que ese usuario no estaba solo jugando, ¿no? Había un punto de fricción buena- ...de un compromiso de tiempo y tal.

Y luego que hay un momento guau, cuando ves y entiendes algo, realmente usas muy bien el producto. Y de hecho hay, hay varios otros ejemplos que les comento rápido, porque es que justo hoy de casualidad, dónde estás, ahí, une de nuestras participadas, eh, nos preguntaba lo mismo, ¿no? Es decir, oye, empiezo a tener muchos onboardings. ¿Qué hago? ¿Hago blog posts y videos, contrato a gente o lo hago yo, fundador, no?

Y precisamente decía, ¿no? Pues Stripe, famosamente, los hermanos Collison iban a la casa de los primeros muchos clientes a hacer la integración para asegurarse que empezaba la caja a hacer cachín y ahí luego ya lo soltaban y veían que seguía funcionando. Y al cabo de bastante tiempo empezaron a documentarlo y a hacerlo hiperescalable. O sea, fueron del extremo founder a API.

O sea, eh, se saltaron el de enmedio, ¿no? superhuman, que como hemos dicho ahora, hacía el onboarding con un equipo de customer success y tal. Yo, por ejemplo, a este fundador le decía: Oye, no, no hagas vídeos ni nada. O sea, de momento te está dando un input valiosísimo a meterte en casa del cliente. Digo: Empieza a contratar poco a poco.

O sea, no seas solo tú, porque eres un cuello de botella, tienes que estar haciendo otras cosas como ventas o quizá levantar pasta o lo que sea. Pero, pero aprovecha también este input que te dan los clientes durante el onboarding. O sea, no, yo creo que no hay que tener prisa en hacer esto hiperescalable. De nuevo, como decíamos antes, hasta que no te das cuenta de que no llegas. Entonces, ahí sí que no hay más remedio.

Y, y ya por último, creo que una reflexión que justo, justo estaba pensando ahora, dependes mucho del intent que tenga tu usuario, o sea, la intencionalidad que tengay la necesidad que tenga de tu producto. Es muy raro que tu producto, que es nuevo en el mercado, es nuevo en la, en la mente de esta persona, se convierta en su máxima prioridad.

Ahora, si es su máxima prioridad porque ve que le resuelves su mayor problema, ahí sí que tiene un intent muy alto y sí que quizás si es un poco techie, es capaz de hacer un onboarding y entrar por su cuenta y para adelante, ¿no? Em, pero me atrevería a decir que la mayoría de productos que hay en el mercado, eh, es difícil que sean la máxima prioridad en la cabeza de sus clientes cuando llegan a la web Es difícil.

Ehm, pero por eso, o sea, decide primero si, si necesitas un onboarding o si te da más valor como dice Jordi el, el empezar a hacerlo a mano porque vas a, mmm, capturar más datos, vas a generar más intent porque vas a hacer un proceso de venta realmente, ehm, y te vas a asegurarte que la persona...

Primero tú has entendido el problema que tiene y segundo ha-- la persona entiende cómo resolverlo con tu producto, eh, que esto es lo más jodido de hacer con, con onboarding, eeeh, con self-onboarding.

Vale.

Pues nada muchas gracias.

Vamos a otra pregunta. Intentemos hacer respuestas un poco más cortas igual, porque si no, no habrá fas-- más preguntas. ¿Quién más?

Vamos, si no entonces largas, ¿eh?

Enrollo más.

¿No serás Jorge AM?

¿No eres, no eres jorge AM, no?

Ah vale. Porque hay alguien en Bali que nos sigue que se llama Jorge AM.

Está en Tailandia Jorge.

Ah Es verdad era Tailandia nada.

Porque nos comente por aquí.

Venga quién dispara.

Voy. Ehm, bueno yo ahora tengo la suerte de que, de que he vuelto al craft. Eh sí que en, en mi última etapa en Factorial pues ya apenas tocaba, tocaba el Figma. Ehm, perooo, pero sí que hay un comentario que, que muchas veces escucho Bernat, ehm, que es que laaa, la persona que está en, en haciendo la, la parte de la gestión, ¿no?

Hay una cosa muy importante que tiene que hacer y es ser capaz de entrar hasta el último detalle, eh cuando toca y el decir cuando toca, ¿no? Ehm y yo creo que en esos momentos es dondeeee yyy yo me acuerdo en factorial ya te digo cuando era director de producto o VP Product em había momentos en que me tenía que meter hasta, hasta el fondo de, de las cosas.

Em y sentarme con pues una diseñadora sentarme con una developer y decir hostia Vale, eh ¿Cómo, cómo montamos esto? Y nos ponemos una pizarra en blanco y venga va a pintar tal esquema arquitectura tal. Eh y esto lo disfrutaba un montón. Em Pero no solo disfruto un montón sino que además tenía mucho valor porque no solo aportaba pues la parte de la visión estrategia construir el equipo y tal Sino que además entraba en algunos proyectos donde donde era clave eh y me quitaba eeesta esta espinita ¿no?

Que tenia em Yo yo creo que es muy importanteee que un manager sea capaz de hacer esto Eeeh Y de hecho es que pasará naturalmente si el manager aprecia el craft como como dices.

Mi Side Project es Un podcast un Fondo de inversión No osea Eh no no hay Tiempo para Side Projects em Yo-

Pero Programar programar.

Yo Sí Que Echo De Menos Programar no Programo Cero Ahora Mismo Hace Tiempo Que Cero cero y Lo echo De Menos y De Hecho algún Día que pienso Hostia Si un día soy Mayor Ya y no Tengo energía y Tal eeeh Qué Haré No y La Verdad es Que no Tengo Ni idea Si ese Día Llegará y Qué pinta Tendrá pero Me Imagino Recuperar la programaciónporque es osea Realmente-

Cuando Devin AI Sea Todo Te pondrás A Programar.

PuesSí yo Qué Sé pero Por placer.

Los Artesanos ¿no? Del Código.

PeroPor Placer porque Es un Construir Es Una Habilidad No a mí Me Encanta Programares construir.

Es Precioso Es Como Para un Escritor Escribiro Para un PintorpintarEh ParaMí EraProgramaryLoHechoDe Menosy No AbroUn EditordeCódigodesdeHacetiempo y LoEchoDemenosperoEsQueOsea CuandoTienesunRolderresponsabilidadycreoque LosSideProjectsquedecíamosAntesestámuybienen teoría Perola prácticacuandola empiezacua ndolagenteempieza atenerrolesdemanagementyaSeacaba.

Bueno Toby Lutkeel CEO de Shopify Sigueprogramando eh.

Si Pero En Shopify.

y Las Hermanas Colison También Stripe.

PeroEnShopifynocomoSideProjectloque Se Acaban SonlossideprojectsquieroDecir.

Ma Es Que El Tema escuandoEstásaEnUnaEmpresadondehaytantatantaactividadentantosámbitostúpuedescasiElegirelsideprojectquequieras nooseahaymilside projectsahínoY creoquehayunpuntoimportantedeloque DecíaCésardebajaraldetalleESNohacefaltaqueseanlosproyectosclaveporquesi túbajasalosproyectoclaveparecequetúno confíesentuEquipo no.

Clavenosinificanecesariamenticlaveparalaempresasinoclaveel hechode quetuTeMetasenese proyecto.

A no EsoSíesoAsíoseso AsíoseaAlfinalesenEste ejemplocasialeatoriodondetúvas abajarVasAbajarlasabajoñoyte vasaMeterdondetúPrimerodisfrutassi tegustaalcraftnoamímencantano noprogramoperoigualsíquetengodiscusiones sobrebasesdedatossobre nosecosasenfoquesdetecnologíaque estamos Haciendosoluciones deexperiencia deusuario amíEso me encantaPorunlado Melo PasobienLuego eneste discusiónmepermitealinearmeconlaspartesyypensarjuntosyenesepensarjuntosSalenmuchascosasdesdelosvalores dela empresahastaporquéEstamosaquíaslaestrategiano puedespueshablar demuchaspcasen estadiscusióndeldetalenoyluegoHostiaparaunmanagereslahostiapodercambiar

decontextoyvertantascosasdiferentesyttrabajarcon gentecontantoTalentoatu alrededor O sea, para mí yo pienso a veces que soy tan afortunado. Tengo gente que stop pensando conjuntamente conmigo. Entonces digo: "Hostia, esto es la hostia", ¿sabes?Entonces sí, es verdad, echo de menos cuando estaba yo solo en mi casa en calzoncillos programando, pero esto es mucho mejor para mí, ¿eh?

De hecho, yo me, me acuerdo que tuve una época en los primeros años de Factorial donde a veces me daba cuenta de que me ponía a programar algo de factorial que no era a priori de top-- Era típico de arreglar el backoffice. Me ponía a arreglar alguna cosa que me molestaba-

Oye pues tenemos, tenemos cosas para ti.

Ya, ya, ya,no,pero me di cuenta de que era mi manera de procrastinar. O sea, a veces tenía un marrón... Claro,yo, yo se me daba bien la programación,¿no? Y es una cosa que, que la veía fácil y a veces, pues había que cerrar un cliente o había que, yo qué sé, conseguir pasta o solucionar un problema que quizá no tenía tan por la mano. Y me,me escondía en la programación que era mi craft y un poco me prohibí hacer eso porque me--para mí era procrastinar.

Era estás dedicándote-

Yo pensé te lo había pedido Pau.

¿Tú eres programador?

Luego hablamos. ¿Eres contrarián?

Tienes todos los checks, ¿eh?

¿Tú ibas decir algo? No. Ah, vale. Bueno, pues oye, vamos al, al pitch. Eh, hoy tenemos dos pitches. Francesc.

No tenemos cubo, eh, hoy. Pero bueno

Muy bien.

Empiezo yo. Si puedes, superbreve. No he entendido lo que hacéis.

¿Puedes explicarlo muy simple, muy simple, con muy pocas palabras?

¿Qué es un bundle?. No. Más simple, más simple.

Agregáis productos digitales.

O sea, compras de golpe varias cosas.

Y es un descuento.

¿Cuánto más barato?

¿Y Netflix por qué quiere meter su Netflix a un megabundle?

¿Qué significa economías de escala en los megabundles?

Bueno, nos abras.

O sea, gente que no se puede permitir los diez euros del Netflix.

¿En qué momento estáis?

¿Has hablado con usuarios o proveedores?

Cuando dices que dis-distribuirlo es muy barato estás obviando una parte muy importante en los software de suscripción o negocios de suscripción que es el coste adquisición de cliente Sí O sea tú estás pensando que ya tienes al cliente distribuir la película es barato sí Pero lo caro es conseguir el cliente y amortizar este coste en el lifetime value del cliente Exacto Ahí está el modelo

Se ha acabado el tiempo

Vamos Vamos al feedback empiezo yo mismo Modelos de grupos de compras en grupos y tal hay muchos hay Muy pocos que hayan funcionado Es muy difícil tener leverage con los providers Los providers tienen otras formas de gestionar este price sensitivity Entre otras cosas, por ejemplo limitando el número de accesos que dan Número de teles, el número de usuarios Planes familiares ellos ya tienen sus sistemas de bundling y tal Y de hecho lo que están haciendo es casi al contrario Es reducir el número de accesos subiendo el price point Para intentar luchar contra estas economías de escala de coste adquisiciones de clientes Que al final es lo que les interesa

controlar el cliente Si tú les alejas el control del cliente Le estás alojando su gold Su razón de ser Que es la información del usuario del cliente etcétera No acabo de ver este Problema que resuelves Seguramente Me he perdido algo Pero no Acabo de Ver dónde está la oportunidad de Negocio y En general hacer un marketplace B2C de Todo Como enunciado Me haría salir corriendo Porque es carísimo por todos lados De la demanda De la oferta De Todos Lados veo En lo que nos has Explicado Hoy no Veo un Modelo claro de negocio Y sobre todo no veo

la ejecución del primer año por Ejemplo

Si Yo no me queda Claro si buscabas inversión o no

pero no me o sea no veo Todavía Nada invertible Qué es a lo que Nosotros Nos Dedicamos es Buscar proyectos Invertibles y realmente Tengo un Problema Filosófico y es que Tú das por sentado que los Proveedores lo que están buscando es monetizar ese long tail de Clientes sensibles al precio Sobre todo los clientes de suscripción y yo te puedo garantizar con bastante seguridad de Hablar con Muchos empresarios e inversores Ejecutivos y nosotros Mismos de Empresas de suscripción que para Nada está ahí el foco El Foco está en la retención y la recurrencia de Estos clientes y el modelo que tú nos

Estás hablando de Bundling y de mezclar Cosas va un poco en Contra de Esto la Gente quiere Control Quiere Recurrencia Quiere Lealtad Quiere FidelidadQuiere Personalización Absoluta que Va un Poco en la Dirección contraria con lo cual esa tesis fundacional a mí no me convence de Momento y luego cien por cien con Bernat que hay un pequeño detalle que es decir oye y de Dónde sale el Cliente de donde Sale el Cliente es la madre del Cordero y de Dónde sale Realmente Estas empresas ya Son Bastante Buenas consiguiendo Clientes porque si no habrían llegado a tu radar a que tú las conocieras y Te interesar ayudará

Con lo cualQué te Hace pensar que tú Serás Capaz de Captar clientes Mejor que Esta Gente repartir estos Cuatro duros que el Cliente porque es un Cliente que no está dispuesto a pagar el Precio full puedes Repartir entre Muchos proveedores para hacer este banding filosóficamente no entiendo la oportunidad todavía Quizá es porque es muy recién y todavía tienes que darle más vueltas pero desde punto de vista de inversor que es el que llevamos aquí no ve oportunidad de inversión todavía

sí opino un poco igual intentando hacer un poco de challenge a la Idea y también para instarte a hablar con proveedores No paro de pensar en, en el riesgo de canibalización, eh, que tendría tu producto. Porque al final tú estás pensando en ese long tail de gente que actualmente no está utilizando Netflix, pero también está el riesgo de: hostia, es que si tienes éxito y funcionas, la base de clientes que ya tiene Netflix va a decir: "Hostia, esto es una solución de puta madre, puedo pagar la mitad de precio, me voy a pillar un bundle y dejo de pagar a Netflix".

Y esto va a ser un riesgo que, que Netflix te va, te va a decir: "¿Y qué hacemos con estos?", ¿no? Ehm, entonces, lo, lo que sí que te animaría es a validarlo con los proveedores porque sin ellos, mmm, poco vas a hacer.

¿Me puedes responder? No, luego. Vale. Muy bien. Gracias. Muchas gracias

. Venga, el último, el último proyecto de hoy, ¿cuál es? ¿Carles?

Ay, ¿puedes ir ahí?

Un minuto.

Empiezo yo Eh No sé Qué hace vuestro producto

No

Cómo

Esto Hay Que Preautorizarlo Yo Tengo una, una niña pequeña por ejemplo no y tuve que firmar unos papeles con los DNI de mis padres de la canguro y obviamente de mi mujer y yo Sí Eh A principio de curso o sea hay que preautorizar estas cosas no, novale mandar una foto y decir hoy vendrá Bernat a buscar a Ainhoa al cole Esto Está Liado Nuevamente

Qualla Es la Aplicación

Que se Han Ido a casa Cada Día sí eso Es lo QueQueremos No Que se vayan a casa Claro claro

Es un Gran Dolor

ParaQuién

OseaElProblemaEsDelospodresPrincipalmente

Un tema que es un poco de mal rollo, ¿eh? Pero ¿tenéis algún tipo de estadística de problemas?-

...de, de seguridad?

Hombre, no me, no me refería a esto .

Problema, no estadística cualquiera. Problema de seguridad en la recogida.

¿En serio?

Yo me lo creo, ¿eh? Me lo creo

Vale.

¿Cómo de grande es este mercado?

¿Cómo de grande es este mercado?

¿Quién paga?

El colegio.

¿Cuánto?

¿Cuántos niños tenéis en la plataforma ahora mismo?

Veinte mil. O sea, estáis facturando dos millones y medio.

Ah, no, doscientos mil, porque era al año has dicho. O sea, doscientus-

Que-- ¿hay algún tipo de cole, perdona, ya me callo, algún tipo de cole o de entidad a la que vendáis?

La tecnología qué tiene de especial. O sea, si ahora alguien nos está escuchando y dice: "Esto lo voy a hacer yo", ¿qué, qué tenéis vosotros?

No, no voy tanto por ahí, ¿eh? O sea, me, me da un poco igual.

¿Quién, quién hace la tecnología?

Pero ¿quién, quién, quién la hace?

¿Tú? ¿Programas?

¿Quién programa?

¿Tenéis un CTO y un CIO?

¿Y son founders?

Fundadores.

Vale. ¿Y qué diferencia hay entre un CTO y un CIO?

¿Cuántos sois en total?

¿Cuánto estáis levantando? ¿Lo has dicho o no?

Has, has dicho cuánto estáis levantando.

¿Con quién?

Venga, vamos al feedback. Empieza César.

Vale. Eh, me creo que es un problema que existe. Me, me creo que es un pain suficientemente doloroso como para que tenga que haber una solución tecnológica. No sé si el mercado es suficientemente grande, eh, haciendo foco solo en esto. No me ha quedado claro si vais a cubrir más superficie con el producto. Eh, has hablado de...

Ay, ahora no-- se me ha olvidado la palabra que has dicho, pero, o sea, como que hay alguna gente que se encarga de, de la parte curricular, me parece que has dicho vuestros-- vuestra competencia, y vosotros os encargáis de los-- como los procesos. Eh, has utilizado una palabra de ese estilo. Eh, no me ha quedado claro cuál, cuáles son los siguientes pasos, ¿no? Eh, porque si esto ya lo tenéis descubierto, entiendo que es como desplegarlo en, en colegios, em, pero no, no me ha quedado claro cómo evoluciona el producto para acceder a un tamaño de merca-- de mercado más grande.

Em, si consideras toda Europa y toda Latinoamérica, eh, y son tres mil millones, hostia, mm, está bien, eh, pero no sé, no sé si me creo que vais a capturar una parte suficiente de este mercado que además es jodido capturar siendo escuelas, eh, muchas veces, pues la, la partida, em, va, va por contrato público, ¿no?

Corrígeme si me equivoco, pero e-es, es más difícil vender a, a escuelas que vender a empresas, ¿no? Em No sé, ¿qué opináis?

¿Te puedo contestar o...?

No luego. Luego ya no .

Yo como único padre de, de los tres, eh, obviamente vas a un, a un miedo real, ¿no? O sea, yo creo que me acuerdo al principio sí que me planteaba: "Oye, quién va a ir ahí", ¿no?, y tal. Eh, pero luego viendo con el tiempo las dinámicas y tal, también veo mucho el, el factor humano y esa intuición que tienen es-esos profesionales, esos maestros, incluso conserje de un cole y tal desarrollan una intuición que creo que es muy valiosa y no tengo claro que queramos industrializar, eeeh, ahora mismo porque precisamente es un tema tan sagrado el

quién, quién permites entrar en un cole, a quién le permites llevarse a un-- a una persona menor de edad, sobre todo muy chiquitos, porque cuando ya tienen diez años ya van solos por la calle casi, ¿no?, pueden algunos, o sea que son más... Pero los pequeñitos, eh, no sé si quiero industrializarlo tanto o si ya me está, ya me está bien que haya ese contacto y esa intuición de los profesionales del centro a quien realmente les importa muchísimo la seguridad de y el bienestar de, de los críos que hay ahí.

No, no lo tengo, no lo tengo tan claro. Y luego, la otra duda que tengo es, em, si hay una tecnología realmente defendible y única y, y que os permita crecer y haceros fuertes en el mercado, o si realmente este patrón de uso se hace común, salen como setas y las aplicaciones que, que todos los padres tenemos donde comparten pues las noticias del cole, los menús, eh, las tareas que nos dan y tal, si no podrían incorporar esto de manera muy fácil, ¿no?

O sea, cómo te bloqueas contra una de las apps que ya existen o de comunicación de compadres y estas historias, eh, lo incorporan. No, no me he quedado muy claro. Sumado a que vender a escuelas es un poco miserable porque normalmente van faltas de recursos muchas de ellas o no tienen profesionalizada la parte de IT, veo retos que como inversor no me encantan.

Mmm, como padre te diría oye, con ganas de ver cómo va y quizá, yo qué sé, presentarte a mi cole y a ver si lo prueban, ¿no? Pero no tengo claro la invertibilidad todavía.

Es una putada escuchar el feedback y no poder responder, ¿eh? Pero luego..

Podría al final, sí.

Al final, luego ya, pero no, pero cuando ya no grabamos. Eh, poco más añadir. Yo creo que eso que dice Jordi es muy importante, o sea, y sobre todo los que hemos hecho tecnología sabemos que la tecnología tiene peligros, es hackeable, ¿no? Y a veces es mejor fiarte de dinámicas no escalables con personas conocidas que intentarlo industrializar todo con todos los riesgos que tiene la tecnología.

Yo creo que el problema que intenta resolver no es tanto ir a recoger el niño al cole, sino identificar a alguien desconocido que sea la persona adecuada, que no deja de ser el proyecto este que hemos hablado mucho en las tertulias de Wall… ¿Cómo se llama? Wallcoin. Wallcoin, ¿no? Que era este que leía los iris de las personas, ¿no? E intentaba identificar de forma única a los seres humanos, ¿no?

Yo creo que va más por ahí. Lo que pasa es que esto es aplicable a muchas cosas y no solo a esta. Yo no me metería en este negocio por todos los riesgos de go to market, por, por todos los problemas de seguridad y porque no acabo de ver este problema que tenga que escalar, pero probablemente otro, otro lo verá. Muchas gracias por pichar.

Gracias.

Pues hasta aquí hemos llegado. Gracias a todos por venir y nos vemos el jueves que viene.