Bienvenidos a Startups y Tecnología. Podéis ver el podcast en índic.net para podcast y
escucharlo a través de iTunes, e-books y RSS. Bienvenidos de una semana más al podcast
de Indic. Yo soy Bernat Zarrero, CEO de Indic. Y esta semana estoy con Jordi Romero, CEO
de Factorial. Buenas tardes, Bernat. César Miguel Añez, director de Producto Factorial.
Hola, ¿qué tal? Yurio Blanc, director de Producto de Equipo. Buenas tardes. ¿Qué tal?
A ver, hoy tenemos un podcast interno con personajes clave de nuestra casa en donde
queremos hablar de producto. Es un poco nuestro ADN en Indic. Le damos muchas vueltas al
producto, a las metodologías, cómo hacer el desarrollo de producto, cómo construir
un producto, cómo llegar al mercado, cómo conseguir éxito a través de la propuesta
de valor y del producto en sí con nuestros clientes. Y hoy sería bueno comparar un poco
con dos productos que se parecen mucho, ambos B2B, que intentan ofrecer una solución de
administración a las compañías, administración de recursos humanos en el caso de Factorial
y administración de contabilidad y proceso administrativo en general en el caso de Equipo.
Entonces, explicándonos un poco en más detalle en qué consiste vuestro producto, cada uno
de los dos. ¿Empezó yo? Sí. Lo que estamos en Equipo es hemos
identificado que la gestoria, la gestoria contra el fiscal, que es en el caso de Equipo,
se limita sobre todo a la parte compliance, la parte de las obligaciones fiscales. Entonces,
todo este conocimiento que adquiere el gestor de la empresa, queremos que vuelva como una
serie de informes que queremos dar mensualmente, de momento, y en el futuro real-time, a la
empresa para que pueda centrarse en su negocio y le vuelva como un ciclo toda esta información
que ha generado para mejorar su negocio. Entonces, queremos que sea didáctico y que
le ayude a mejorar, o sea, todo porque estamos enfocados a pymes de pocos empleados donde
solamente no habrá un perfil, un finance controller que se dedique a analizar cada uno de los
ratios, pues ya vamos a ayudar a eso. Y factorial, pues básicamente también es un producto
que está enfocado a pymes, desde un empleado hasta 300 empleados, quizás más. ¿Estamos
pymes, no? Ya no se la pymes. Bueno, es una mediana empresa, ¿no? No es una gran empresa
de 5.000 empleados, obviamente, es una gran enterprise, pero sí que nos enfocamos, sobre
todo, entre el segmento de uno a 100, pero también nos usan empresas de 300 empleados
y sin problema. Básicamente, nosotros nos enfocamos en recursos humanos, nos dimos cuenta
de que es un mundo poco profesionalizado en cuanto a software, la gente básicamente
usa Excel para gestionar las vacaciones, la gestión con el gestor, en cuanto a nóminas
es todo por mail y muy casero, mail y llamadas, no hay centralización de los datos, por
lo tanto, el obtener información a partir de esos datos mediante informes es muy complicado,
porque unos datos los tiene el gestor, otros datos los tiene un Excel, otros datos los
sabe la gestora de recursos humanos de tu empresa. Entonces, lo que nosotros hacemos
un poco es centralizar todos estos datos en una plataforma única y a partir de ahí
sacar conclusiones mediante nuestra herramienta de reporting.
Al final hay un problema súper común cuando lo explicáis, se nota mucho. Tú has dicho
que las pymes no están muy profesionalizadas en cuanto a software en recursos humanos,
no están profesionalizadas en general en cuanto a recursos humanos, incluso la gente
de recursos humanos de las pymes muchas veces no tiene estudios específicos de recursos
humanos, es gente que hace un poco varios roles y en finanzas igual, las pymes hacen
finanzas con estabilidad y recursos humanos para cumplir con la ley, pero no les sacan
ningún valor fuera de que no les metan en la cárcel o que haciendo no te persiga o
seguridad asociada no te persiga o que el empleado reciba algo a final de mes.
Es por la tranquilidad porque tengo que hacer algo que me obliga la ley y lo hago, pero
no les sacan todo. Es un coste, no hay ningún valor añadido.
Exacto. Es curioso porque las pymes se encuentran
en un momento que es su peor momento y su mejor momento, su peor momento porque grandes
monopolios, grandes compañías están arrasando grandes espacios de la economía tradicional,
pues los Amazon, Google, Facebook, Saturnos están cargando sectores enteros de la economía.
Por otro lado, aparecen herramientas con las best practices que incorporan las best practices
de las grandes compañías que históricamente han llevado a cabo departamentos enteros
dentro de las grandes compañías y los están facilitando, democratizando a las pymes para
llegar a ser tan competitivas como las grandes compañías. Son dos fuerzas opuestas que al
final ayudan y destruyen a las pymes al mismo tiempo.
Pero aquí son de estos productos muy importantes. Hablamos de antena que el concepto de producto
se empieza a hablar con un famoso post de Ben Horowitz hace más de 20 años que se titulaba
Good Product Manager, Bad Product Manager, y dentro del apartado de Good Product Manager
hablaba del concepto de que un buen Product Manager es el CEO of the product, es el CEO
del producto. Entonces, ¿qué pensáis sobre este concepto de ser el CEO del producto? ¿Vosotros
consideráis primer o todo CEO del producto? ¿Ultimo decision maker del producto?
A ver, yo la verdad es que no entiendo muy bien a qué se arregla este concepto, igual
porque no he sido CEO nunca. Entonces, no sé qué implicaciones tiene. Y también hablábamos
antes de que al final se podría considerar que una empresa como la nuestra, todos los
equipos acaban siendo producto. Tanto marketing como ventas, todo es producto. Entonces, ser
CEO de producto y producto es todo, es incompatible con que la empresa tenga un CEO. O el CEO
del producto es el CEO.
¿Han entendido como último decision maker, el que toma las decisiones últimas sobre
el producto teniendo en cuenta los inputs de todo tipo? Porque hay muchos inputs que
acaban llegando producto.
Yo creo que más como un coordinador, más que como un CEO que toma la decisión es
como un hub o como alguien que está conectando con todos, entiende las necesidades de todos
y la intenta plasmar. A veces es una feature, a veces es una manera de trabajar, un workflow,
pero yo no lo veo tanto como la última palabra, sino como que encajen todas las piezas. Va
preguntando, va deshilando y encuentra respuestas.
Ya, no sólo eso tampoco, sino que al final las decisiones de producto las acaba tomando
el cliente.
Yo puedo ver.
El cliente que tienes o el que no tienes a veces.
Correcto.
Entonces, no sé.
El cliente veo difícil que tomen las decisiones de producto.
O sea, el cliente es el que tiene la última palabra.
El cliente es quien tiene el problema, que tú quieres solucionar.
Correcto, pero eso es el que decide si se lo está solucionando o no.
Si compra o no compra.
Es un input más.
No, no, es el input. El cliente es el input. No es un input más. Si el cliente te dice
una cosa y tú no lo haces, el cliente no te va a comprar y tu empresa no existe.
Muchas veces no sabe ni lo que quiere.
Tu producto no existe.
Pero cuando no sabe lo que quiere, al final tienes que juntar con otro input que también
es la visión de la empresa y encontrar donde convergen, intentando llevarlo hacia allí.
A veces fallarás, obviamente, y el cliente te lo va a decir, pero es un input.
Yo estoy totalmente de acuerdo con Oriol.
De hecho, no es producto cuando el cliente es del input. Es otra cosa. Es un servicio.
Se llama consultoría y realmente lo que hace es lo que te pide mal y te explica mal el
cliente.
Intenta satisfacerlo con un producto.
Cuando tienes el input del cliente, es tarde. Tú naces para solucionar un problema al cliente.
¿Qué quieres decir, tarde?
O sea que cuando realmente ves si el cliente te compra o no compra, ya es muy tarde.
Normalmente tú imaginas un segmento grande de mercado, intentas trocearlo, intenta encontrar
un low hanging fruit, una oportunidad más de corto plazo de este gran mercado, un pequeño
segmento al que satisfacer, y tú empiezas a solucionar el problema y vas viendo si
te va comprando durante el camino. No en el principio. Cuando estás imaginando tu negocio
y estás diseñando tu plan de negocio y tu producto.
Lo que tienes que intentar es que te compres al principio, cuando estás diseñando precisamente
tu producto.
Probablemente el primer cliente que te compre, o sea el segundo cliente que te compre, el
tercer cliente que te compre.
Hemos mezclado 15.000 conceptos, ¿eh?
Sí.
Todo es cierto, pero todo es matizable. O sea, el cliente lo que tiene es, o el mercado,
un problema.
Entonces, yo creo que el problema es que estamos, nosotros, la confusión es que estamos hablando
de qué te dice el cliente. El cliente lo que te tiene que decir antes de que tú existas
en siquiera, tiene que reconocer que existe ese problema. No te tiene que decir, necesito
un software que me haga esto, necesito un coche, porque si no no existe. Si no, si
ni siquiera es consciente de que hay un problema, es que no hay un problema.
Lo siento mucho, pero voy a volver a mi ejemplo favorito, que es el de Henry Forsey.
Ok, hay un problema, pero hay un problema, la gente tarda.
Creo que hacía las podcast que nos salía, ¿no?
Hacía unos cuantos, porque cinco minutos.
Pero no digo que la gente pidiera un coche.
Vamos a situarlo.
Te pagoje a esto, ya.
El siglo XIX, la gente se desplazaba tranquilamente y era muy felices con sus caballos.
No, tenían problemas, tenían problemas de avantar, tenían que parar a buscar paja,
se le ponía a cagar el caballo.
Su vida estaba amoldada, digamos, de la tecnología a los productos del momento.
Pero el coche solucionó algún problema o no?
Sí, eran caballos mucho más rápidos.
El coche solucionó un problema, y ese problema existía.
Pero no lo pedían.
El problema sí la solución no.
¿Dónde que el problema existía?
El problema tiene que existir, si no existe el problema.
Pero tiene que existir desde tu punto de vista, no desde el punto de vista del cliente.
Eso es muy importante.
Yo creo que la diferencia es problema-solución.
O sea, la persona de producto, o el innovador, o el inventor,
lo que tiene que ser capaz es de tener la visión
de que para ese problema hay una solución que nadie ha pensado antes.
Pero el problema, yo creo que no se lo tiene que inventar producto.
No, el problema tiene que existir en válidamente.
Pues sí, estamos de acuerdo.
El rol de producto es escuchar el problema
y tener esa visión de producto,
que es como un subset de la visión de negocio,
es un trozo de la visión de negocio,
es la visión de producto,
y tiene que hacer una propuesta
y ejecutar esta propuesta.
Entonces, ahí entra el rol de producto,
de que si es diseño, de si es hablar con clientes,
si es coordinar, como decía Uriol,
si es dar contexto a distintos equipos
para que los otros tengan más pequeñas ideas, etc.
Yo creo que entamos en más detalle en el rol de producto.
Yo creo que esto es la dicotomía típica que tiene el producto.
¿En qué momento el producto es un input,
se viene del input del cliente
o viene del input de la visión?
Uriol ha hablado de la visión.
Yo sé que expongo un ejemplo, no es falta ir al siglo XIX.
El mes pasado hemos sacado el NPS,
¿vale?
en Kipu.
Explica lo que es, por si alguien no lo sabe.
El NPS es la manera, bueno, es el Net Promoter Score,
es la manera de medir
cómo de satisfecho está el cliente
con la plataforma.
Es el típico mensaje, seguro que lo habéis dado mil veces.
Hay que puntuar entre 1 y 10.
Si punto a 9 y 10
es que es un
Promoter
Promotor
7 y 8 es neutral
y del 1 al 6 no cuenta.
Es de tractor.
Entonces,
con esto puedes identificar un poco
si la gente está satisfecho o no con tu producto.
¿Y la pregunta es si recomendarías ese producto
a conocidos colegas?
Si nos pasamos en el limbo del cliente,
cogemos
lo que nos dice el feedback del tractor
el 30% lo que nos pide
es tener las plantillas de las alturas más bonitas.
Nuestra visión es
dar una experiencia 10X
en el todo proceso administrativo
de una empresa.
Si nosotros nos guiamos por lo que quiere
el cliente,
lo que haríamos es, pues, quizá un sistema
de plantillas de facturación.
O sea, muchas veces el cliente, yo creo,
significa el problema, ¿no?
Cuando hablamos de producto, pensamos en un problema
y cómo lo solucionamos. El cliente, muchas veces,
cree que sea un problema y te da una solución
al problema que tiene identificado él.
Pero no es el problema real.
Claro, el problema real es que no sabe gestionar su negocio
porque no tiene los datos, no tiene las best practices
de cómo gestionar su negocio.
¿No puede solucionar eso?
Incluso sabiendo que el cliente no lo pide.
¿Y cómo se lo hacemos ver? Pues con un producto.
Y eso es el problema de la dicotomía del juego de la gallina.
Si no el producto,
convencerle de que puede solucionar mejor su problema.
Entonces, ¿no puede ser el input?
No, yo creo que nos hemos saltado otra vez
el matice. O sea, sí,
pero no necesitas un producto
para contestar esta pregunta. O sea, el producto puede ser,
no tiene por qué ser tecnología, que esto es el matice.
Pueden ser preguntas.
O sea, muchas veces, al principio de factorio,
por ejemplo,
por vergüenza, casi no, siempre íbamos
con producto funcionando y con el tiempo,
a medida de aprender más y tal,
cada vez vamos a más demos
o piches o historias sin nada que enseñar.
Y simplemente haciendo las preguntas correctas,
la gente ya se pone cachonda porque entiende
que hay un problema que lo tiene, que no lo había pensado nunca
y simplemente con las preguntas
que le haces, o sea, ¿cómo haces esto?
¿Y te ha causado alguna vez problemas?
¿Y qué problema está causado? Sólo con eso la gente
descubre que tenía un problema
que ya, que estaba, el problema existía
pero no lo sabía verbalizar, porque nunca se hacía esta autocrítica
o este análisis que nosotros hacemos
porque nos dedicamos a esto, ¿no?
Pero al final, yo creo que producto, la magia
conseguir arrancarle del cliente, del mercado
los problemas que realmente tiene
aunque no lo saben, pero
o sea, en el fondo lo saben, pero no se lo plantean.
La gente está ocupada pues dándole
de comer a caballo, ¿no?
O que sea, buscando una plantilla más bonita
para la factura. ¿Qué tiene la plantilla?
En realidad le preguntas, pero a ver, ¿tú qué cambio has hecho en tu negocio?
Ninguno. ¿Dónde estás gastando el dinero?
¿Qué cliente te da más dinero? Ah, no lo sé.
¿Lo gastan en plantillas? Claro.
Y volviendo al tema de Último Decision Maker,
¿vosotros sentís
no pressure teniendo que estamos yo regalados?
¿Qué sois?
¿Los últimos decisores
del producto?
Siempre usamos cosas a vosotros.
Respuesta correcta.
Sí, yo sí.
Yo tengo Último Poder Decisión
para tomar cualquier
decisión en cuanto producto.
Qué responsabilidad, ¿no? Sí, bastante.
¿Duermeis por la noche? Sí, tranquilamente.
Eso ya no me gusta tanto.
Siempre tomas las decisiones.
Yo no durmo tanto por tomar las decisiones.
Pero sí,
yo creo que
llegar a ser el CEO
o la última persona
de tomar decisión creo que es algo más moral
que se va cogiendo con la experiencia
y con la
experiencia que gana uno mismo
y con la responsabilidad moral que coges en el equipo.
Yo también llevo menos tiempo
al proyecto. Hay muchas cosas
que estoy aprendiendo al final
del negocio, de la contabilidad, de fiscalidad.
Pero creo que poco a poco
se me respeta más las decisiones,
se escucha más y yo puedo opinar más
porque también sé más.
No pregunta.
Porque ya hemos entrado a saco con producto, ¿no?
¿Cómo lo explicáis a vuestra tía
o a vecino, etcétera?
¿Qué hacéis en la empresa?
¿Qué es tu trabajo?
A otra persona que no esté aquí, ¿no? ¿Cómo lo explicas?
Yo soy director de producto.
A ver, yo lo que suelo decir
es que hablo con los clientes
y recibo feedback
y pues gestiono
también con mi rol actual
gestiono un equipo de gente
que
al final acaba ejecutando
una visión que viene
de la empresa por así decirlo, ¿no?
Tampoco lo he explicado mucho.
O sea, yo digo que hago cosas de Internet
y ya está.
Cuando mi abuelo me pregunta, no lo puedo explicar
más tampoco. Me dice, pero bien
y yo, sí, sí, todo bien.
Tienes trabajo y yo, sí, sí.
Pues eso es lo que importa.
Mi pareja todavía me presenta a su familia
como, he does things with computers.
O sea, ¿qué?
Creo que quedó con este estudio.
Yo...
he muy parecido, pero lo que intento verlo
es que, como que solucionamos problemas.
O sea, al finales entendemos que hay una problemática
y buscamos la solución.
Y también con el problema, no funciona la impresora
y...
Oca broma, que esta semana nos ha tocado
esto con un partner
y nos tocó mirar cómo funciona la impresora
pero bueno, al final, si con esto
consigamos que la factura esté
dentro de equipo, pues vamos y miramos la impresora.
¿Crees que el rol de producto
tiene que colgar del feo directamente
a la compañía? Hoy en otras ocasiones
se ha colgado de marketing o de tecnología.
¿Tenéis una opinión fuerte en eso?
Depende de la empresa, al final, ¿no?
O sea, si la empresa es
completamente enfocada en producto
como factor al equipo, yo creo que tiene que
quedar directamente
del cedo de la empresa.
Y creo que sí que no tendrías a temporal.
Creo que el producto empezó más en marketing,
porque era algo más de diseño,
que se hacía creatividades para campañas
o cosas offline, incluso.
Y creo que he ido ganando peso
en los años. Solamente depende de la empresa, seguro,
pero que lo que hay tendencia
es cada vez un que gane más
protagonismo.
¿Qué es producto? Es una pregunta difícil.
¿Qué es marketing? Todavía más.
Marketing también lo es todo para mí.
Al final,
una pregunta.
¿Qué es producto? Hay una discusión
típica aquí, en la oficina.
Esto es producto.
Antes hablábamos, como ejemplo, el precio, el pricing.
Una landing page.
Frase de la home. La frase de la home
es producto, es marketing.
Es el CEO, es la junta de accionistas
o es el becario que está haciendo copies.
¿Qué entran
dentro del paraguas de producto? Creo que en equipo
más fácil, porque en equipo no hay marketing.
O sea, producto ha absorbido marketing.
En equipo, la respuesta es sí.
Copies, el claim,
las ilustraciones, todo
es producto. ¿El pricing? El pricing
es producto, aunque nos hemos metido menos
de lo que deberíamos, es producto.
¿El mensaje que manda customer support
automáticamente cuando mandas un ticket?
No, no hemos
llegado aún, pero por ejemplo, todo el proceso de
certificación, todo lo que hay que decir, todo eso
sí, la valoración que se hace, antes, después,
todos los mails. ¿Qué significa eso, el proceso
de certificación en equipo? Vale.
Una pregunta.
Espero que te haya lo sepas.
Qué buena pregunta.
A ver,
nosotros, como he dicho
antes, intentamos
que conseguimos solucionar
contable y fiscal.
Entonces, ¿cómo lo hacemos esto?
Sabemos que nuestro software hace una parte
o soluciona una parte, pero aún
a día de hoy nos tenemos que apoyar con un gran
enjambre de gestorías que están
por todo el país.
Nosotros lo que hacemos es identificamos las mejores gestorías
que hay en el país,
vemos como que software usan
y lo que hacemos
es como un proceso de certificación
de consultoría para ayudar
a que sean más rentables y más escalables.
Y que dé mejor servicio.
Y que dé mejor servicio. Gracias a ello, serán
más eficaces y podrán escalar.
Eso es un proceso que llamamos proceso de
certificación.
Dura varios meses, entre dos y tres meses
incluye varias visitas de nuestro equipo
de expertos en Contabilidad y de
procesos en sus oficinas
y conseguimos, como he dicho,
rentabilidad, escalabilidad
y que dé un servicio bueno a
nuestros clientes. Todo este proceso
es producto. Y yo sé que os decía antes,
no es una feature, es
un drive. Es un drive,
es una hoja de contrato, todo
esto. Se hay que acabar haciendo algún día.
Es un servicio en relación con el cliente.
Y es la marca.
Es la parte más importante de la marca.
Es el plan maestro de certificación
que decíamos alguna vez.
Y eventualmente será una feature
y quizá acaba haciendo un scoring
que sale en la web y que te
promociona antes las mejores
gestorías del país de momento.
Es un drive
compartido, como os comentan, de mejorando.
Y cuando alguien quiere, alguien que
está en el terreno, un experto que
haga lo que funciona, pues nos da feedback
a producto, lo comentamos
o cocinamos y sacamos una versión
de ese documento.
Antes hablábamos de
LNPS, Net Promoters Core,
como la medida de calidad.
Y a la vez, la medida de calidad
es la mejor métrica, o una de las mejores
métricas para medir el producto
y una de las mejores métricas para
medir la marca. Porque al final, en nuestro
tipo de productos, ¿qué es
una marca si no el servicio que damos?
Lo contenta que está la gente con
nuestro servicio. Al final,
es todo varias caras de
una misma moneda. No dos,
más caras.
Vale, seguimos avanzando.
¿Qué equipo tenéis?
Vale, ahora mismo
no. Aquí entra
la discusión también de si
tecnología es producto o no.
Yo considero que es separado, porque
tengo el objetivo de hacer más cosas, aparte
de producto solo.
Entonces, en mi caso,
en el caso de Factorial,
somos tres diseñadores en total,
incluyéndome a mí,
diseñadores de producto, full stack
producto,
y bueno, full stack producto, pero diseñáis
cómo.
¿Qué pintáis?
Dibujitos.
Las cajitas estas.
Yo cada vez menos,
sí que sigo abriendo Figma
de vez en cuando,
pero porque tengo
un rol más de priorizar
en que se trabaja y en que no,
gestionar el propio equipo
a one-on-ones con los diseñadores
y tal.
Y no es solo pintar cajitas,
sino, o sea, cogemos el proceso
de principio a fin.
Yo no entiendo un diseñador de producto,
o sea, que se encarga solamente de una parte.
Al menos una empresa ha estado como la nuestra.
Y te estoy hablando
desde el tener la idea original
de una feature, por ejemplo,
hasta el momento en el que
se hace el deploy y el post-deploy,
que es el mirar si la feature ha funcionado.
Todo esto, en nuestro caso,
el owner es el diseñador
que se ha encargado de hacer esa feature.
¿Puedes preguntar, como complemento la pregunta,
qué perfiles tenéis las personas
que estás en el equipo?
O sea, que habéis hecho antes, o que habéis estudiado.
Hay un poco de todo.
Yo personalmente
no estudié.
Sabía lo que quería hacer desde
temprana edad.
¿Y según lo que te decía?
Me lo decía, déjate de tonterías
y vete a la universidad.
Y luego, por ejemplo,
Marc
es licenciado en arquitectura.
No sé ni cómo va lo de los títulos del arquitecto.
Es arquitecto.
El arquitecto nunca ejerció
y luego es carpintero
y ahora aquí pues es el project designer.
Lo tenía clarísimo como tú.
Sí, exacto.
Y Jonathan, por otro lado,
también es muy autodidacto.
¿Pero es usted que venís más del mundo
del diseño?
Más que de producto.
Sí.
Sí, diría que sí.
Yo siempre tengo un perfil un poco híbrido.
He trabajado también haciendo front-end.
Entonces también la parte un poco más técnica.
¿Te gusta contar qué programas?
Me gusta contar qué programas
en mis ratas libres.
En la intimidad.
Son dos preguntas.
La primera es
qué incluye o cómo está formando el equipo.
En nuestro caso, en el caso de equipo,
hay que formarte de producto.
Producto es
diseño
y tecnología y marketing.
Porque ejercemos...
Sí, es que es el CEO
de producto.
España 25, quizá.
Y nosotros
unos perfiles
de la gente más que es pro designer.
Yo lo soy
diseñador.
Yo vengo de la mundo de tecnología.
En el programa mis ratas libres.
Cuando me dejan.
Y los demás, hay Marcos
que es deficio diseñador.
De hecho coincidió.
Hay un podcast de verano interesante.
Muy bueno.
Me han dicho.
Y Nadia,
que estuvo 12 años trabajando en la farmacia
y en el último año
dijo que quería cambiar
al diseño y hizo un ironhack.
Nosotros la conocimos después
y vimos que tenía mucho talento
y estaba en el equipo.
Perfiles bastante curiosos.
Todos los que tenemos aquí de producto.
Sí, pero parecía que estamos contratando diseñadores.
Así que si soy diseñador o conocéis diseñadores
contactadme.
www.cesararroafactor.com
Es como spoiler el día 1
empieza un tercer diseñador.
Muy bien.
A ver, otra pregunta.
¿Cuál es el ciclo
que hay
desde que se...
¿De dónde sale la idea?
Primero todo.
¿Cuánto tiempo pasa
y qué pasa entre medio entre qué esta idea
se produce en una funcionalidad
en producción que la gente, el usuario
o el cliente puede utilizar?
Ya.
Obviamente depende mucho
de la futuridad que estamos hablando.
Sobre todo en cuanto a timing.
Porque sacas una feature que te lleva a hacer una semana
y tiene un impacto brutal
para hacer dos meses
y el impacto que tiene
es muy pequeño.
Entonces bueno,
en nuestro caso
las ideas de
qué hacer y qué no hacer
vienen de dos partes.
Por un lado, nosotros nos reunimos
constantemente
con todos los equipos
y recibimos el feedback que ellos tienen.
Por ejemplo, Ventas siempre
viene con feedback sobre
qué necesitan para poder cerrar más
deals.
Saccés, equipos access
es nuestra
conexión con el cliente, más directa
porque son los que al final
son el punto de contacto del cliente con Factorial
y son los que más feedback
tienen, como es lógico.
Y luego los operaciones también
tienen un montón de feedback
sobre todo en cuanto a herramientas internas
y ellos muchas veces nos vienen
con soluciones y esto es algo que nosotros
tenemos que gestionar y tenemos que llegar
al problema real.
Esto es otro tema.
Y luego por otro lado, nosotros también detectamos
donde están los bottlenecks
de producto.
Entonces también proponemos soluciones
pero siempre intentamos buscar
el problema. Siempre
que se nos ocurre algo nuevo
hacer, acabamos hablando con el equipo
y vemos si realmente tiene ese problema
o no.
Si tiene sentido solucionarlo
simplemente es algo que a nosotros nos molestaba
y nos hemos dado cuenta y ya está.
Entonces es un poco eso.
Los diseñadores de producto siempre
tienen que tener algo de
mucho de visión
de cómo podrían ser las cosas
en el futuro
y tiene que estar influenciado
por el feedback del cliente
sobre todo y también el efecto del equipo.
¿La visión? No.
Bueno, también
pero sobre todo
habló ya más de las cosas
del día a día, semana a semana, mes a mes
tiene que estar siempre influenciado por el cliente.
Pues al final si
cosas en producto que no tiene ningún impacto
en el cliente, no tiene ningún sentido.
¿Y si traen reuniones concretas
que hacéis con el cliente
con la gente de
sexés lo hacéis periódicamente
espontáneamente?
Con el cliente sí que es más espontáneo.
A veces es iniciativa
de sexés, a veces es iniciativa nuestra.
Por ejemplo
sexés nos viene y nos dice
¿Veis a ir a este cliente? ¿Quieres
enseñarle algo? ¿Quieres
preguntarle cosas o lo que sea?
Y nosotros pues vamos a ver al cliente
y en otros casos
somos nosotros los que estamos trabajando
en una feature nueva y preguntamos
a sexés ¿Hay algún cliente que podría estar
interesado en esto? ¿Podemos ir a hablar con él,
enseñarle una demo, enseñarle
cosas?
Y ya está, no sé si eso contesta.
Y en nuestro caso si
me dejáis primero explicaré un poco
cómo estamos organizados, porque
como es un mix, como nos he contado
que tecnología y diseño, antes trabajamos
de una manera más tradicional, orientado a plataforma
¿No?
Backend, Frontend y diseño y ahora lo que
hemos hecho desde diciembre es nos hemos unido todos
y hemos creado tres equipos interdisciplinares
donde hay un diseñador, un Frontend y un Backend
en dos de los equipos
y un tercer equipo que es 100%
tecnología. Esto nos permite
tener velocidad, porque nos hemos dado cuenta
que teníamos un problema a la hora de entregar
y
que había muchos clientes de botella, producto
y o entre ellos ¿Vale?
Entonces lo que hemos hecho es, hemos empoderado
al 66% del equipo
para que tengan poder
de decisión y sean sus ceos
de sus mini productos
para ver más.
Y un tercer equipo, puro
tecnología, que lo que va haciendo es
va quitando la deuda técnica
que se puede generando y si puede va avanzando
un poco el terreno para los dos equipos, que nunca se
pare. Un equipo
se han focado al cliente final y otro equipo
se han focado al partner certificado
la asesoría.
Nosotros tenemos varias dinámicas
para coger este feedback
con ventas,
con adquisición, con el equipo
de partners, que se ha equivocado con las
asesorías, y
generalmente
tenemos una reunión de sincronía
que es que ya en los equipos, conmigo
intentamos
encontrar el problema real
y lo plasmamos en un roadmap, que es lo que ejerzo yo.
Ya hago final de guardia en este roadmap
intento llevarlo lo más a día posible
y discutiendo si hay problemas o no.
Intentamos pactar la entrega de ese mes.
O sea, el objetivo que tenemos es mensual
e intentamos tener una entrega mensual
y dividimos cada problemática
en un equipo, pero sólo
pactamos el enunciado. Luego este equipo
intenta encontrar posibles soluciones
y vuelven a asentarse
con los departamentos o áreas
que más le da ayudar.
Una cosa que no habéis mencionado ninguno de los dos
como input
de en qué dedicar
los recursos de producto de tecnología
son datos o métricas
o tenéis algo
al respecto. Se toma alguna decisión basada
en métricas o es todo puramente
cualitativo
simplemente opiniones y
decisiones.
Ahora ha sido otra pendiente.
Tenemos pocas métricas
y hay un proyecto para
mejorar las métricas que tenemos.
Ahora hay mucha
decisión
y muchas fichas que empieza ahora
es en base a opiniones y en base a la visión.
Tenemos que ir hacia allí
y como fichas nuevas pocas métricas
nos lo apoyar.
Entonces, está claro que tenemos que
empezar a medir cosas.
De hecho, uno de los fichos es que decía
que hay que evaluar la salud
que tiene un partner.
Esto es una métrica.
Estoy que construirlo primero
y podremos ver en qué parte
peca el partner
para identificar si falta producto.
Y por lo menos es el mismo.
Pensando por ejemplo Uriol en tu experiencia anterior
justo antes de equipo
tuviste en Billy una empresa
de una red de
advertisement
con trillones, no sé qué unidad
y puntos de datos.
200 millones al día.
Esos son los data points que teníais
para tomar decisiones.
¿Usabais estas métricas para tomar
una decisión de producto?
Sí, 100% no he orientado a data.
O sea, la principal
guía de las decisiones de producto eran las métricas,
tú dirías.
Sí, también había decisiones
de cada visión. Hay que hacer
un formato nuevo.
No te puedes hacer métricas porque aquí no hay métricas.
Para mejoras
era un bonde muy importante.
En ese sentido es una diferencia
importante entre
la forma de operar en Billy
y equipo?
En cuanto a
datos sí. En cuanto a metodología
yo creo que
aquí es mejor. O sea, hemos implantado
una metodología que se empodera
mucho a los equipos
y que permiten tomar decisiones. Al final
si hay tres cerebros pensando
compartiendo y discutiendo todo, yo creo que es mucho mejor.
También estás trabajando en terreno inexplorador
como tú decías. Clichos nuevas,
espacio nuevo. Hay poca métrica.
Muy poca métrica. Y en el caso de Billy
no había una ficha visual
en algoritmo. O sea, no había
ni lo que decía, hay que hacer
tal cosa. Al final es
si mejoras
la tabrietecesión de IP por país
por qué tal, pues esto al final es una ficha
tecnológica. Aquí sí que
necesitas métricas.
Entonces la reunión hay semanal que tienes.
Luego tú tienes una reunión
dos reuniones al mes
con stakeholders de todo tipo, donde intentas
brainstormar más temas de
visión y de estrategia.
Exacto. O sea, esta iso es semanal. Primero
es para ordenar la cabeza y ver si
bloqueos, cambios de impunidades
y luego cada dos semanas
lo expolemos a los demás stakeholders.
También para contrastar con otras
cabezas. Porque al final acabamos discutiendo siempre lo mismo
y si ves ahí presentarlo
más y conseguir cita con tantas de mejor.
Para que si el feedback loop sea lo más
constante posible.
Y hay un concepto
que se utiliza mucho que es el tema del MVP
el mínimo viable product
el proyecto mínimo viable.
Esto lo compráis
este concepto
y cómo lo definís y cómo lo trabajáis en el
día a día.
Básicamente todo lo que sacamos en Factorial
es un MVP
que luego mejoramos siempre
pero empieza siendo
siempre.
Empieza siendo un MVP
porque al final
puedes tener la idea mágica en tu cabeza
de una feature que la va a apetar
y que va a ser la hostia y tal
tarda 6 meses en desarrollarla
la sacas y te asco te has perdido 6 meses
esto intentamos evitarlo
lo máximo posible y
la forma más eficiente de hacerlo es
mediante un MVP
por ejemplo si tenemos una
feature muy grande como por ejemplo la
que estamos desarrollando ahora que es control
horario
intentamos escalonar
las realices del producto
para intentar aportar el valor
en el momento en el que nosotros creamos que tenemos una feature
que aporta suficiente valor como para sacarla al cliente
lo hacemos y planificamos
de cara a eso y luego vamos iterando
sobre ella porque es la única forma
de saber
y sobre todo de construirla bien
al final si tú construís una versión muy simplificada
pero que aporta valor al cliente
recibes el feedback del cliente
es mucho mejor porque va a estar mucho más
informada por el mercado que una feature
que cierras una cueva durante 6 meses
y la sacas
pensando tú en tus propias conclusiones
esto es un error
y al final puedes obtener feedback cualitativo
haciendo demos con pocos clientes
y tal pero hasta que no la sacas al grueso del mercado
al grueso de los usuarios en este caso
no sabes como va a
performar
para extender este concepto
leer de line startup
un poco anticuado
no es pasa que a veces esto se extrapola
y la gente crea una mierda
y utiliza el argumento
de que es un MVP
y esto el feedback que produce
es útil para seguir desarrollando
es muy fácil que pase esto
tienes que ir con mucho cuidado
¿cómo evitas eso?
hablando con clientes
en este caso el feedback cualitativo es muy importante
el llevar la primera demo
que tienes
demo en prototipos
de Figma en nuestro caso
directamente al cliente
yo creo que hay una iteración sobre el MVP
como concepto
que un tío
el coach de Spotify
hizo popular
que es que rompe el MVP en tres cosas
porque vaya vol para qué
vaya vol para salir a bolsa, vaya vol para la NASA
o vaya vol para una startup
con un concepto económico
y mínimo es super relativo
al final
lo que propone es
romperlo en tres fases
el minimum testable product
el minimum usable product
y bueno de hecho el le llama earliest testable product
earliest usable product
y earliest lovable product
y el primer testable es
lo primero que le puedes poner a la cara a alguien
y ver qué hace con ello
aunque no sirve de nada, literalmente dice
si añade un valor es de casualidad
lo único que queremos es, a ver qué nos dice
o sea, esto estaría muy bien si funcionara
o esto tiene que tener esta funcionalidad
o ese botón o ese no sé qué
y es lo primero que te empieza a dar feedback
por esa, es lo que hay que hacer
que puede que salga una mierda
pero ya esa mierda tú estás diciendo
claramente que no sirve de nada, que sólo es para ver
que te dicen y te da feedback
luego el usable, y así que sería como yo creo el MVP
como lo entendemos la mayoría de gente
que es, no es la hostia
pero ya es mejor que nada
y lovable, que es donde en teoría siempre tendrías que llegar
y no quedarte en el MVP
es algo que no sólo soluciona algo, sino que es la hostia
y que realmente la gente pues
te recomienda en el NPS
o usa tu producto y se comierte en un inicializador
etcétera, etcétera
yo creo que esta es una buena manera de separar el MVP
porque sí que es cierto, reconozco
que muchas veces en los años
un montón de años que llevamos haciendo producto
hacemos muchos MVPs
porque es lo mejor para primer paso
porque luego pasa otro tren
pasa otra gran oportunidad
y el MVP se queda ahí y tú te monestas a otra cosa
y nunca se convierte en lovable
se queda en usable
como mucho y nunca
nunca es lovable, yo creo que este es un problema
de la velocidad
en la que cambia el contexto para una startup
si, dicho en kipu
bueno, pues escribo totalmente lo que dice
lo que dice él
al final los otros en kipu
como también nos hemos marcado
el reto de entregar valor
cada mes, nos pasa esto
es como decimos que es MVP
para los otros MVP
es que tiene que abordar valor mínimamente al cliente
mínimamente
sí
bueno, eso es la M
pero sí, o sea
tengo que decir que no siempre llegamos al mes
porque estimarlos es muy complicado
y a veces nos hay intratrasos
lo típico de tecnología
pero el objetivo es hacer ciclos muy cortos
para enseñarse al cliente
conseguir feedback
también en ese tiempo
se aprende esas necesidades
entiendes que hay otros problemáticas
y vas haciendo, y claro hay que luchar contra cambios de prioridades
esto no, como lo hemos conseguido hacer
con lo que se dice de los equipos
por ejemplo, tenemos el equipo que está enfocado
a perder las ganancias
que es un titular muy grande para una empresa
hay que hacer informe y perder las ganancias
pues el primer mes
se hizo una entrega
una MVP
pero era Testable, Usable o Loveable
las tres
todo era Loveable
sí, la gente le ha gustado bastante
pero claro, faltaban features
ahora mismo era mínimo
pero era Loveable también
el acabado, el diseño
era pequeño
había una feature
la famosa homología esta de patinete, bicicleta, moto, coche
era un patinete, pero un patinete chulo
hacía lo que decía
un informe para las ganancias
y era bonito, porque es el mismo
que tú exportaba el partner
de su software de anterioridad, nosotros evitamos bonito
y desplegable
ahora estamos haciendo una feature que es que lo puedas comparar
con otros años
pues eso es otra feature que también serán MVP
y así iremos construyendo
pero claro, nosotros desde el producto tenemos que luchar
que no entre ahora otra feature
que obligue a parar este desarrollo
y que se quede con algo que
está muy lejos de lo que queremos
eso es parte de nuestra
de intentar compaginar
y esto pasa mucho en el producto
el postrelease
y ya lo he hecho
y ahora pasa esa otra cosa
¿cómo conseguir que las cosas de evolución
crezcan?
esto es la primera versión
los productos están llenos de MVP
que se han quedado MVP para toda la vida
¿cómo hacéis eso?
¿cómo cultiváis?
en nuestro caso nos dimos cuenta de este problema
precisamente en factorial
y ahora estamos probando
un nuevo proceso de producto
en el cual, antes de empezar a desarrollar
la feature o lo que sea
defines unos objetivos que quieres conseguir
y pueden ser objetivos internos o externos
en el sentido de
con esto quiero conseguir
equismas clientes
o quiero reducir el bottleneck
tal en tanto por ciento
etcétera
que se considera
deployado
hay una parte de seguimiento de estas métricas
y de definir si
si se han conseguido los objetivos o no
yo creo que hay un concepto interesante
que de hecho hay un tema que
cuando nosotros hace unos meses
hicimos un cambio de proceso de entrega
de producto
que hicimos fue reunirnos con gente de producto
CEO's
directores de producto etcétera
de varias startups invertidas por los mismos inversores que nosotros
vamos con type form, con content full
con on track también
y con alguno más no me acuerdo ya
y uno se habla mucho de los OKRs
que es un método de definición de objetivos
y indirectamente
después de estudiar más a profundidad el tema de los OKRs
hay un concepto que es muy simple
pero me va a decir relevante para producto
que es que siempre hay que ir a buscar outcomes
una feature
para tener la feature no sirve de nada
porque hemos hecho la feature
para subir un 20% en el rato de conversión
hemos subido un 20% en el rato de conversión
porque si no nos hemos hecho nada
hemos perdido dos meses o una semana o dos días
y no hemos conseguido nada
y yo creo que esta es una cultura
que ni OKRs ni historias
esto es más la cultura y los principios
de las personas de conseguir siempre ir a buscar outcomes
en lugar de outputs
para mí es un buen recordatorio
el objetivo que hemos puesto es un output es un outcome
es algo que realmente nos ha impactado la empresa
o la vida de nuestros clientes
¿cuál es la relación que tenéis
con vuestro CTO
y la tecnología?
¿dónde acaba y dónde empieza vuestro trabajo?
por fin, son proyectos tecnológicos
en nuestro caso
tengo que decir que nos conocemos hace varios años
y
todo lo que sea tecnología
yo me desentiendo porque
se sabe mucho más que yo
y yo no quiero entrar tanto en el detalle
de hecho como de velo perto
tengo que hacer un pequeño ejercicio
de no entrar en el githab y todo
y a veces me veo entrando en el githab
pero de lego totalmente esta parte
yo me reúno muy veludo con él
y estamos...
¿cuára veludo?
pues diariamente, aunque no se nos renamos
hablamos
todo el rato
y...
toda la parte de tecnología
al final es el líder moral en el equipo
tampoco quiero quitar ese espacio
porque ni podría
pero al final
él es el que lleva un poco las rendas
yo le explico un poco el reto
ya no se lo explico yo, se lo explica cada uno de esos equipos
y
el desarrollador en cuestión
que va a hacer una funcionalidad
toman las decisiones y las comparte
con el RIC
en tu caso
en nuestro caso
llevamos en factorial desde el principio
ambos, pao tanto pao como yo
obviamente
lo de que les fa un derita
entonces
yo estoy muy agradecido de que
creo que nos complementamos muy bien
y además estoy muy agradecido de que pao
siempre tiene
la visión de producto también dentro
entonces es muy fácil hablar
de todos los temas
que toca producto con él
y también es muy fácil
la parte
de pasar de lo que producto hace
a tecnología
porque
al final él es la conexión entre producto
tanto él como yo somos la conexión
entre producto y desarrollo
y el hecho de que él tenga
esta
parte de visión de producto que no siempre se da
en muchos casos el CDO
solamente se encarga de tecnología
coincida con la tuya siempre
la visión de producto
no siempre, para nada
para nada
de hecho
pero es bueno que haya desacuerdo
porque es una persona más que te hace
challenge de las ideas que tú tienes
y es una persona que tiene mucho criterio
y además la tecnología
influencia mucho en el producto porque
en el caso de Uriol quizá no porque él tiene mucho conocimiento tecnológico
y así que tú eres programador también
con todo el respeto a tus habilidades
de programación tú puedes tener una idea
o hacer una propuesta que sea
veinte veces más difícil de ejecutar
que otra opción
y ni tú ni Marguerite
quizá os habéis podido plantear esa
decisión y si una persona de producto
simplemente coge el SP que se pone a hacerlo
quizá acabamos de perder ocho semanas
de tiempo y quizá si hubiese dicho oye se te ha ocurrido
que haya otra opción que quizá no requiera
hacer X refactors modelado
de datos, tiempo real
etcétera etcétera
y dices ah bueno pues no es
la hostia pero es casi igual de potente
y es ocho veces más rápido de hacer
pues hacemos esto y luego nos planteamos
y además está influenciado por un buen criterio
y eso pasa mucho, yo creo un factor y a eso se ve
que hay mucho el... porque no todos son base de datos
a veces el propio Frontend
la UI hay decisiones que decir oye
eres consciente que me acabas de
obligar a reescribir todo Frontend
y a veces es sí, soy consciente
y lo he pensado mucho y si quieres lo discutimos
hay que hacerlo y a veces tienes razón
quizá ahora no toca
nosotros
tenemos un sistema de diseño
que es lo que gobierna todo el diseño de la aplicación
y en muchos casos
nos inventamos componentes nuevos
y viene Pau
y nos dice esto no lo podemos hacer con este otro componente
que existe y nos obliga nosotros mismos
a ser estrictos con nuestro sistema de diseño
y también agiliza
los tiempos de desarrollo que no tienen que crear un componente nuevo
otra dicotomía
donde he visto yo históricamente
saltar chispas de las buenas
que es entre adquisición
y producto
marketing adquisición
SEO
y producto
como gestionáis eso
mi visión en esta
parte es que
producto está pensando siempre en la parte más
de estrategia, de visión
pero
hay una particularidad que no tiene un objetivo
de este mes
y eso es muy cómodo
es que la persona adquisición se juega cada mes
partido a partido su objetivo
entonces dice ostia, eso está muy bien
pero ¿por qué no me metes
esta keyword en este título
porque me va a ayudar a posicionar
o porque no hacemos esta landing
que me va a ayudar a aprovechar esta oportunidad
porque está pensando en el corto plazo
que es importante pensar en el corto plazo
si no las empresas no crecen
¿cómo gestionáis eso?
al final
es encontrar el balance
yo creo que
producto tiene que
acatar todo lo que adquisición dice
ni al contrario
esto es una respuesta
al final
es
ceder en algunas cosas
que igual a ti te importan personalmente
y también darte cuenta de lo que te importa personalmente
y separarlo de lo que es realmente importante
para la empresa porque en muchos casos
sobre todo con diseñadores pasa mucho
que hacen una cosa
y piensan que es lo más importante
lo más importante, lo más importante
pero al final te das cuenta
de que lo más importante para la empresa
no es necesariamente lo que es más importante
para ti
¿qué significa para ti?
hay mucho amor propio
en este tipo de trabajo
y departamentalismo también
es un gran problema
producto necesita esto
es tan pequeño
que necesita factoria
al final yo creo que viene
del hecho de que
ambos equipos son creativos
y al final tu cuando haces algo desde cero
te enamoras de ese algo
tienes que estar enamorado de ese algo
y si bien otra persona
con otro input de fuera que tu no habias considerado
es difícil el darte cuenta
de igual mi solución no es la mejor
porque no estaba pensando en adquisición
entonces por eso digo
al final
no es
adquisición siempre lleva razón
ni producto siempre lleva razón
sino la mezcla de ambos
y lo que es mejor para la empresa
es lo que debería hacerse
yo creo que es
el gran derecho de producto
es que cada decisión que se toma
tiene que aportar algo a corto
a medio y a largo plazo
y tiene que estar compensado porque si no
no puedes desatender
porque quizás también entra lo que decías
de los egos y todo
y como lo hacemos nosotros pues nosotros
identificamos que este equipo
que os decía que está enfocado al cliente final
su roadmap
competía en cambiar
un meta de la web pública
con avanzar una superfeature
de pedas y ganancias
obviamente aquí siempre ganaba
el pedas y ganancias
entonces como decidas crear un tercer equipo
que se encargue del funnel
desde que llega el lead hasta que se registra
formado por un diseñador
y enfronten
y extrae el otro equipo
que se encargará desde que soy cliente
bueno todo el flow
desde que soy cliente que soy todo el pedas y ganancias
y otros informes
se orienta parte del producto más de la táctica
a mes
y aquí sí que podemos medir
porque podemos medir
si con lo que vamos haciendo
este equipo están consiguiendo convertir más
más barato
yo tengo una pregunta con los equipos
¿van rotando?
es una pregunta
de momento no lo hemos pensado
pero lo hemos leatido ya un par de veces
está claro que rotar
hay este switching cost
que puede perjudicar pero también puede favorecer
porque es mente fresca
eso me pongo
sombrero de persona que ha hecho producto también
en red booth
y en typeform de hecho lo estuvimos hablando con la gente de typeform hace poco
tienen el concepto de equipo
por temas, en el caso de typeform es por partes del funnel
en el caso de red booth
era partes del producto
y había que rotar
porque si no había especialistas
y entonces una persona en las vacaciones
y esa área de tecnología
de conocimiento desaparece
y también la gente si no se queda
y rotábamos bastante frecuente
unos meses como máximo
lo que te estabas en un equipo
esa es parte de la T2
pero hay una fecha para hacer la rotación
pero se está hablando de si tiene sentido o si no
para que todo el mundo quiera hacer
temas estratégicos
desde cero una feature de puta madre
versus hacer cambios en las landing
o arreglar bugs
de hecho hay un equipo que está arreglando bugs
también queremos que
como gestionáis
si hay una feature
que afecta varios puntos
o a varios equipos
eso que le decía, al final es hablar mucho
ahora es mucho y solamente hay cosas
por ejemplo
una parte de la feature que está haciendo el equipo
afecta directamente al otro
pues no los pisemos
pero el otro equipo igual tiene otro roadmap
si pero problemas cada día
y semanalmente nos lo presentamos
aparte cada equipo hace daily
cada día y yo voy entrando
de manera random en los 3 dailys
directamente por su lado
entonces esto ayuda de que yo pueda anticipar
si alguien va a tocar una parte de la aplicación
que es tanto que uno de los otros
y cada día entro un daily
en repústas hacíamos una cosa muy parecida
última pregunta y acabamos con eso
hay mucha brevedad en la respuesta
¿qué herramientas, qué lista de herramientas utilizáis
en vuestro día a día?
nosotros, bueno
yo y el equipo
usamos Airtable principalmente para gestionar
todo producto
es un producto fantástico
realmente soy fan número uno de Airtable
porque hemos podido
reflejar en un producto
el
el ciclo de cómo desarrollamos
pero perfectamente
muy elástico, muy flexible
totalmente, es fantástico
es un excel básicamente
es un excel pero la experiencia de usuario
es increíble, realmente es un producto
que más de herramientas?
Workflowy, sorprendentemente
que es una herramienta muy simple
para hacer listas infinitas
empecé a usarlo
y puse toda mi vida
ahora mismo realizo toda mi vida con Workflowy
es fantástico
y todo el equipo lo está usando también
así que mola
es la polla
y ya está
bueno y luego Figma para diseñar
y Slack para
perder el tiempo y los memes
y todas estas cosas
la cultura
es tan fan de Airtable
que se lo presentó a dos del equipo
en Trigia Marcos
y vinieron los dos aquí
hay que pasar a Airtable
César tiene eso
es muy pesado
te voy a probar Workflowy cuando salga
es la hostia, yo también me he convertido
y Airtable también
tenemos parte del equipo trabajando con Gira
parte del equipo trabajando con Asana
por la herencia recibida
de parte del equipo
y entonces
vimos Airtable y vimos que solucionaba
mucho nuestro día a día
nos hemos separado en varios meses, estamos muy contentos
y más a la bienzas pues lo mismo
Slack para memes
Sketch para diseñar
y Docs
muchos Docs
oye, muchas gracias
a todos por vuestra experiencia
como líderes de producto
y empresas de producto relevante
de nuestro país, obviamente
y nos vemos la semana que viene
un poco