Bueno, bienvenidos todos a una nueva tertulia de ITNIC.
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 Genesys.
¿Qué tal, Genesys?
¿Cómo va el espacio?
Bueno, todavía está medio vacío.
Oye, la semana pasada se me criticó llevar una sudadera de un inversor
y hoy me ha asegurado de llevar una de una participada.
Es increíble la cantidad de spam que hacemos de Genesys.
No, tú has empezado tú.
Aquí no pone nada, esto es una sola, solo.
Bueno, hoy 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.
Y estaría muy guay.
Estaba escuchando una discusión arriba sobre el Product Designer,
la figura del Product Designer,
que es una de las mil discusiones recurrentes que hay normalmente
en las empresas de producto y como no en Factorial.
Y creo que podría ser interesante empezar por aquí,
por repetir esta discusión que estamos teniendo en Factorial,
porque estamos en un momento donde estamos replanteando mucho
cada uno de los roles que tenemos en Factorial
y uno de los roles clave en Factorial,
de hecho fue el primer empleado de Factorial
que marcó bastante el ADN de Factorial,
fue César, con el rol de Product Designer.
Y de hecho René me dijo,
oye, ¿me puedes presentar a César?
Porque quiero entender, ¿no?
Ayer justamente, ¿no?
Y les has sentado a seis metros.
Sí, pero en directo.
Entonces, bueno, vuestros roles,
tú eres Design Lead, Product Design Lead,
Design Lead en el dominio de People.
Presentaros, presentaros vosotros mismos.
Soy René.
¿Hay que encender el micro antes?
No, la UIKit es complicada, es prolongada.
Design Lead también, Jonathan Centeno,
en Time y Payroll.
O sea, estamos divididos en varios equipos.
Hostia.
Puedes venir aquí, Alba, puedes venir para aquí,
que hay como tres metros vacíos, si quieres.
No es muy cómodo, ¿eh?
Estáis enfadados.
Sí.
Pues yo soy Product Manager,
soy Alba, soy Product Manager,
en el dominio de People también con René.
Y mi producto se encarga de Performance Management.
Si hay alguna empresa que está interesada
en ver cómo mejorar la performance de sus empleados,
de ayudarles pronto, feedback continuo,
todo esto, pues este es el producto que hacemos nosotros en el equipo.
La evaluación del desempeño, que le llamamos aquí.
Evaluación del desempeño, evaluación incluso de onboardings,
trial periods, objetivos, evaluación de competencias.
Todo ese abanico de productos es el nuestro.
Muy bien.
Oye, pues hay un debate y le he pedido, de hecho,
bueno, ya te lo quedas.
Le he pedido también a Alba que bajara para dar su opinión como PM
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.
Hay escuelas de pensamiento que creen que el Product Manager
tiene que participar mucho en la solución,
de hecho, directamente escribiendo los specs
y casi diseñando wireframes
y que el diseñador es quien luego pinta.
Veo la cara, he visto la cara.
Y luego están los que piensan que el PM es negocio puro,
tiene que entender impacto y costes, pensar la P&L,
y a partir de aquí, cuando decide esto es una oportunidad,
entra el ingeniero que no está aquí hoy representado,
no podemos tener tanta gente.
Bueno, a ver, tú y yo podemos hacer de ingenieros.
No cuenta ya.
Y el Product Designer se encargan de todo, entre comillas.
Y aquí es donde Alba va a hacer la cara de cómo...
Sí, o sea, entre uno y otro yo creo que hay muchas otras opciones.
Hay muchas grises.
De hecho, cuando estabas explicando la segunda opción,
yo estaba en plan, escribir los specs, las user stories,
todo esto, es como no hay nada que sea más inútil,
en mi opinión, que el Product Manager sea la persona
que hace los tickets en Jira y el Project Management y tal,
porque todo ese tiempo es un trade-off gigante
en el que no está enamorando y enamorándose
de los problemas de los clientes,
o participando con el equipo en la solución.
No escribiendo specs, pero sí en flujos, en wireframes.
A mí me encanta colaborar con un Product Designer
haciendo los flujos juntos, los wireframes,
con los ingenieros también.
Iremos al rol del PM.
Igual el PM daría para otro podcast.
Vamos a hablar del PD hoy.
Vamos a hablar del PD.
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 brief?
Sí, a ver, pequeño contexto.
O sea, cumplo dos meses en Factoria.
Una eternidad ya.
Sí, ya se siente largo.
Antes de eso estuve principalmente en Cabify,
hasta ya bastantes años fui el segundo Product Designer
y me tocó, junto con Mark McKay,
que se une a Factorial también, gran noticia,
crear el equipo de producto,
el equipo de diseño de producto.
Pasamos un poco por la fase de caos total,
de no tener PMs,
y donde el Product Designer 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 Designer creía que hacía.
Ahora llega uno más especialista que se empieza a meter en ese terreno.
Personalmente tuve mucha fricción ahí en esa parte.
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 motos que ahora están en parte de Cabify.
Después una fintech que se convirtió en su propia empresa,
que fue Lana.
Y ya no como Cabify,
pero el último proyecto fue Inbopop con Sam,
como quiere ser interesante que hablaran igual.
¿Qué era el CTO de Cabify?
CTO, fundador de Cabify y de Lana también.
¿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.
Quizás era un momento de muchísima hambre, ¿no?
De quererme ganar un puesto en Cabify y en la industria.
Y quizás una falta de tacto.
Yo a veces le llamo política, a Bernat no le gusta esa palabra.
Pero sí de crear relaciones con nosotros, product managers, ¿no?
O sea, no me gusta porque la usas en positivo.
La usas en positivo, claro.
Te gusta como algo bueno.
Y lo ha hablado con Alba también.
Sí, o sea, tiene una muy mala connotación.
Quizás tengo que pensar en una nueva palabra.
Pero para mí es esa capacidad de crear relaciones con otros roles,
con otros departamentos y de tener mucho tacto.
A veces cuando tienes muchas ideas y mucha creatividad, te sale, puedes parecer un poco tóxico, ¿no?
Y crees que estás haciendo lo mejor por la empresa, pero tu energía te rebasa.
Y puede sonar que, bueno, que estás metiendo ambiente tóxico en el equipo, ¿no?
Y 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.
Más allá de tu visión personal y tu situación personal, esta fricción 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 managers y product designers.
En general, cuando aparecen los especialistas o gente más especialista
y poco a poco van reemplazando funciones de los generalistas,
que son normalmente los que empiezan las compañías, ¿no?
Sí, así es.
Y creo que en ese momento, como en Cabify, como en muchas otras empresas,
no estaban claras las líneas entre un rol y otro, ¿no?
Y mi perfil personal quizás 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, bueno, hay que saber 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 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 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?
Entonces, la gente ya no es gente, ya no son personas, 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 el mundo infra.
Y hay otros que son más frontend.
Igual hay developers que les gusta diseñar, ¿no?
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 empiezan a generar Frankenstein, ¿no?
Que no digo que sea nuestro caso.
También creo que hay un problema que nosotros lo estamos haciendo ahora
fuera del 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 de Indy, 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 cómo podemos cambiar de la vida al usuario, ¿no?
Yo creo que ese 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 a decir, en qué problema solucionamos o te callas y dibujas, ¿no?
De hecho, sí, puedo intervenir un segundo.
Cuando estábamos hablando de, bueno, pues al escalar los equipos en Factorial,
al final pues introdujimos las figuras del trío y demás y todos iguales.
Eso es la... todo el mundo lo hacemos cuando escalamos.
También intentamos hacer frameworks para todo.
Entonces, cada cajita no solamente tiene su rol, sino que tiene que hacer exactamente esto.
Independientemente de lo que a lo mejor necesite el producto, incluso el propio equipo.
Y volviendo al tema de las discusiones internas,
para mí hay una cosa que es súper importante y muchas veces se infravalora, es la química.
O sea, también tenemos que optimizar por química dentro de un equipo.
Porque si tenemos química, esas discusiones no pasan.
Y cada uno sabemos, mirándonos a los ojos, sabemos lo que tenemos que hacer cada uno
y cómo podemos aportar más.
Entonces, yo creo que eso es algo que también estamos haciendo.
Hay que poner una casilla de química en el externo.
Total, un chatbox.
Es que además, cuando creas estas casillas, lo que pasa es que la gente empieza a proteger.
Este es mi terreno y mi terreno acaba aquí.
Y cuando acaba mi terreno pasa al siguiente y luego al siguiente.
Y es lo que dice un poco Jordi.
Luego ya te olvidas de que el objetivo no es este es mi terreno y este es mi objetivo
y esta es mi responsabilidad.
No, no.
La responsabilidad es de los tres y es alcanzar un objetivo final.
Y aquí es donde se genera luego el Frankenstein, lo que no tiene sentido.
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 día pisándose.
El ingeniero está pensando en el diseño.
El diseño está pensando en la tecnología y nadie lo ve como algo personal.
Que eso es la startup early stage, ¿no?
O sea, esto es Latitude.
Estáis todos haciendo de todo.
Dudo que nadie esté documentando qué hace cada uno.
No, total.
Y de hecho es algo que también yo he opusido mucho, ¿no?
Pues a veces estamos trabajando, yo que sé, ahora que hemos sacado 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?
Pues yo muchas veces le digo al developer que esté implementando algo, hazme una propuesta.
Hazme una propuesta de diseño porque nosotros estamos con otra cosa y no podemos cambiar el foco ahora mismo a esto.
Y seguro que tú vas a ser capaz de hacer algo con sentido.
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.
Pero la propuesta inicial muchas veces viene del developer.
Me están viniendo flashbacks de lo contento que estabas cuando Pau Ramón se inventaba diseños.
Ah, total.
Porque tú eras siempre el cuello de botella.
Sí.
Siempre los diseños era lo que tardaba más.
Y Pau, que va 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 de diseño…
No había sistema de diseño.
Bueno, copiar la web de Stripe.
Estos son secretos que no se dicen.
No, yo creo que cuando, por ejemplo, nosotros, por hablar de casos prácticos,
estamos utilizando por dentro una librería que se llama ShadCN,
que son una serie de componentes de frontend que actúan del sistema de diseño.
Entonces, hacen mucho el trabajo de sentar las bases de qué pinta tiene que tener una interfaz.
Entonces, es muy fácil entre esto y otra herramienta que se llama Tailwind,
que ya más o menos también te orienta mucho a hacer las cosas de una forma.
Pues generalmente las cosas quedan bien de primeras.
Entonces, cuando tienes una base de diseño muy sólida,
es más fácil conseguir que el deber operte haga una propuesta,
que esté más cerca del producto final, que sea otra cosa que vaya por otra dirección.
No, en cualquier caso, no había ninguna fricción.
O sea, tú juzgabas el diseño que hacía Pau y luego lo arreglabas.
Total.
Pero íbamos a todo gas haciendo lo que podíamos,
que es lo que esperamos de la química de los equipos 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 Product Manager adquiera una posición más estratégica,
más scope, y que los productos tengan más Product Designers.
O sea, estamos contratando más Product Designers y por eso hemos hecho todo este proceso
de definir qué es y qué no es un Product Designer y un poco cuál es el perfil que queremos.
¿Podemos explicar qué es y qué no es para nosotros hoy?
Vosotros dos representáis el leadership de Product Design en Factorial, ¿no?
Entre los dos.
Y sé que incluso entre los dos tenéis en algunos ámbitos divergencias de opiniones.
¿Podemos definir o intentar definir entre los dos qué es y qué no es un Product Designer para Factorial hoy?
Hoy hemos tenido una discusión, de hecho, para bien, ¿eh?
Pero estábamos discutiendo justo si el diseñador tenía hasta qué punto tenía que entrar en el rol
de entender el problema, de ir a conversaciones con clientes, hacer las conversaciones con clientes
y tantas como sean necesarias hasta entender el detalle del problema.
Aquí hemos entrado en la especialización también, ¿no?
Si necesita este rol, tener a alguien especializado que le ayude a hacer este research, ¿no?
Creo que voy a definirlo y luego me dices si estamos alineados o no.
Pero fuera del research, claro, definiciones de Product Designer hay muchísimas
y yo que tengo la oportunidad de hablar con muchísimos diseñadores de muchas empresas
es que cada empresa es un mundo.
En nuestro caso es, oye, ¿qué esperamos del diseñador?
Es que primero de todo entienda el problema, que normalmente es el 80% casi del trabajo.
Si entiendes bien el problema, todo lo demás casi viene dado, ¿no?
Sí que es cierto que hay una parte muy importante en la dirección, en pensar, oye,
¿cuál es esa solución que podemos construir que nos ayude a solucionar el problema?
En el caso de Factorial, el mayor problema que tenemos es, tenemos nueve mercados,
tenemos infinitas casuísticas de diferentes empresas, pero claro, producto hay uno.
Entonces esto a veces es lo que lleva también mucho tiempo, ¿no?
Y luego ya toda la parte de, oye, no solo se acaba en el diseño el diseñador,
sino que tiene que llegar a lo que hablábamos antes, ¿no?
No hay una transición en lo que esto ya pasa un ingeniero, un ingeniero programa y ya, no.
El ingeniero, trabajas mano a mano con el ingeniero para construir esa solución,
asegurarte de que funciona y por supuesto resolver al final, ¿no?
El problema que tiene ese cliente.
Sí, o sea, entrando más en detalle, la discusión que teníamos hoy, o sea,
era hasta qué punto el Product Designer tiene que liderar esos esfuerzos de research o de discovery.
En mi caso, 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 liderarlos es un proceso muy complicado.
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 que lo resuelva.
Pero, o sea, 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 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, al menos como yo lo he visto,
son personas que les apasiona usar software, que les apasiona usar apps.
Y esto es como la música, o sea, los músicos que más escuchan música,
o sea, es que la música les brota de las venas, ¿no?
Los Product Designers que les encantan las apps, que les flipan,
pues naturalmente tienen miles de referencias y cuando le 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 viendo el retrato robot de César.
César no es un super researcher, o sea, no le encantaba,
sobre todo el César de antes, igual hay un nuevo César,
pero no le encantaba ir ahí en toda la complejidad,
le aburría un poco la complejidad de los miles de negocio y tal.
Él, una persona intuitiva, muy rápido, por poca exposición a un problema,
te venía con una solución, ¿no?
Pero la clave es que yo creo que has soltado dos perlas que me han encantado.
Una es lo del diseño es acción, que me la apunto cuando viene,
a veces, diseñadores demasiado académicos.
Y la otra que es, construyendo sobre esto,
César siempre nos estaba enseñando productos, ¿no?
Siempre.
Diciendo, pero de cualquier cosa, ¿eh?
O sea, una app de su vida privada, un negocio financiero, un negocio de media, ¿no?
Y decía, hostia, mira qué patrón de experiencia de usuario hay aquí,
mira qué interacción con el multitouch han creado aquí, mira qué...
Y esa exposición que comentabas ahora, René, ¿no?
El diseñador bueno que está obsesionado con descubrir diseños, entenderlos
y luego intentar 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.
Luego ha resultado clave en el hiring, ¿no?
Cuando ves gente 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 persona la quiero
porque si le oriento bien estará de lunes a domingo pensando en nuevas maneras,
nuevos patrones 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 que el fin de semana normalmente
está haciendo side projects.
Es una cosa que también hablamos mucho, ¿no?
Los side projects.
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.
No, claro.
A veces hay suerte.
No, o sea, nosotros tenemos casos, tenemos gente que está probando
una API o un modelo de inteligencia artificial encima de Factorial
y si mola, pues luego nos lo cuenta y quizá lo intenta meter en el roadmap
o lo está haciendo con su app de pasear perros.
Da igual, ¿no?
Da igual.
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 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 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 VC,
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
para que lo haga en las noches.
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 necesidad imperativa,
creo que forma una forma de pensar que después cuando llegas a una empresa,
pues lo tienes de casa, ¿no?
Ya naturalmente piensas en hagamos esto de la forma más minimalista posible.
Uno de tus side projects es blank page, ¿no?
¿Tú cuando te conocís no tenías un side project de una blank page?
No lo sé.
¿No tenías un blog o un ordenador de blog?
Es un side project de una blank page.
No, pero eso fue más adelante.
¿Cómo se llamaba?
Lo que hacía el CMS.
Hiciste un CMS.
Ah, sí, sí.
Bueno, hice...
Eso fue en Factorial.
Hice Typehat.
Eso, Typehat.
Que era un CMS súper simple.
Es que era muy parecido.
Porque estaba...
Es un pattern este blank page.
Estaba harto de los CMS complejos como WordPress y todos estos
y yo quería montarme un blog, quería montarme un sitio de links
que me parecían interesantes y me monté un CMS
y la verdad que estoy bastante orgulloso de cómo quedó.
Y de hecho conseguí incluso facturar con él.
Lo publiqué en un sitio de estos que se llama Absumo,
que es de Lifetime Deals y me saqué 10.000 pavos o algo así.
De gente comprando Lifetime Deals.
Que tu precio hora seguramente fue una mierda
porque le echaste horas a eso.
Bueno, pero yo...
Al final es una inversión porque también aprendí un montón.
Bueno, no es una inversión, es una diversión.
No, pero es una inversión también en mis skills y mi conocimiento.
¿Sigue vivo?
Sí, sí, sí.
Sigue funcionando.
Porque, claro, vender Lifetime Deals está muy bien,
pero no 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 poco de base, no va tan mal.
¿Tú vendes Lifetime Deals?
No.
¿Haces donaciones?
Sí, acabamos de empezar con BuyMeACoffee Memberships
y OneOff Coffees.
¿Y la gente paga?
Pues tenemos desde enero acá 14 members,
que puedes elegir entre 1, 5 o 10 dólares al mes.
Y como 80 y tantos coffee donors.
Un saludo a los 14 members.
Oye, están cerca de pagarnos, o sea, estamos cerca de ser rentables, ¿eh?
O sea, es muy bueno.
Bueno, es porque el coste ahora, tú y yo lo paga Factorial igual.
El coste ahora se lo va a regalar, por cierto.
Está en mercado.
Nosotros tenemos, Jonathan fichó en Factorial, ¿no?
A Hacin, que ha estado también aquí, se ha golao 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.
Y estoy de acuerdo en que te da muchísimo contexto.
Lo que vale un peine.
Hay factores que deberíamos fichar gente que tenga side projects.
Claro, es lo que voy a decir.
Hay mucha correlación entre capacidad, curiosidad, skills, etcétera, etcétera.
Y tener side projects.
Pero también es verdad que encontrar este talento es muy jodido,
porque la mayoría de gente no hace estas cosas.
Pero tenemos bastantes, ¿eh?
¿Casualmente?
No, y make sense, porque además cuando te traes uno,
generalmente conocen a dos o tres que también se van a venir, ¿sabes?
Porque ven que es un tipo de rol que gusta mucho, ¿no?
O que dentro de la empresa funciona muy bien.
Pero es difícil de encontrar.
También hay otro indicador, diría, que es el product designer,
que empieza diseñando porque le apetece, se divierte, no sé qué.
Y poco a poco, un día, termina trabajando de diseñador de producto en una empresa.
Entonces, no tiene side projects, pero tiene esa pasión,
esa curiosidad de aprender que le lleva a dedicarse a ello.
Bueno, un debate que yo creo que 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?
El pum, pum, pum, hago side project, aquí lo tienes.
Venga, me he cargado aquí la mitad de internet.
La mitad de internet es photo sharing apps.
Claro, pero cuando tú haces una aplicación para tener un balance actualizado
de lo que es el tiempo trabajado anual, teniendo en cuenta las leyes de Alemania,
esto, claro, ahí hay una parte de research importantísima, ¿no?
Entonces, ¿quién hace el research en estos casos, no?
Es un poco el dilema que tenemos en algunos dominios de Factorial
que tienen mucha profundidad.
Pero ahí, sí, por ejemplo, voy a poner un ejemplo hablando también de química, ¿no?
Y de cómo también no hace falta definir si lideras, en mi opinión, ¿eh?
Yo creo que no hace falta definir si lideras o no lideras,
o al final es el momento el que te lo puede decir,
porque sí que estoy de acuerdo en que al final los roles que tocamos tantas skills
o tanta diversidad de cosas que tenemos que tener en cuenta,
sí que va a haber una cosa en la que lo hagamos muy bien y todo lo demás, pues somos ok.
Pero, ¿cómo vas a resolver un problema de una forma muy simple
si no has mirado a los ojos, a la persona que lo tiene,
o a dos o tres, no hace falta que hagas veinte entrevistas, ¿no?
Y quería poner un ejemplo de Francisca, es una product designer
que entró con nosotros ahora un mes, ¿no? Un mes y medio.
Y a mí me encanta y es una persona que respeto mucho
porque sin decir nada, ella es portuguesa y nosotros estamos en Portugal
y el módulo de performance, el producto de performance allí,
bueno, ahí por legislación es importante y, bueno, sin decir nada,
pues se puso en contacto con el equipo de CX, con los account managers de Portugal,
se puso sus entrevistas con los clientes y además salió súper feliz, súper contenta de
¡Buah! Hablar con esta cliente ha sido increíble porque esta visión tal
y esa energía a mí me la contagia y digo ¡Buah! Sí, porque no sé qué.
Entonces nos vamos buando la una a la otra y no es todo el rato yo tenerle que vender la moto a alguien, ¿sabes?
Es decir, pues es que he hablado con este cliente y tal.
Y no sé, es eso que, y no tiene por qué liderar, ¿no?
Porque idealmente hablaría, o sea, nosotros hablamos con los clientes todas las semanas
y al final, pues bueno, a lo mejor yo una semana puedo estar más ocupada
viendo cómo le llevamos el producto a estos clientes que habíamos detectado la necesidad
porque eso también es importante, no detectarla, resolverla y después que se queda ahí
y a lo mejor esa parte la puede cubrir más un poco ella, ¿no?
Entonces, dentro e internamente del equipo nos... a mí no nos gustan mucho las cajitas.
Alba, ¿con cuántos clientes hablas en una semana promedio de verdad, real, más o menos?
Hablar no es siempre hacer discovery, ¿vale?
Hablar, hablar con clientes...
Hablar, pues...
¿Uno?
No, como cinco, una semana tranquilita, cinco.
¿Y vosotros?
¿Yo ahora mismo unos tres?
Yo muy poco, o sea, desde que he entrado he hablado con dos clientes, o sea que...
¿Y vosotros, Marc, que tenemos aquí a gente de experiencia de cliente, en una semana, ¿con cuántos habláis?
Cuarenta.
Por eso la relación con CX también es muy importante.
Claro, ¿no? Que es la parte que falta, o sea, porque el Product Manager puede hablar con algún cliente...
Totalmente.
Pero luego hay muchos clientes.
Pero de hecho es que...
Y cada uno tiene sus historias.
De hecho es que a mí ellos me dicen incluso con quién tengo que hablar.
En plan, yo les cuento el problema y les digo, el trimestre que viene nos queremos enfocar o creemos que vamos a ir por aquí.
Y los account managers son las personas que me dicen, habla con este, con este y con este.
Y me ponen la vida facilísima, ¿no?
Tengo que ingeniármelas para ver quién quiere hablar conmigo.
Es de, no, no, es que ellos ya tienen súper identificado quién nos puede ayudar con este problema.
Y yo creo que tiene mucho valor que los ingenieros también hablen con clientes.
No puede estar todo el mundo hablando con clientes.
Alguien tiene que estar produciendo también.
No, pero en distintas frecuencias sí que se puede hacer.
Y, o sea, para mí hablar con clientes es como un check de realidad.
Exacto.
¿Sabes?
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 es lo mismo, ¿eh?
No es lo mismo.
No, pero es que tú, o sea, esto te ha cambiado, tu visión.
O sea, tú eres muy de cueva.
Sí, pero ya sabes que yo soy de opiniones fuertes, pero débiles.
Pero hoy estás cambiando cada semana.
No, pero tú eres muy de cueva, ¿no?
Yo creo que en general el perfil product designer e ingeniero son perfiles introvertidos.
No son gente de estar siempre fuera, ¿no?
Son gente más de cueva.
No, total.
Hay formas de hacer esto.
Puedes grabar las llamadas y que luego la mayoría de interacción, no interacción, sino la mayoría de input de cliente, pues venga de ahí.
Pero el hacer el reality check, el mirar a la cara...
Y generar empatía.
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 10 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.
Y decir, no, que es uno, es uno de 100.
Tranquilo, ¿vale?
Que has visto uno, pero es que yo veo 15 cada día y no vamos a hacer solo lo que dice este.
Y a veces os agarrabais súper fuerte.
Pero es que me dijo esto.
La gracia tuya, Jordi, aquí, era llevarlos al cliente correcto.
Pero te la juegas.
Te la juegas, pero eso es toda la gente que está aquí escuchándonos.
O sea, todo el mundo está hablando con clientes.
Yo cada vez le coge un poco de rabia esto de que, hey, 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.
No, es con entender el problema.
Es entender el problema.
Es entender el problema.
Que es muy importante.
¿Y qué problema quieres resolver?
Porque hay muchos que has resuelto, ¿no?
Que eso lo decías en casa.
Para mí aquí hace falta una figura.
Que no digo que haga falta en Factorial.
Todavía no quiero abrir esa guerra.
Hay roles que tenemos ya más roles que personas, ¿eh?
Pero creo que como discusión de la industria tiene sentido.
Que es la figura del User Researcher.
Y te digo, no la quiero abrir en Factorial.
Pero, o sea, el Product Designer al final, ¿qué necesita?
Necesitan muchos inputs.
Y estos inputs pueden venir de datos.
Pueden venir de gente de ventas.
Pueden venir de su propia experiencia hablando con clientes.
Pueden venir de uso que ven.
Pero la figura del User Researcher creo que crea un muy buen balance entre todos estos inputs.
Porque ¿quién es el User Researcher?
No son diseñadores.
Si tú ves los perfiles, son psicólogos, sociólogos, antropólogos.
Es gente que realmente se las suda la solución.
Y que no están sesgados en absoluto.
Que lo que quieren es entender la verdadera motivación que hay detrás del request de ventas.
La verdadera motivación que hay detrás de...
Mi pregunta es...
Muy peligroso.
¿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 vayas 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 estaba diciendo, esto es representativo.
La famosa frase de el PM es el CEO del producto.
Claro.
En las startups pequeñas, es el CEO.
El problema es cómo escala de esto.
O sea, era muy importante dónde los llevabas en aquel momento.
En qué reunión.
No había tantos.
Ahora tenemos el buen problema de tener muchos.
Pero el SRN no puede ser un buen equipo de customer experience o de customer success que tienen ideas y entienden los volúmenes y pueden analizar los datos de sus carteras de clientes y decir, oye, yo te hago un research.
Y te hago un research que, por cierto, mientras te lo hago, estoy manteniendo una cartera de cliente satisfecho.
Estoy encontrando oportunidades de crecimiento.
Estoy reteniendo un cliente que tiene problemas.
O sea, te estoy aportando un montón de valor a la empresa y, además, te genero inteligencia, te genero research, si le quieres llamar así.
De hecho, es que eso es súper necesario porque yo tengo una barrera de idioma que hablo español e inglés.
Y nosotros estamos en nueve mercados.
Entonces, la gente que a mí me ayuda...
Y Valencia un poco también, ¿no?
Bueno, sí, catalán.
Entonces, a mí las personas que a mí me ayudan a entender los problemas que existen de performance en Italia, en Francia, en Alemania, en Estados Unidos,
es el equipo de account managers.
Y ellos son los que yo les paso, a lo mejor, un guión de cosas que quiero saber
y, de repente, dos semanas después, me devuelven un documento que digo, esto está de puta madre.
¿Y tú, Río, no crees que esto sea así?
No, sí. O sea, desde luego creo que ayuda.
Y es research.
Pero tú has dicho, el diseño es acción, ¿no?
El diseño es acción y por eso el product designer lo que más tiene que hacer es estar diseñando.
Esto, sí, que lo escuché antes y quiero hacer doble clic.
Venga.
¿Qué significa el designer tiene que estar diseñando? ¿Qué significa diseñar?
O sea, para mí es que tiene que estar probando cosas.
Tiene que, con ese input que cogió, sea de quien sea, de venta, de donde sea, tiene que estar probando cosas.
Pero es que, fíjate, yo con el tiempo me he dado cuenta de que soy mucho más exitoso cuando mi proceso de diseño es 80% entender, pensar, conseguir más inputs, etcétera, etcétera.
Y el 20% implementar la solución que ya he pensado de primeras y probarla con el cliente. Eso es.
Bueno, ese 20% es clave. O sea, que no se lo quiten al product designer.
No es el 100% del tiempo diseñando, entre comillas, ¿no? 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 el producto actual.
Lo que es interesante es la gente, 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.
Eso diría que diseño es acción. O sea, me acoge. O sea, sí, o sea, eso, para mí eso es, diseño es acción es eso.
O sea, que estás, mientras el cliente te está contando algo, estás visualizando ciertas cosas, estás diseñando en tu cabeza.
No quiere decir que estás en Figma, pero estás actuando. No estás analizando y estás, o sea, esto de estar haciendo post-its y tal, tal.
Bueno, hazlo muy rápido.
Claro.
Muy rápido.
Estoy 100% en línea con esto.
¿Hacéis post-its?
No.
Thick Jam.
Thick Jam, el post-it digital.
No, iba a decir que justo era la discusión que estábamos teniendo, porque yo le decía, si el diseñador no entiende muy bien el problema,
lo que va a hacer es rellenar los huecos. Y cuando rellena los huecos te puedes equivocar.
Y normalmente te equivocas. Que es igual lo que pasa con ingeniería.
Cuando tienes un ingeniero que empieza a programar, oye, esto no tiene sentido.
Esto que has diseñado ya no encaja la lógica. Empiezas a encontrar todas las deficiencias.
Entonces, cuando el diseñador entra en entender ese problema al detalle, es cuando entiende todos estos huecos
y los empieza a rellenar con diseño.
Yo creo que aquí sí que estoy muy de acuerdo en la idea de que el diseñador tiene que estar diseñando.
Desde el día uno, prácticamente ya está pintando cosas.
Y en ese proceso va descubriendo cómo funciona el problema y va pintando cada vez más esos huecos.
Y en Factorial, de hecho, diría que siempre hemos tenido dos tipos de cosas.
Teníamos payroll, nómina. Y aquí te podías tirar horas hablando con un asesor laboral,
entendiendo cómo funcionaba el convenio y el trato y no sé qué.
Tengo trastorno de estrés postraumático.
He dicho payroll y me han entrado calores.
Claro, y luego tenías otras cosas que, bueno, podías más o menos por intuición,
el problema era mucho más pequeño y no hacía falta tanto research o investigación
para rellenar esos huecos. Esta es la realidad.
Y luego tenemos proyectos que diseño hay muy poco.
O sea, al menos diseño, como entendemos, diseño de interfaz.
Es mucho diseño de problema por detrás, de cómo funciona, de la lógica,
que aquí es un poco diferente, ¿no? También el rol del diseñador.
O sea, cuando digo de diseño es 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 un montón de lugares
donde se rompe.
O sea, ahí es donde me refiero. Tiene que estar diseñando para 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 que estén todo el día en Figma dándole vueltas a sus propias ideas.
No. O sea, pero que, o sea, como lo de la frase que es la inspiración
de tener que encontrar trabajando, pues la solución te la vas a encontrar diseñando.
O sea, podríamos estar de acuerdo en el concepto de que no tiene sentido
que tú estés haciendo Discovery, ¿no? Tres meses y el último día te pongas
a diseñar la solución, ¿no? Sino que la solución empieza el día uno.
Eso no sirve para nada.
Yo desconfío mucho de cuando un diseñador está repitiendo Discovery y validación
y Discovery, validación, Discovery, empiezo a dudar. O sea, ¿dónde está tu talento
para resolver el problema? Estas palabras a mí 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 falta más disco.
O sea, no. Me mata.
Y tiene que ver ya con la propia metodología de desarrollo de producto.
Cuando volvemos a estos Discovery infinitos, ahí no hay iteración.
Ahí hay un riesgo brutal.
Porque estás construyendo algo que va a ver la luz en X tiempo, has perdido un mes,
el cliente no le va a funcionar, vuelve al Discovery.
O sea, yo creo que toda la gente que es capaz de construir cosas rápidas y sacarlo,
sacarlo y ver cómo funciona, es la gente que tiene éxito en producto.
Y una cosa, la pregunta de qué es diseñar. Yo, por ejemplo, no soy diseñadora.
Entonces, para mí diseñar, yo no me imagino sobre la pantalla.
Yo creo que tú también, o sea, tú tampoco te imaginas la pantalla cuando hablas de diseñar.
Pueden ser flujos de usuario, pueden ser puntos de entrada, las notificaciones.
Las notificaciones. O sea, ¿qué va a conseguir de esta pantalla? ¿Cuál es el objetivo?
Todo eso no tiene color. Pueden ser cajas con cruces, con flechas, con círculos.
Y eso para mí también es diseñar. Y yo no diseño.
Yo hago cajas con flechas, eso sí.
¿Quién hace el copy?
Esto es una buena.
Esto es otra discusión.
Joder, yo pensé que teníamos que cambiar de tema ya y...
Pero creo que aquí René y yo estamos alineados. El diseñador hace el copy.
El diseñador piensa la experiencia y el diseñador tiene que poner ese texto, ¿no?
¿Cómo explicas? ¿Cómo puedes pensar en construir?
Es lo que hablamos un poco de cuando divides, ¿no?
Cuando divides ya nadie toma responsabilidad y todo cae en diferentes cajas.
Si tú estás pensando toda la experiencia, piensas toda la experiencia.
Y toda la experiencia es desde el botón, desde el texto, desde la pantalla, todo.
Absolutamente todo.
Luego sí que es cierto que tienes los perfiles especialistas, ¿no?
Que pueden ayudar a que haya una consistencia en esos textos, ¿no?
Que haya textos mejor explicados.
Que vaya un nivel más allá en la calidad.
Y la traducción, que la traducción siempre es un problema, ¿no?
Exacto.
O sea, ahí te hará falta alguien.
Pero, o sea, en general lo que siempre acabamos convirgiendo es
como más generalistas sean los perfiles, mejor.
Gente del Renacimiento.
Oye, que programe, diseñe y toque el violín.
Sí, pero lo de escribir es básico, ¿eh?
O sea, habilidad número uno para 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 interfase, más de la mitad de los elementos son, es texto.
Entonces, esta idea de que el diseñador hace un layout y después se lo pasa a un UX,
content writer o lo que sea, 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, 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 naiv, que lo podemos hacer al 100%,
pero sí que creo que podemos lograr un 80-20,
donde el 80% 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.
O sea, que es un reto enorme y para el cual estamos buscando product designers excelentes
y que tengan esta mentalidad de diseño de producto como una forma de lograr consistencia
y no tanto como de lograr cosas que apantallen o que se vean muy bien,
no, o sea, de llegar a esta unidad, para mí, no sé.
Yo diría justamente que en Factorial hablamos mucho del concepto de abstracción,
de cómo muchos problemas granulares terminan en una única solución
que permite ser una experiencia intuitiva, justamente, ¿no?
El problema, el gran reto que tenemos ahora es cuando creas un producto tan grande,
el volumen de abstracciones ya no es pocas, ya no son abstracciones, ya es otra cosa.
Y ahora tenemos ese reto de cómo abstraemos la abstracción, en un paso más allá.
Muy bien, hoy llegando a la abstracción última,
nos hemos dejado la lista entera de temas que teníamos hoy,
que han pasado esta semana, ¿eh?
Tenemos el ban de TikTok,
Devin AI, ¿queréis hablar de algo de esto?
¿O pasamos al Q&A?
Bueno, puedo comentar.
Strip Annual Letter.
Devin.
Devin es bastante impresionante, creo que merece la pena,
por si alguien no lo conozca, comentarlo.
Sí, claro que sí.
Vale.
Bueno, esta semana han anunciado un nuevo producto que está en Early Access,
o sea, no se puede usar aún.
Venta privada, ¿no?
Sí, hay una lista de espera.
Yo estoy apuntado, ya os avisaré cuando entre.
Pero básicamente lo que proponen es esta plataforma que se llama Devin,
que es un developer AI, ¿vale?
Pero no es un developer tipo copilot que te ayuda a escribir código,
sino que realmente es un LLM, o sea, un Large Language Model.
Es un agente.
Sí, con comportamiento agéntico, es decir, que tiene 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, cosas de este tipo.
Y lo que hace es dispara varios agentes que hacen en un proceso multipaso,
estoy traduciendo en mi cabeza en tiempo real, un proceso multipaso,
donde, pues por ejemplo, se va a Google y busca la API del producto que estás intentando utilizar
y la mete toda en el contexto para poder utilizarla después.
Se hace un plan de implementación del software que le has pedido, de la aplicación que le has pedido.
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 un código que ha generado,
es capaz de detectar el fallo, utilizarlo como parte del contexto y lo arregla también.
Y te lo va enseñando todo en tiempo real.
Los vídeos, la verdad, que son bastante impresionantes.
Me ha hecho gracia porque en Twitter hemos empezado a ver algunos developers
que se nota que tienen un poco de miedo.
Y además, de hecho, alguna gente que decía,
ah, los artistas que no se están uniendo a la AI 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,
siempre necesitarás tal y cual.
Y el resto del mundo diciendo,
los developers nos habéis sustituido a todo el mundo hasta ahora.
Os vais a cagar.
Oye, es muy chulo 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 la terminal, ¿no?
O sea, un desarrollador romamente 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 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 la documentación, vuelve al código,
lo edita, ejecuta, funciona, va al navegador.
Es increíble.
Sí.
Es per-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 son bastante chulos,
que me han gustado,
de cosas que no sabe si está un poco trucado o no,
porque son vídeos grabados.
O sea, que es difícil...
El binde que está bastante trucado.
Es difícil saberlo esto.
Bueno, pero, por ejemplo,
uno me ha gustado mucho porque pilla el enlace de un blog post
donde alguien generaba unas imágenes de esas muy chulas,
no sé si habéis visto,
usando 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.
Y el prompt era,
ese es el blog post,
quiero hacer esta palabra,
ejecútamelo todo, ¿no?
Bájate las librerías,
haz varios test, no sé qué,
y funciona.
Otro que es,
aquí tienes un super repositorio,
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,
pues es una plataforma para contratar freelancers
donde normalmente el cliente pone una tarea, ¿no?
Y una tarea podría ser, por ejemplo,
pues quiero un scrapper, ¿no?
Un código que se chupe todos los contactos de LinkedIn
y me encuentre, no sé qué, tal.
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é, de momento.
Sí, sí, sí, yo lo he leído que cobra.
Ah, bueno, y en el caso del ejemplo 100.
Y de hecho, para dar un...
Aquí es donde se ha empezado a acojonar la gente.
En el momento que ha cobrado.
Porque, claro,
pones ahí 100 euros de GPUs
y va trabajando, ¿no?
Para dar algún dato que ha sacado la empresa de GitHub.
O sea, los proyectos open source que están en GitHub
tiene una sección de issues, que es precisamente los bugs y features nuevas que quieren añadir al proyecto, ¿no?
Y han dado el dato de que Devin es capaz de resolver, de todas las que han dado,
un 13,7%, si no me equivoco, de issues, que a priori no parece muy impresionante, un 13%.
O sea, no van a dejar a muchos developers sin trabajo.
Bueno, no sé cuántos developers pueden solucionar más del 13%, ¿eh?
También.
Pero es interesante la comparación con los modelos existentes.
Porque tienes a Cloud, por ejemplo, Cloud 3, que me parece que es un 3-4%.
Tienes a GPT-4 con un 1,8%, algo así.
Me estoy medio inventando los números, pero es algo así.
Llama entre medio, sí.
Es un orden de magnitud.
Es un orden de magnitud, correcto.
Y esto es el principio.
O sea, esta gente empezó la empresa esta hace unos meses.
Es una startup que se llama Cognition, que ha levantado 21 millones de dólares de Founders Fund.
Y como curiosidad…
Que es Peter Thiel.
¿Eh?
Que es Peter Thiel, el fondo de Peter Thiel.
Que es Peter Thiel, es el promotor de Founders Fund, sí.
Y me hace mucha gracia porque siempre destaca que los fundadores han ganado 10 medallas de oro de las Olimpiadas de Informática.
Como gran…
Y es una locura porque puedes ver, salió un vídeo también del Founder hace, yo qué sé, 15 años.
Porque tenía 10 años.
Y picando ahí, hackeando en una competición de estas.
Frikis de toda la vida.
Es muy impresionante.
O sea, 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.
Sí, lo sabéis lo que voy a llamar.
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 los large language models pueden terminar en algo como súper generalista, 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 bundle que lo personificaron 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 un bundle 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á...
O sea, este caso del un bundle 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 GPTs, GPTs, que iban un poco por esta dirección, ¿no?
Donde podías promptearlos, configurarlos, tal, pero es una capa por encima muy, muy, muy sencilla.
Es que al final necesitas un UI, como decías.
O sea, para ser un developer necesitas la consola.
Para ser un editor de libros necesitarás algo que te highlighte sustantivos, verbos.
Al final necesitas UI ad hoc.
Hablando de abstracciones, o sea, creo que se van a necesitar cosas ad hoc.
¿Cuántos GPTs habéis usado que no sea HGPT.com desde que salió el App Store hace unos meses?
¿Cero?
Cero.
Sí, he probado un par y fail total.
Sí que me hice alguno, pero dejé de usarlos.
Creaste más que usaste.
Bueno, Dali está puesto como un GPT.
No, pero no cuela.
Sí, bueno, pero te lo muestran ahí como un... en teoría es uno más.
Sí, no parece que tire.
No va a esperar.
No parece que tire.
Oye, pues vamos ya... teníamos muchos temas, pero los dejamos para la semana que viene.
Vamos a...
Antes de las preguntas, yo quiero... me hace mucha ilusión, me han traído un realo, un oyente clásico que normalmente nos escucha desde Suiza, ¿no?
Y nos comenta en YouTube, sanamente loco.
No sé si podéis enfocar esto.
Los que estáis aquí en el público, luego os acercáis a mirarlo.
Pero es una taza que tiene la imagen... perdona, la dejo aquí quieta, ¿vale? Porque si no no vas a poder enfocar.
Que tiene la imagen de ese meme del perro en llamas que se está fundiendo.
Pero en lugar del perro en llamas hay un señor con barba, que interpreto que es una caricatura mía, que pone this is fine, ¿no?
O sea, todo está bien, que es un poco la metáfora de la startup o del emprendedor, ¿no?
De estar todo en llamas caótico y me hace mucha ilusión y además está personalizada, ¿eh?
Pone my daily life at Factorial, ¿no? O sea, un día en Factorial y hay una pequeña taza de Factorial ahí en el background.
Así que muchas gracias, sanamente loco. Me ha hecho mucha ilusión.
¿Está hecha con AI la imagen?
¿Con Dalí?
Con Dalí.
Ah, muchas gracias.
Eso no lo sabía.
Muy fina.
Muy meta.
Usos en producción ya de inteligencia artificial.
Bien, esto se va para casa, ¿eh? No sé qué de la oficina.
Muy bien. Oye, vamos a la...
¿Tenéis más regalos?
¿No?
¿Es el próximo día?
No.
Vamos a la sección de 0 a 1. Si queréis enfocarlo más a Product Design hoy tenemos aquí gente que puede participar.
Vamos a tener que circular el micro por este lado. ¿Quién quiere empezar? Mira, ahí hay una mano.
Yo a Product Design no, a Customer Experience sí. Estamos teniendo un crecimiento bastante bueno
y mi pregunta es, ¿cómo se escala sanamente un equipo de Customer Experience? O sea, ¿qué estrategias se puede usar para escalar un equipo de Customer Experience que no sea contratar más gente?
Es una buena pregunta, ¿eh?
Es una buena pregunta, ¿eh? Tenemos aquí a gente de Customer Experience. A ver, yo creo que, o sea, es difícil plantear escalar un equipo de GoToMarket sin gente, ¿eh?
O sea, al final, igual la inteligencia artificial sustituirá todo, ¿eh?
Y también depende qué tipo de Customer Experience. Si es más orientada a consultoría, que es lo que hacemos en las empresas de software SaaS B2B, o es más puro soporte B2C, que es probablemente más automatizable.
Hay muchas capas de automatización con chatbots, etcétera, ¿no?
En nuestro caso, en Factorial, hemos escalado con personas. Igual como en ventas hemos escalado con vendedores, sí que al mejorar los win rates, la eficiencia, el ratio vendedor, euros vendidos, va mejorando.
En el caso de Customer Experience, nosotros escalamos con personas y la cuestión siempre es, ¿cuál es el tamaño de la cartera idóneo?
Es decir, ¿cuántas cuentas tiene que llevar cada persona y en función de qué, ¿no?
¿Cuál es la complejidad del cliente? ¿Cómo se reparte la complejidad entre los distintos reps, ¿no?
Pero ahí no hay magia, ¿eh? O sea, no hay nada fuera del otro mundo, ¿eh?
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 15% del revenue se invierte en el propio servicio al cliente de software, ¿vale?
Entonces, esto es un benchmark que te puede servir o no, 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 muy fácil, a diferencia de en ventas, ¿no?
En ventas, ¿cuándo escalar? No es nada obvio.
Nada.
Se puede escalar demasiado temprano y quemar pasta y frustrar a todo el mundo, o demasiado tarde y que te pille el toro, ¿no?
Y que te gane el competidor.
Hay riesgo y hay saltos. Funciona por saltos.
Exacto. Pero en cambio, en experiencia de cliente, Customer Success, Customer Experience, como lo quieras llamar,
pues te van llegando los clientes, te vas saturando y vas 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 estábamos en el equipo, no sé qué.
Luego el de marketing, te dabas cuenta de que estabas haciendo más tickets que blog post,
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 es a medida que te van entrando clientes
y te va entrando volumen. Y cuando ya petas, pues vas creciendo el equipo.
Nosotros no hemos usado mucho AI hasta ahora. 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 y tal, son abas contadas.
Yo, es que llevo un día entero hablando sobre este tema. ¿Qué quiere decir Customer Experience en tu caso?
¿Es acompañamiento y onboarding de usuarios o es resolución de problemas de usuarios?
Pasa el micro, pasa el micro.
Es depende del momento. En una empresa pequeña como nosotros, es depende del momento.
Hay veces que alguien te llama porque le falla algo o porque no sabe hacer una cosa
y tienes que hacerle un mini-tutorial. Y hay veces que es cuando le haces el onboarding.
Si es depende del momento, no hay que escalar nada, seguramente. O sea, tiene que ya estar bastante claro antes de escalarlo.
Pero el corto plazo es muy putada en Customer Experience.
Y eso es lo que estarán pensando la gente que nos está escuchando detrás de Customer Experience.
Porque a veces, cuando Ventas tiene buenas noticias, está celebrando, en las mesas del 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 las primeras etapas se acostuma a 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, cuando va creciendo la demanda, cuando van entrando más clientes,
ir contratando más Customer Experience y acabar aplanando estas curvas.
Pero sí que a corto plazo es un pain, sin duda.
Lo que nosotros estábamos hablando, bueno, llevamos un montón de tiempo hablando,
cuando es un tema de acompañamiento, normalmente acaba teniendo que ver con producto,
con hablar con diseñadores, con ir poniendo ayudas, las cosas que no están claras.
O sea, dejar de tener humanos respondiendo a problemas, que la misma interfaz ya te diga
esta lista viene de buscar no sé qué, y entonces dejan de preguntarte dónde viene esa lista.
Y si es sobre resolución de problemas, cada problema que llegue,
hay un momento en que estás tan sobrepasado resolviendo, respondiendo, respondiendo, respondiendo,
que no hay nadie pensando, sumando todos los problemas que hay.
Oye, hay un 20% de las dudas que es este problema.
Y luego está el tema de los centros de resolución de disputas,
sobre todo si tienes un Marketplace con gente, empresas al otro lado,
que tienen que aceptar reclamaciones y tal, automatizar eso.
No necesitas echar GPT, necesitas un formulario de tengo un problema, quiero hacer esto,
quiero, o sea, que alguien esté contando los tipos de problemas que te están viniendo,
taggeando los mails en carpetas de labels de Gmail,
si no usáis ningún sistema de gestión, y empezar a sumar.
Uy, mira, hay un montón de estos. Una de las personas de atención al cliente,
o de Customer Experience, el manager tiene que estar con un contador,
esto es mi problema principal, lo resuelvo.
Ahora me sube este, lo resuelvo.
Y en vez de escalar en gente, escalas en soluciones de software que te lo resuelvan.
Y becarios.
Venga, más preguntas. Por aquí hay una.
Hola. Vale, continuando con el tema de onboarding, pero ahora llevándolo desde el punto de vista de producto.
Es decir, que el producto hace el propio onboarding del usuario.
Y a nivel diseño, ¿cómo de importante es esto?
¿Cuáles son las mejores estrategias?
¿Qué referencias tenéis para hacer el onboarding de usuario?
Vale. 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?
Claro, depende totalmente del producto, ¿eh?
Yo estoy explorando ahora mismo la posibilidad de que el usuario tenga una primera acción
y a partir de la... venga la acción, venga el primer valor que le da el producto
antes de que haga el propio sign-up.
¿Qué os parece esto? ¿Estrategias para hacerlo?
O sea, que haga una primera acción antes de...
Claro, que pruebe el producto antes de que haga el propio sign-up.
100%, o sea, lo que pueda ser antes de tener que hacer un login, permítelo.
O sea, los logins son la muerte, o sea...
Ok, yo los odio.
De hecho, yo soy un poco extremista.
Odio todos estos onboardings que te hacen...
Haz clic aquí, esto, esto, esto, otro, y mira todo lo que tenemos.
¿Alguien hace esto? Yo no.
Y creo que la gran mayoría posiblemente aquí tampoco, ¿no?
Creo que cuando piensas en hacer el onboarding así es porque hay muchas deficiencias en el producto
que lo que tienes que centrarte es, vale, ¿cómo soy capaz de mostrarle cómo funciona el producto
y la propuesta de valor de forma que el producto sea tan intuitivo y tan obvio
que no tengas que explicarlo?
Es que en el momento en que tienes que explicar es lo opuesto al diseño de producto, ¿no?
Y aquí, volviendo a la conversación del copy, ¿no?
De los textos que hay en el producto, los textos tienen que ser un soporte.
Nunca pueden ser el medio, ¿no?
De, vale, como esta funcionalidad no se entiende, la voy a explicar, ¿no?
Voy a crear un párrafo que nadie se va a leer.
Entonces, el productor no se entiende.
Claro, claro. Nosotros tenemos ahora mismo vídeos y texto.
Entonces, creo que el onboarding no es el perfecto.
Entonces, es donde le estoy dando la vuelta ahí.
Así que cualquier referencia que tenga alguien de onboarding me viene bien.
Sí, yo, por ser un poco contrarian, hay una pregunta que mucha gente no se hace
cuando se pone a diseñar un onboarding y es, ¿necesito que el producto haga el onboarding?
Y luego, ¿puedo conseguir que el producto haga el onboarding?
¿Por qué?
Porque te pones en la práctica y ves muchos casos y pruebas muchos softwares.
Entonces, nosotros estamos muy acostumbrados, como diseñadores, developers, gente que monta productos para startups,
a ser muy autosuficientes, ¿no?
Probamos muchas cosas, pues hacemos nuestro research, no queremos hablar con nadie
y nos buscamos nuestras propias habas.
Pero la realidad es que la mayoría de gente no es así.
Entonces, depende mucho de la industria en la que estés, del producto 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 pensar que con un producto que haga self onboarding
vas a conseguir cerrar clientes.
Y, o sea, la verdad que después de haber estado en Factorial, aquí me cambió bastante la visión
porque yo también era muy de pensar, bueno, yo es que para usar un producto no quiero hablar con nadie,
no quiero que venga aquí nadie a venderme la moto ni yo tener que salir de la cueva, ¿sabes?
Pero la realidad es que luego te pones a ver el producto y te das cuenta del problema de la gente
y que eres su última preocupación cuando está probando el software
y dices, hostia, pues igual le chapo el onboarding y le meto a una llamada.
Hace poco, por si quieres referencias, los de Equals, me parece que fueron,
escribieron un blog post donde explicaban que...
Equals es una plataforma que es como una alternativa a Excel pero en la nube, ¿vale?
En una web.
Y explicaban la curva de crecimiento y cómo se había parado o estaba completamente flat
mientras tenían el onboarding, o sea, que la gente podía hacerlo.
Lo chaparon, obligaban a todo el mundo a ir a una llamada y la curva de crecimiento empezó a hacer así.
Y esto es un producto que en principio se presta mucho a que el propio producto te haga el onboarding.
Entonces, pruébalo, pero sobre todo sé muy consciente del tipo de cliente que tienes
porque si no es un developer o un product designer hacer un producto que te haga el onboarding solo
es jodido que funcione.
Nosotros mismos incluso hemos probado onboardings de 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 levantamos la activación por encima del 50%.
O sea, no...
Hay más ejemplos, ¿no?
De esto que decías tú, por ejemplo, Superhuman.
También, famosamente, hacía una llamada de 45 minutos para hacer el onboarding
y ahí garantizaban 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 varios otros ejemplos que los comento rápido porque es que justo hoy de casualidad...
¿Dónde estás ahí?
Una de nuestras participadas nos preguntaba lo mismo, ¿no?
Es decir, oye, empiezo a tener muchos onboardings.
¿Qué hago? ¿Hago blog posts y vídeos? ¿Contrato gente o lo hago yo, fundador, no?
Y precisamente decían, ¿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 caching
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, se saldaron de en medio, ¿no?
Superhuman, que como hemos dicho ahora, hacía el onboarding con un equipo de Customer Access y tal.
Y yo, por ejemplo, a este fundador le decía, oye, 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 y tienes que estar haciendo otras cosas
como ventas o quizá levantar pasta o lo que sea.
Pero aprovecha también este input que te dan los clientes durante el onboarding.
O sea, yo creo que no hay que tener prisa en hacer esto hiperescalable.
De nuevo, como decíamos antes, ¿eh?
Hasta que no te das cuenta de que no llegas.
Entonces, ahí sí que no hay más remedio.
Y ya por último, creo que una reflexión que justo estaba pensando ahora.
Dependes mucho del intent que tenga tu usuario.
O sea, la intencionalidad que tenga y la necesidad que tenga de tu producto.
Es muy raro que tu producto, que es nuevo en el mercado, es nuevo 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 techy,
es capaz de hacer un onboarding y entrar por su cuenta y para adelante, ¿no?
Pero me atrevería a decir que la mayoría de productos que hay en el mercado
es difícil que sean la máxima prioridad en la cabeza de sus clientes cuando llegan a la web.
Es difícil.
Pero, por eso, decide primero si necesitas un onboarding
o si te da más valor, como dice Jordi, el empezar a hacerlo a mano
porque vas a capturar más datos, vas a generar más intent
porque vas a hacer un proceso de venta realmente
y te vas a asegurar de que la persona, primero, tú has entendido el problema que tiene
y, segundo, la persona entiende cómo resolverlo con tu producto,
que esto es lo más jodido de hacer con un onboarding, con un self-onboarding.
Vale.
Bueno, nada, muchas gracias.
Vamos a otra pregunta.
Intentemos hacer respuestas un poco más cortas igual,
porque si no, no habrá más preguntas.
¿Quién más?
Ah, bueno, si no, entonces largas.
Un rollo más.
Hola, muy buenas.
Bueno, primero, muchas gracias por el podcast que, vamos,
me he tirado como cinco meses en Bali
y habéis sido mi acompañamiento casi diario.
Cada paseo que me daba me acompañabais.
¿No eres Jorge AM, no?
No, no, no.
Ah, vale, porque hay alguien en Bali que nos sigue,
que se llama Jorge AM.
¿No está en Tailandia, Jorge?
Ah, es verdad, era Tailandia, nada.
Porque nos comente por YouTube.
Vamos, de todas maneras, estoy seguro de que hay mucha gente en Bali
que os sigue, ¿eh?
Sí.
A ver, yo hace cuatro años monté un e-commerce
y vengo más de la parte de empresa y de marketing.
El caso es que hace como cosa de un año empecé a cerrarlo
y como tenía tiempo libre decidí que iba a aprender a programar
y lo veía como un medio para llegar a un fin.
El caso es que por el caso no he descubierto que el medio me gusta mucho
y el craft por el craft de programar me ha enganchado.
Entonces, ahora estoy buscando un poco qué modelo encuentro
que me permita no hacer como que no he descubierto esto
pero tampoco dejar atrás mi anterior, mi pasado, ¿no?
Entonces, cuando os veo a vosotros
que habéis pasado de ser desarrolladores, de ser diseñadores
a tener un papel de gestión
me viene la pregunta de
¿no echáis mucho de menos el craft por el que empezasteis todo esto?
Y si es así, ¿cómo os rascáis esa necesidad?
O sea, cuando habláis de side projects
¿tenéis side projects vosotros?
En general, ¿cómo hacéis para esta parte de crear proyectos
hacerla convivir con el ONU?
Es que quiero ser yo el que los pique.
¿Quién dispara?
¿Voy?
Bueno, yo ahora tengo la suerte de que he vuelto al craft
sí que en mi última etapa en factorial
pues ya apenas tocaba el Figma
pero sí que hay un comentario que muchas veces escucho a Bernat
que es que la persona que está haciendo la parte de la gestión
hay una cosa muy importante que tiene que hacer
y es ser capaz de entrar hasta el último detalle
cuando toca
y el decir cuando toca
y yo creo que en esos momentos
es donde
y yo me acuerdo en factorial
ya te digo, cuando era director de producto
o BB Product
había momentos en que me tenía que meter
hasta el fondo de las cosas
y sentarme con una diseñadora
sentarme con una developer
y decir, hostia, vale
¿cómo montamos esto?
y nos ponemos una pizarra en blanco
y venga, va a pintar tal
el esquema de arquitectura tal
y yo esto lo disfrutaba un montón
pero no solo lo disfrutaba 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 era clave
y me quitaba
esta espinita que tenía
yo creo que es muy importante
que un manager sea capaz de hacer esto
y de hecho es que pasará naturalmente
si el manager
aprecia el craft
como dices
Mi site project es
un podcast
un fondo de inversión
o sea
no hay tiempo para site projects
pero programar
yo sí que he hecho de menos programar
no programo
cero ahora mismo
hace tiempo que cero cero
y lo he hecho 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
¿qué haré?
y la verdad es que no tengo ni idea
si ese día llegará
y qué pinta tendrá
pero me imagino
recuperar la programación
porque es
o sea, realmente
cuando Devin AI sea todo
entonces te pondrás a programar
pues sí, yo qué sé
pero por placer
pero por placer
porque es un construir
es una habilidad
a mí me encanta programar
es construir
además el feedback loop
es muy rápido
es precioso
es como para un escritor escribir
o para un pintor pintar
para mí era programar
y lo he hecho de menos
y no abro un editor de código
desde hace tiempo
y lo he hecho de menos
pero es que
o sea, cuando tienes un rol
de responsabilidad
yo creo que los adprojects
que decíamos antes
está muy bien en teoría
pero la práctica
cuando la gente empieza
a tener roles de management
ya se acaba
bueno
Tobin Luke
el CEO de Shopify
sigue programando
y los hermanos Collison
también de Stripe
pero en Shopify
no como side project
lo que se acaba
son los adprojects
es que el tema es
cuando estás en una empresa
donde hay tanta
tanta actividad
en tantos ámbitos
tú puedes casi elegir
el side project que quieras
hay mil side projects
ahí
y creo que un punto importante
lo que decía César
de bajar al detalle
es
no hace falta que sean
los proyectos clave
porque si tú bajas
a los proyectos clave
parece que tú no confías
en tu equipo
clave no significa
necesariamente clave
para la empresa
sino clave
el hecho de que tú
te metas en ese proyecto
es en este ejemplo
casi aleatorio
donde tú vas a bajar
vas a bajar
vas a bajar
y te vas a meter
donde tú primero disfrutas
si te gusta el craft
a mí me encanta
no programo
pero igual sí que tengo
discusiones sobre bases
de datos
sobre no sé
cosas
enfoques de tecnología
que estamos haciendo
soluciones de experiencia
de usuario
a mí eso me encanta
por un lado
me lo paso bien
luego
en esta discusión
me permite alinearme
con las partes
y pensar juntos
y en ese pensar juntos
salen muchas cosas
desde los valores
de la empresa
hasta por qué estamos aquí
hasta la estrategia
puedes hablar de muchas capas
en esta discusión
del detalle
y luego
hostia
para un manager
es la hostia
poder cambiar de contexto
y ver tantas cosas diferentes
y trabajar con gente
con tanto talento
a tu alrededor
o sea para mí
yo pienso a veces
que soy tan afortunado
que 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í
de hecho yo 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
prioridad top
era típico
de arreglar
el back office
me ponía
a arreglar
alguna cosa
que me molestaba
oye pues tenemos
tenemos cosas
pero me di cuenta
de que era mi manera
de procrastinar
o sea a veces
tenía un marrón
claro yo
se me daba bien
la programación
¿no?
es una cosa
que la veía fácil
y a veces
pues había que cerrar
un cliente
o había que
yo que sé
conseguir pasta
o solucionar
un problema
que quizá
no tenía tan por la mano
y me escondía
en la programación
que era mi craft
y un poco
me prohibí
hacer eso
porque para mí
era procrastinar
era estás dedicando
yo pensé
que te lo había prohibido
Pau
no
que va
pobrecito Pau
yo simplemente
por añadir
creo que
también hay un cambio
de mindset
cuando tú pasas
a management
es decir
pasas de ser crafter
a management
y te crees que
tu única forma
de seguir
teniendo un impacto
es construir
¿no?
es programar
o es diseñar
y hay un momento
que tienes que
para mí
hizo trigger
decir
es que todo lo que
está construyendo
mi equipo
también lo estoy
construyendo yo
de alguna forma
y lo que dice César
aunque pases a una función
de management
tu rol no es simplemente
hablar con gente
reunirte
no, no
a veces
hay que bajar
al detalle
entenderlo
y abres el figma
y abres el figma
con un diseñador
y te pones a pensar
ideas
y cómo resolverlo
y demás
y luego si te pica
ya más el gusónillo
pues el side project
eso está claro
gracias
yo una cosa más
igual
o sea yo soy muy fan
de los side projects
te puedo tratar
de convencer
o sea
otro valor que veo
de tener un side project
es que
no solo es conectar
con el craft
sino que te puede permitir
tener un lugar
en donde te puedes
distanciar
de ciertas cosas
del día a día
que te pueden presionar
mucho
entonces el side project
como un lugar
donde vas a este lugar
feliz
donde nadie te va a molestar
de modelos de negocio
ni de absolutamente
nada más
que por el pub
me encanta lo de molestar
de modelos de negocio
este es mi rol
puede llegar a ser
un punto muy relajante
como decía Jordi
pues él lo usaba
para procrastinar
pero te animaría
que si te gusta
y lo disfrutes
pues que lo hagas
igual que como
puedes tocar guitarra
o andar en bici
yo que sé
o sea
ahora sí que
por disfrutar el arte
vale
última pregunta
y nos vamos a los piches
creo que tenemos dos
además
venga
alguien
o algún comentario
más regalos
mira ahí hay uno
ahí hay una mano
a nuestra izquierda
oye
lo de los sofás
yo no estoy cómodo
aunque lo pueda parecer
que es decir
que estamos así
porque es la única manera
de estar sentado
es que no sé
cómo ponerme ya
es complicado
hola
bueno
yo solo quiero hacer
una reflexión
y es que
en los últimos
tres años
que he estado trabajando
en una consultoría
pequeñita
de aquí de Barcelona
me he dado cuenta
que el crecimiento
profesional que he tenido
ha sido por apoyarme
mucho
también en los otros roles
y ser muy participativo
en la solución
pero siempre muy cerca
de dónde está el problema
porque al final
llega un punto
de que
o sea
también un poco
con la experiencia
de haberlo visto
en otras empresas
que te quieren tener
como apartado
y es como
tú solo programa
pero
cuanto más cerca
estás del problema
mejor
entendes la necesidad
y mejor
puedes plantear
una solución
porque a lo mejor
la persona
que te ha recogido
ese input
no ha sido capaz
de ver un poquito
más allá
que a veces
es normal
porque estás saturado
y tienes muchos frentes
entonces
yo me gustaría animar
que siempre
pudierais estar
lo más cerca
del problema
y que
trabajarais muy
mano a mano
con el resto de roles
porque vais a aprender
muchas skills
que al principio
no te das cuenta
cuando estás empezando
y luego
cuando estás avanzando
más en tu carrera profesional
te das cuenta
de que tienen un valor
muy grande
de hecho
es que eso
para mí
lo trasladaría
hasta al reclutamiento
o sea
por ejemplo
para contratar ingenieros
pues se hace una entrevista
al principio
con el hiring manager
y después
una entrevista técnica
y después tal
yo como product manager
a mí me encantaría
participar
en el proceso
de reclutamiento
de ingeniería
y de diseño
y me encantaría
que diseño e ingeniería
participaran
en el proceso
de reclutamiento
de producto
de product management
porque
cada uno
vamos a estar sesgados
a mirar
una skill
en concreta
en esa entrevista
y a lo mejor
en una entrevista técnica
estás muy enfocado
en tus habilidades
para programar
en las gemas
que has hecho
y que has contribuido
pero luego
te comunicas
como el culo
y a lo mejor
cada uno
vamos a estar observando
una cosa distinta
y no sé
ese approach
también lo llevaría
incluso
al reclutamiento
no sé qué pensáis
eso está en el hiring
en Factorial
particularmente
no contratamos
programadores
al menos
lo intentamos
que no tengan
lo que llamamos
agency
agencia
esta voluntad
de entender el porqué
y cuestionar siempre
o sea
nadie
programa
lo que le viene dado
lo que le dicen
que programe
buscamos gente
que sea contrarian
que diga
¿por qué?
hay una forma mejor
de hacerlo
¿por qué me miras
cuando dices contrarian?
contrarian
es el eufemismo
de toca pelotas
me encanta
ese puesto de moda
pero
se lo he visto en la mirada
no pues sí
o sea
yo creo que esta es la actitud
¿tú eres programador?
sí
sí sí
luego hablamos
¿eres contrarian?
no no
yo lo tengo muy claro
ya
de momento
estoy muy bien
donde estoy
creo que me faltan
muchas cosas
por aprender
y en el sitio donde estoy
puedo aprender mucho
y luego también tengo
un side project
una red social
que está ahí
y va a ir para largo también
o sea
es complicado
de momento
hacer un cambio
tienes todos los checks
¿eh?
¿tú quieres decir algo?
no
ah vale
bueno pues ahí
vamos al pitch
hoy tenemos dos pitches
Francesc
Mark
a ver
¿cómo nos colocamos ahora?
¿qué manera de despedir?
¿se me escucha?
sí
vale pues dispara
hola buenas
espero que estéis todos bien
mi nombre es Max
y soy el fundador de Bandlot
Bandlot es una startup
que ha nacido
para transformar la forma
en la que consumimos
cualquier producto
en nuestra economía
que tenga costes marginales
de producción
o distribución
muy bajos
lo que vamos a hacer
va a ser crear
lo que yo llamo
megavundles
un megavundle
es un conjunto
de productos
de varias categorías
que se agrupan
y se venden
como una unidad
a través de una suscripción
es decir
el usuario
paga una suscripción
y eso le da acceso
a consumir
todos estos productos
gratuitamente
o con descuentos sustanciales
estos productos
como he dicho
van a ser de varias categorías
siempre y cuando
tengan costes marginales bajos
como por ejemplo
servicios de streaming
de películas
de series
de música
de deportes
podemos tener
suscripciones
a productos SaaS
podemos tener
suscripciones
a periódicos
suscripciones
a videojuegos
a plataformas
de aprendizaje online
etcétera
también podemos tener
productos de telefonía
incluso productos de retail
con márgenes altos
nosotros al final
lo que vamos a dar
a los usuarios
son links de activación
para las suscripciones
y códigos de descuento
para los casos
de uso de retail
pues bien
este es el producto
cuáles son los problemas
que estamos solventando
y por qué estoy convencido
de que el futuro
del consumismo
va a estar canalizado
a través de megabandels
como este
pues por varias razones
solo tengo tiempo
para explicar
las que tienen que ver
con experiencia de usuario
una de ellas
es que estamos
centralizando
los gastos
de las suscripciones
en vez de tener
varias suscripciones
en varias plataformas
separadas
que tienes los pagos
que se te olvidan
si los quieres cancelar
y además son muy difíciles
de agregar
porque los tienes
en varios sitios
por lo tanto
no sabes cuánto
te estás gastando
lo que hacemos
es reducir ese problema
porque lo que vas a tener
es una plataforma
con mega suscripciones
que te va a incluir
todos los productos
que vas a acabar consumiendo
por poner un dato
el americano promedio
cree que gasta
80 dólares al mes
en suscripciones
pero en realidad
gasta más de 200 dólares
al mes
pues bien
esa es una parte
otra parte
es que estamos
cambiando la forma
en la que consumimos productos
porque en vez de pagar
por cada producto
que consumimos
lo que estamos haciendo
es transferir esos costes
a la suscripción
que es un pago fijo
y después
consumir te cuesta
marginalmente cero
por lo tanto
no solo aumentamos
el consumo
sino que lo volvemos
más agradable
porque no te está
costando consumir
también hacemos
que puedas explorar
productos
ya que no hay
un coste marginal
y eso solo es posible
si no hay fricciones
si se te permite
consumir
sin un coste marginal
pues bien
me quedo
sin tiempo
para explicar
muchas otras cosas
para mí
más importantes
sobre el proyecto
no tengo tiempo
y me encantaría
recibir
vuestras preguntas
y vuestro feedback
gracias
muy bien
empiezo yo
si puedes
súper breve
no he entendido
lo que hacéis
puedes explicarlo
muy simple
muy simple
con muy pocas palabras
es un bundle
que te incluye
que es un bundle
más simple
es un conjunto
de productos
que se vende
como una unidad
estos productos
son productos digitales
sobre todo
sus creaciones
agregáis productos digitales
por ejemplo
una cuenta de netflix
una cuenta de un periódico
para lectura
una
o sea compras de golpe
varias cosas
si
y es un descuento
es un descuento
al usuario
le sale mucho más barato
que la suma
de los productos
individuales
porque hay economías
de escala
¿cuánto más barato?
a veces órdenes
de magnitud
o sea si sumas
si tienes un catálogo
de 100 productos
la suma de los precios
pueden ser
3.000 dólares
y quizá el bundle
te cuesta 50 dólares
¿y netflix
por qué quiere
meter su netflix
a un mega bundle?
pues porque
hay economías de escala
en los mega bundles
entonces
si tú puedes comer
¿qué significa
economías de escala
en los mega bundles?
¿me das
un minuto y medio?
bueno
menos menos
os habrás
vale lo explico muy rápido
estos productos
con costes fijos altos
y marginales bajos
tienen un problema
muy grande
el problema es que
cuando venden
sus productos
individualmente
es decir a la carta
y no a través
de un bundle
tienen que poner
un precio
y este precio
puede ser más alto
o más bajo
pero como tienen que cubrir
sus costes fijos altos
el precio
por una vendida
siempre se queda
mucho
muy por encima
del coste marginal
de producción
eso hace que se quede
una cola de la demanda
muy larga
desabastecida
para poner un ejemplo
una cuenta de Netflix
o sea
hay gente que no se puede permitir
los 10 euros del Netflix
exacto
pero que valora Netflix
menos que 10 euros
quizás 5 euros
o 2 euros
entonces
ese problema
a nivel de producto individual
si lo vendes por unidad
solo se puede resolver
intentando hacer algo
de price discrimination
la solución
la solución
del bundling
que está haciendo
es que
el mercado
puede servir
a toda esta cola
de la demanda
larguísima
porque lo que estás haciendo
es que el usuario
no paga marginalmente
por el producto
sino que paga
los costes iniciales
de la suscripción
entonces
estás digamos
sirviendo
a un mercado
que hoy en día
no se está sirviendo
y que bueno
esta falla de mercado
tiene unas magnitudes
enormes
porque cada producto
de estos
tiene este problema
¿en qué momento estáis?
la idea es muy prematura
aterrizo en mi cabeza
hace un mes
cuatro semanas
y tengo un prototipo
tengo la idea de negocio
y bueno
tengo todo lo que se necesita
para empezar
pero es muy temprana
¿has hablado con usuarios
o proveedores?
con proveedores
todavía no he validado
absolutamente nada
con usuarios
bueno
he hecho el pitch
a mucha gente
le he explicado
la parte técnica
de por qué
estamos resolviendo
una falla del mercado
y cuando me paro
explicar
todo el mundo lo entiende
tiene sentido
de hecho ya existe
ya existe
el bundling
Netflix
por cierto
lo que innovaba
Netflix
es que hizo un bundle
de productos
que tienen costes
fijos altos
y marginales bajos
que son películas
cuesta mucho de producir
una vez están producidas
distribuirlas
es muy barato
entonces quiero hacer
con productos
como Netflix
lo que Netflix hizo
con productos
como películas
lo que Spotify
hizo con canciones
y lo que muchas otras
empresas
como Office
también han hecho
en su propia categoría
cuando dices que
distribuirlo
es muy barato
estás obviando
una parte muy importante
en los
soportes de suscripción
o negocio de suscripción
que es el coste
de adquisición del cliente
tú estás pensando
que ya tienes al cliente
distribuir la película
es barato
pero lo caro
es conseguir al cliente
y amortizar
este coste
en el lifetime value
del cliente
exacto
ahí es donde está el modelo
obviamente este es
el coste marginal
más alto que hay
en el bundling
también hay economías
de escala
en el marketing
porque en vez de tener
una campaña de marketing
para cada uno
de los productos
por separado
lo que podemos hacer
es tener una gran
campaña de marketing
para el bundle en sí
y cuando los usuarios
se convierten
en suscriptores
ellos mismos
ya están incentivados
a hacer un product discovery
dentro del bundle
porque tienen
descuentos sustanciales
por lo tanto
van a preferir
consumir ese producto
en vez de la competencia
que está fuera del bundle
entonces el product discovery
es más orgánico
y por lo tanto eficiente
o sea el coste de adquisición
al final está bajando
por esto
se ha acabado el tiempo
vamos al feedback
empiezo yo mismo
modelos de grupos
de compras en grupos
y tal
hay muchos
hay muy pocos
que han 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
el 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
es subiendo
el price point
para intentar luchar
contra estas economías
de escala
de coste de adquisición
del cliente
que al final
es lo que les interesa
controlar al cliente
si tú les alejas
del control del cliente
le estás alojando
su gold
la razón
de ser
que es
la información
del usuario
del cliente
etcétera
entonces
no acabo de ver
este problema
que resuelves
no
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 los 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
no me queda claro
si buscabas inversión
o no
estoy acabando de empezar
entonces
me interesa
acabando de empezar
mejor que empezando a acabar
pero
no me
o sea
no veo todavía
nada invertible
que es a lo que
nosotros nos dedicamos
es a 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
¿no?
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 fidelidad
quiere 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
100% con Bernat
que hay un pequeño detalle
¿no?
que es decir
oye
¿y de dónde sale
el cliente?
de dónde sale
el cliente
es la madre
del cordero
y de dónde sale
¿no?
o sea
realmente
estas empresas
ya son bastante buenas
consiguiendo clientes
porque si no
no habrían llegado
a tu radar
¿no?
a que tú las conocieras
y te interesara
ayudarlas
con lo cual
¿qué 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
o sea
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 el punto
de vista de inversor
que es el que llevamos aquí
no veo oportunidad
de inversión todavía
gracias
sí
yo opino un poco igual
intentando hacer
un poco de challenge
a la idea
y también para instarte
a hablar con proveedores
no para pensar
en el riesgo
de cannibalización
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 Netflix te va a decir
¿y qué hacemos con estos?
entonces
lo que sí que te animaría
es a validarlo
con los proveedores
porque sin ellos
poco vas a hacer
no puedes responder
no
gracias
muchas gracias
venga el último
el último proyecto de hoy
¿cuál es?
¿Carlos?
¿puede ser ahí?
sí
¿pensáis que es fácil
garantizar
quién son las personas
autorizadas
a recoger a los niños
cuando salen
de su actividad?
bien
pues ante esta pregunta
esto es lo que resolvemos
ante esta pregunta
lo primero que hicimos
fue hacer un contraste
con la prensa
y vimos que era una necesidad
y cuando lo contrastamos
con los colegios
era un problema histórico
nadie lo había resuelto
a partir de aquí
nosotros buscamos
a ver qué respuestas
tenemos que dar
y a quién le tenemos
que dar estas respuestas
por un lado
están los papás
que horarios laborales
no les coinciden
con los hijos
y necesitan hacer cambios
a última hora
además
una vez
son los cambios
necesitan tener
el feedback
de que aquello que han hecho
ha funcionado
los maestros
tienen que recordar
los cambios
de última hora
y lo tienen que hacer
de memoria
si quieren ser ágiles
y finalmente
los colegios
que resulta que
colegios que tienen
unos protocolos
impresionantes
no están registrando
con quién sale
el niño cada día
bien
nuestro objetivo era
cómo respondemos
a todos ellos
de la manera más fácil posible
y simplificando
simplificando
y buscando experiencia
de estudio
llegamos a un solo clic
en un solo clic
hacemos todas estas respuestas
cuando esto lo llevamos
al mercado
aparece otra sorpresa
y aquí tuvimos que definir
dónde vamos a estar
y cómo no nos vamos a mover
porque si no
hubiésemos perdido el foco
y la sorpresa fue
que nos empezaron a pedir
que mediante un solo clic
qué más podíamos resolver
y ahí
hay un flujo de cosas
que hemos ido resolviendo
a nivel de comedores
transporte escolar
autorizaciones
etcétera
construimos un paraguas
para no salirnos
de nuestro foco
y el paraguas es
que queremos dar tranquilidad
que en definitiva
es lo como nos definen
los clientes
que ya tenemos
queremos dar tranquilidad
y la tranquilidad
son dos cosas
por un lado
ahorremos riesgos
y por otro lado
ahorremos trabajo
los riesgos con trabajo
no son tranquilidad
y después ponemos
al cliente en el centro
con dos objetivos
un primer objetivo
garantizar que cualquier
funcionalidad que hagamos
va a cubrir una necesidad real
y que tal como lo hacemos
va a ser útil
¿vale?
¿me marcas un minuto?
un minuto, vale
bien
tres características
que nos van a acompañar
en todos nuestros desarrollos
agilidad
un solo clic
facilidad
experiencia de usuario
muy interesante
lo que habéis comentado hoy
porque ahí estamos muy enfocados
y evitamos el aprendizaje
y finalmente seguridad
porque todo lo registramos
una de las cosas
que teníamos que analizar
también es
quién iban a ser
nuestros competidores
y pusimos el foco
en todas las plataformas
que existen en el mercado
que es Ciclique Edu
SM Educamos
Alexia
etcétera
etcétera
que existen
pero salimos
al mercado
y vimos que
estábamos compartiendo
el espacio
y ahora estos son
nuestros aliados
porque ellos están
muy enfocados
a una parte curricular
y de gestión escolar
y nosotros estamos
muy organizados
en el sentido
de resolver
protocolos escolares
estamos integrados
nos estamos integrando
con varias de ellas
y a partir de ahí
pues hemos empezado
con un negocio
B2B
segmentado
en base al número
de usuarios
que tiene cada centro
y bueno
como no hay más tiempo
ya a partir de aquí
las preguntas
¿empiezo yo?
no sé
qué hace vuestro producto
¿qué hace el producto?
no
garantizar
con quién salen los niños
a la salida del colegio
¿cómo?
los papás
con un solo clic
aprietan
y marcan quién es
la persona autorizada
y a partir de aquí
todo ha fluido
los maestros
simplemente a la salida
nadie les tiene que decir nada
ven la cara del niño
y ven la cara del recogedor
y le dan al botón
ya saben
y con eso ha quedado registrado
los papás han recibido
la notificación push
este es el producto
vale
esto hay que preautorizarlo
yo tengo una niña pequeña
por ejemplo
y tuve que firmar unos papeles
con los DNIs
de mis padres
de la canguro
y obviamente
de mi mujer y yo
a principio de curso
hay que preautorizar
estas cosas
no vale como mandar una foto
y decir
hoy vendrá Bernat
a buscar a
ahí no al cole
esto
que está liado nuevamente
esto tiene un problema
es una de las competencias
que teníamos
porque los niños
sin cualla
se han ido a casa cada día
perdona
perdona
la frase esta
los niños sin tener cualla
cualla es la aplicación
se han ido a casa cada día
con lo cual
correcto
¿cómo?
que se han ido a casa cada día
eso es lo que queremos
que se vayan a casa
claro claro
pero como lo han hecho
para que puedan salir
y esta es nuestra competencia principal
romper con las formas
que están trabajando
los colegios
establecidas
¿es un gran dolor?
sí
¿para quién?
para todos
los papás
porque realmente
los cambios de última hora
que los tienen que hacer
tú lo sabes
porque al final
resulta que un día
tienes que ir
o tiene que ir tu hermana
y al final no puede
y tienes que ir a cambio
o un papá de otro niño
que dice
oye
no llevo de fiesta
de cumpleaños
y quieres autorizarlo
pero es novio
¿vale?
entonces esto está ocurriendo
y lo que tú comentas
de los papeles
que se llenan
a principio de curso
son estáticos
pero es que la vida
del colegio
no es estática
o sea el problema
es de los padres
principalmente
los padres
los maestros
que tienen un dolor
impresionante
porque a la hora
de la salida
no saben
seguro
con quién tiene que ir el niño
y funcionan de memoria
ya este lo conozco
un tema que es un poco
de mal rollo
pero tenéis algún tipo
de estadística
de problemas
sí
de seguridad
sí mira
solo en Cataluña
hay cada año
unos 15.000 divorcios
hombre
no me refería a esto
no estática cualquiera
problema de seguridad
en la recogida
no ya ya ya
pero los principales conflictos
vienen por ahí
¿en serio?
claro
porque
yo me lo creo
me lo creo
papá y mamá
que no están
con buena relación
y ahí vienen los problemas
y esos problemas
se transmiten
a los profesores
y ahora
hay jueces
que están pidiendo
los registros
de con quién ha salido
el niño cada día
y esto se lo damos
automatizado
¿cómo de grandes
es este mercado?
¿cómo?
¿cómo de grandes
es este mercado?
pues mira
donde nos estamos dirigiendo
ahora
que ya no solo la salida
antes
cuando hacíamos
de 0 a 10 años
porque era solo la salida
ahora al entrar comedores
entrar transporte escolar
etcétera
esto ha crecido
estábamos
en un
en un
servicio
global
que tenemos
entre Europa
y Latinoamérica
de 400 millones
anuales
pero
ahora actualmente
además se nos ha incrementado
ya no estamos solo en colegios
sino en clubes deportivos
cualquier actividad infantil
estamos en 3.000 millones
de mercado
entre
Europa
y Latinoamérica
y una casuística
de la necesidad
que comentábamos
en Latinoamérica
nos están
llamando
sin que hagamos nada
y ya tenemos mercado
en Latinoamérica
porque
buscan una solución
de ese tipo
y hasta ahora
no ha existido
¿quién paga?
paga el colegio
el colegio
acaba pagando el papá
¿cuánto?
mira
en un promedio
de un colegio
de 500 niños
porque como segmentamos
¿vale?
un colegio
de 500 niños
que cojan
la mayoría
de funcionalidades
que es lo que acostumbra pasar
estamos en unos 10 euros
por niño
¿cuántos niños tenéis
en la plataforma
ahora mismo?
ahora unos 20.000
20.000
o sea
¿estáis facturando
2 millones y medio?
no
¿por qué?
ah no
200.000
porque era el año
has dicho
sí
es al año
pero no
no
porque además
la puesta en marcha
no ha sido a este precio
que estamos ahora
sino que partimos
pues primero hicimos
unas pruebas gratuitas
después empezamos a cobrar
3 euros
después 5
y ahora estamos cobrando 10
¿hay algún tipo de cole?
perdón
ya me callo
¿algún tipo de cole
o de entidad
a la que vendáis?
sí
de hecho
cuando marcamos
el servicio
obtener al market
nos dirigíamos
básicamente
a colegios privados
y concertados
y en ciudades
de más de 20.000 habitantes
porque el factor
nos conocemos todos
era un elemento
competitivo
para nosotros
entonces
de ahí vamos bajando
ya hemos empezado
a tener
poblaciones más pequeñas
pero no es nuestro objetivo
ahora mismo
¿la tecnología
qué tiene de especial?
o sea
si ahora alguien
nos está escuchando
y dice
esto lo voy a hacer yo
¿qué tenéis vosotros?
no
a ver
no hay una tecnología
especial
porque al final
o sea
es un protocolo
que tú programas
y no tiene
una tecnología especial
lo que pasa
es que como no se puede
patentar
en Europa
no se puede patentar
el software
lo que hemos hecho
es registrar
las pantallas
el registro
el registro de pantallas
es importante
porque ahí hay
una experiencia
de usuario
muy trabajada
y queremos
que por lo menos
no pasen
por la pantalla
que hemos diseñado
nosotros
y hay toda una serie
de características
dentro de la pantalla
que intentamos
que queden protegidas
por otro lado
hemos hecho
el registro de marca
por supuesto
y hemos depositado
el copyright
y aquí sí
no voy tanto por ahí
me da un poco igual
no nos van a copiar
nos van a copiar
seguro un día o otro
¿quién hace la tecnología?
es tecnología
es el programa
de Frontend
es un Reignative
¿pero quién
quién la hace?
nosotros
¿tú?
¿programas?
no, yo no programo
¿quién programa?
el programa
pues el CTO
el CIO
el Frontend
tenemos a un equipo
que está trabajando
¿tenéis un CTO
y un CIO?
sí
¿y son founders?
son founders
mira
¿y fundadores?
el Frontend
es founder
el CIO
es founder
y el CTO
tiene Phantom Shares
¿y qué diferencia
hay entre el CTO
y un CIO?
el CTO
es básicamente
el que dirige
al equipo
el que ve
pues las necesidades
como se van distribuyendo
y el CIO
es el que hace
la infraestructura
y el que está pendiente
de que el backend
esté todo bien construido
y que tenga escalabilidad
y que funcione bien
en este sentido
¿cuántos sois en total?
nosotros ahora somos
9
y a final de año
si cerramos la ronda
que tenemos abierta
y todo va en la línea
que queremos
vamos a ser 16
¿cuánto estáis levantando?
¿lo has dicho?
¿no?
¿cómo?
¿has dicho cuánto estáis levantando?
ronda, sí
580.000 euros
y hemos cubierto
205 aproximadamente
¿con quién?
Business Plan Jols
me damos el feedback
empieza César
vale
me creo que es un problema
que existe
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
haciendo foco solo en esto
no me ha quedado claro
si vais a cubrir
más superficie
con el producto
has hablado de
ahora se me ha olvidado
la palabra que has dicho
pero
como que hay alguna gente
que se encarga
de la parte curricular
me parece que has dicho
vuestra competencia
y vosotros os encargáis
de los procesos
has utilizado palabras
de ese estilo
no me ha quedado claro
cuáles son los siguientes pasos
porque si esto ya lo tenéis cubierto
al final entiendo que es como
desplegarlo en colegios
pero no me ha quedado claro
cómo evoluciona el producto
para acceder a un tamaño
de mercado más grande
si consideras toda Europa
y toda Latinoamérica
y son 3.000 millones
hostia
está bien
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
muchas veces
pues la partida
va por
un contrato público
¿no?
corréjeme si me equivoco
pero es más difícil
vender a escuelas
que vender a empresas
¿no?
no sé
¿qué opináis?
¿te puedo contestar?
no, luego ya no
yo como único padre
de los tres
obviamente
vas a un miedo real
o sea yo creo que
me acuerdo a principio
sí que me planteaba
oye quién va a ir ahí
¿no?
y tal
pero luego
viendo con el tiempo
las dinámicas y tal
también veo mucho
el factor humano
y esa intuición
que tienen
esos profesionales
¿no?
esos maestros
incluso el conserje
de un cole y tal
desarrollan una intuición
que creo que es muy valiosa
y no tengo claro
que querramos
industrializar
ahora mismo ¿no?
porque precisamente
es un tema tan sagrado
el
quién
quién permites
entrar en un cole
a quién le permites
llevarse a una persona
menor de edad ¿no?
sobre todo muy chiquitos
porque cuando ya tienen
diez años
ya van solos por la calle
casi ¿no?
pueden algunos
o sea que ya son más
pero los pequeñitos
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
y el bienestar
de los críos
que hay ahí
¿no?
no lo tengo
no lo tengo tan claro
y luego
la otra duda que tengo
es
si hay una tecnología
realmente defendible
y única
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 todos los padres
tenemos
donde comparten
pues las noticias
del cole
los menús
las tareas
que nos dan y tal
si no podrían incorporar
esto de manera muy fácil
¿no?
o sea como te bloqueas
contra una de las apps
que ya existen
o de comunicación
con padres
y estas historias
lo incorporan
no me he quedado muy claro
sumado a que vender
a escuelas
es un poco miserable
porque pues
normalmente van faltas
de recursos
¿no?
muchas de ellas
o no tienen profesionaleza
de la parte de IT
veo retos
que como inversor
no me encantan
como padre te diría
oye
con ganas de ver
cómo va
y quizá
yo que sé
presentarte a mi cole
y a ver si lo prueban
¿no?
pero
no tengo claro
la invertibilidad todavía
es una puta
escuchar el feedback
y no poder responder
¿eh?
pero luego
podría al final
sí
pero cuando ya
no grabamos
poco más
añadir
yo creo que esto que dice
Jordi es muy importante
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 deje 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?
y 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 todos los problemas
de seguridad
y porque no acabo
de ver este problema
que tenga que escalar
pero probablemente
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
aplausos