Bienvenidos al podcast de INNIC, número 26. Yo soy el Bernal Farrero, el CEO de INNIC,
y hoy tenemos con nosotros a César Miguel Áñez, siempre.
Y a esta vez a Paul Narbonna, Product Owner de Typeform.
Muy buenos. Sería interesante hoy tocar el tema de Product y Project Management en startups.
Es un tema muy recurrente, de amplia discusión internamente aquí en INNIC, pero en general
yo creo en todas las startups. Todos hacemos y recemos las metodologías cada tres meses,
probablemente. Pero estaría bien empezar con tu historia, Paul. ¿Cómo has llegado a Typeform?
Bueno, pues mi historia empieza un poco... Yo soy de Barcelona, pero empecé a estudiar aquí
ingeniería industrial el primer año, y me salió la oportunidad de irme a Estados Unidos con una beca
deportiva. Y un poco tal y como estaban las cosas aquí hace 5 o 6 años, pues decidí hacerlo.
Y da la casualidad que Typeform tiene la base de usuarios todos en Estados Unidos,
o la parte más grande. Y de hecho me acuerdo perfectamente, estaba en una clase en tercero de
carrera y necesitaba hacer un proyecto, un poco de investigación de mercado. Y da la casualidad
que la semana antes había visto un artículo de startups locales mencionando Typeform y lo que
hacían, y decidí darle una oportunidad. Y la verdad es que ya en la creación de la encuesta
tuve una experiencia muy nítida y me gustó mucho, ya casi sin conocer lo que era, honestamente. Pero
ya cuando compartí la encuesta, el feedback fue brutal y la gente incluso, lo que todo el mundo me decía
es, hostia, has hecho algo, has hecho una página web tú mismo, esto no te gustaría crear un producto
de eso, porque de hecho lo que dices es pagué y entonces el removal branding no ponía Typeform.
Y entonces no sabían si eso era algo nativo que había hecho yo o realmente era un producto.
¿Explica un paréntesis qué hace Typeform para los que no lo conozcan?
Sí, Typeform, a ver tengo la definición aburrida y la que es un poco más divertida, pero siempre
empieza un poco para la aburrida porque es lo que me hacen decir, no. Typeform al final es un software
de recolección de datos online y básicamente puedes hacer todo tipo de formularios desde
encuestas, formularios de contacto, formularios de registro de eventos, cualquier formulario que se
te pase por la cabeza, pero realmente y por eso digo que es una definición aburrida, no hace
justicia lo que es Typeform, yo creo que el valor un poco intrínseco de Typeform es que realmente
ha convertido un proceso un poco, y esto lo diréis después en la presentación, pero un proceso un
poco burocrático y aparentemente el reinar formularios siempre ha sido históricamente algo un
poco atado a la burocracia, que la experiencia no es buena y ha convertido estos formularios más
en una conversación que puede ser muy agradable a nivel de diseño, porque es un enfoque muy grande
que tenemos, pero también a nivel de interactuar y un poco conversar con los respondents que los
llamamos, con la persona que está detrás del Typeform, y ese básicamente creo que es el valor
intrínseco de Typeform y de hecho estamos lo estamos viendo que la industria de por sí
la está validando nuestro nuestro approach a los formularios, porque realmente ya estamos viendo
la competencia un poco pivotando sus diseños a nuestro un poco el unique selling proposition,
que es el una pregunta en pantalla, un diseño más conversacional. O sea,
ha facilitado digamos lo que sería una herramienta de encuestas, lo ha facilitado a nivel de
usabilidad de diseño, lo ha llevado al extremo de la de la usabilidad. Exacto,
y a la vez hemos visto, esto no sólo es un detalle bonito de tener a nivel de usabilidad, sino que
hemos visto que también se lo que consigue es que consigas más respuestas y de mejor calidad,
o sea, tenemos el dato objetivo es que tenemos una tasa de compleción o de finalización más alta
de toda nuestra competencia de todos los otros formbuilders. Mi pregunta siempre con este dato
es ¿de dónde sale el benchmark? ¿Quién publica eso? Yo me quiero creer al equipo de data interno,
sí que después en marketing supongo se vende como se quiere, pero sí que yo he estado trabajando
mucho con nuestro Data Scientist y después puedo asegurar que el benchmark de la competencia no
sé dónde sale, pero nuestro sí que es creo que está un 56% de usuarios que entran a un type
form y realmente dejan respuestas, cosa que es bastante alto. También, además, y eso sí es
objetivo, typeform ha experimentado un crecimiento desde su aparición enorme, de la nivel de
tracción de usuarios, no sé si hay cifra de negocio, no sé qué datos son públicos o que se
pueden hablar, pero alguna referencia de volumen, si te puedes compartir. La que seguro que puedo
compartir y no creo que realmente no creo que estemos ocultando nada, pero la que seguro que
puedo compartir y un poco siguiendo con la historia de como un type form y un type form
hace año y medio, acabando mis estudios en Nueva York y creo que fui empleado en 90. Ahora
mismo creo que somos 180 en año y medio. O sea, eso un poco da la idea de cuánto hemos
crecido y la velocidad a la que estamos creciendo. Entré apenas creo que cinco meses después de
levantar la serie SA, creo que fueron 14 millones o así, no sé cuánto nos evaluaba eso sinceramente,
pero ahora hace cuatro meses creo que también hemos hecho la serie SB, que si no me equivoco así
rápido, quizás me equivoco, creo que fueron 32 millones y también eso, no estoy seguro si
puedo decir a cuánto nos evalua, tampoco lo tengo muy claro, pero sí que estamos intentando hacer
cosas más grandes. Una de las cosas que intentamos estar haciendo es nos conocen por formularios ahora
cómo podemos llevar esta herramienta conversacional a otros canales, ese sería un poco el challenge
que tenemos en frente. Por ejemplo, VR, VR, todo lo que es realidad virtual, estas cosas son
espacios que están muy intocados a nivel de data collection y es algo que sin duda espero y esa
es muy pura opinión, ya no de productores sino de cliente de type form que exploremos algún día,
interfaces conversacionales, lanzamos un artículo conversacional que tuvo mucho éxito y desde
entonces no lo hemos tocado, es algo que quizás queremos. Al final las conversaciones están en
muchos sitios y creo que en todos estos sitios type form puede aportar mucho valor con lo que ya
ha cambiado en el mundo de los formularios y ver de verdad dónde están esos espacios en los que
podemos también un poco cambiar las cosas. Cerrando el paréntesis. Te fuiste en Nueva York, estudiaste
ahí, volviste y entraste en type form. Sí, el último año de Nueva York estudiando una carrera
más enfocada de negocios, un programa de dos carreras enfocada más de negocio y economía,
pero realmente yo sabía que estuve ahí en una diseñadora web, una startup en Nueva York un
año y ya sabía que quería ir un poco hacia el mundo tecnológico, me gustaba y ya empecé a hacer
una especialización online en software product management y empecé a buscar ofertas a toda
Europa. De hecho, creo que type form fue la única que apliqué en Barcelona. Si me voy a casa al
menos será una empresa en donde no perderé el inglés, seguiré estando rendiendo gente
internacional, tienen buena proyección en el mercado está en Estados Unidos, creo que es un
mercado que conozco un poco. Así que apliqué, no había posiciones abiertas en producto, que era
mi challenge principal, entré en el equipo de customer success como una lista de datos y ahí
empecé a trabajar con equipos, empecé un poco a entender un poco el comportamiento de los usuarios
en nuestras public sites principalmente, que suelen ser top of the funnel un poco y colaboras mucho
con producto, los voy a trabajar, veía que es lo que me gustaba hacer y a la que hiciera una
reorganización un poco interna y así que apliqué internamente a una posición de product owner y
como ya tenía un poco, ya había puesto el pie en la puerta unas cuantas veces, al final
le damos la posición a este pesado y aquí estoy. ¿Cómo funciona el product management
en el equipo de producto en Typhoon? Pues aparte justo es un momento en el que puedo dar un poco
de contexto, hasta ahora hemos estado, somos cinco equipos de productos que estamos un poco
repartidos en lo que es la user journey, el camino del usuario, o sea hay una colonia de producto
que se llama Discover, que ahora mismo trabaja con todo lo que es el top of the funnel otra vez,
el public sites como atraer a sus captar gente exacto hacia el producto, después ya estaría
subscribe que es el equipo que trabaja con ya la suscripción del usuario, hasta hace poco teníamos
un environment demo donde pudieran probar el producto, todo esto y así vamos avanzando por
la user journey, yo de hecho trabajo en la última que es con Clut, que es la parte donde trabajamos
básicamente con los resultados, dentro de este de esta colonia de producto hay tres equipos y
básicamente hay un equipo que trabaja, de hecho hay dos, pero ahora mismo tenemos tres porque hay
un equipo que está más enfocado simplemente a la base de datos y hay otro que es más a nivel de
implementación en el producto en el panel de resultados, yo concretamente en mi charla voy a
enfocar mucho al este tercer equipo que es el de integraciones y es donde hemos podido realmente
hemos tenido sus exponencias muy opuestas a nivel de agilidad y no quiero presentarlas hoy, déjame
hacer un paréntesis, otro paréntesis, que es que hemos cogido a Paul hoy, justo cuando veníes a
hacer una charla sobre Ayael en Ismeral, porque la gente en nuestra biencia no tiene el contexto de
la charla y de hecho hablarás de Ayael dual track Ayael que ahora también nos contará un poco
de en qué consiste. Bueno, unas cosas que digo en la presentación es que intentemos evitar,
bueno al menos en Typhoon intentamos evitar lo dual track Ayael porque es un bueno no pasa
nada pero realmente es un poco innecesario que vayamos sumando más palabras que son
las metodologías o frameworks y al final lo llamamos por lo que es con el equipo,
es discovery y delivery, el descubrir y el entregar. Antes de entrar perdona en el dual track Ayael,
me interesa que profundices un poco más en cómo funciona el equipo de producto en Typhoon,
hablas de colonia, ¿qué significa una colonia? Vale, es una discusión exenso, pero en la colonia
al final el significado es alrededor de qué paso de ese camino del usuario estamos trabajando,
la idea es que como he dicho con Clut trabajan todo alrededor de resultados que es el último paso
para un usuario. ¿Colonia es un grupo de gente? Colonia al final es en una colonia de
conclut en principio, hay tres equipos de productos multifuncionales, o sea ahí sí que es el equipo
donde tienes diseñador, ingenieros, tienes UX, tienes Product Owner y entonces hay tres equipos
dentro de este área de enfoque un poco que es el de resultados. Al final colonia solo lo que da es
un mensaje de los equipos que están en esta colonia, trabajar en esta parte del viaje del usuario.
¿Y las colonias estas son completamente terméticas o la gente cambia entre equipos?
Sobre todo a nivel de ingeniería, sobre todo estamos viendo que la gente cambia mucho,
obviamente los ingenieros por definición son súper curiosos y les encanta estar tocando
diferentes partes del codebase y nosotros nos vamos moviendo. Creo que de hecho los
productos somos lo que menos nos movemos de equipo a equipo y la verdad es que es algo que quizás
deberíamos hacer más. Tiene sentido por que tal y como lo estoy entendiendo básicamente lo que
dividís es el producto, el producto se evidencia en cinco partes con objetivos de negocio cada una
y luego las partes de diseño y ingeniería pues no está tan atada al producto, pero Product Owner
es normal que tenga esta parte del producto en la cabeza. Y a todo eso ahora mismo estamos rompiendo
esta organización y nos estamos reorganizando de otra manera porque sí que hemos encontrado que
se creaban algunas dependencias y realmente a veces que estudiábamos un tipo de usuario,
queríamos crear un tipo de camino para él pero no estaba en la prioridad de otros equipos y entonces
quizás teníamos dependencias en otras partes y ahora estamos probaremos, es un experimento,
un un approach un poco más horizontal al nivel de que un equipo pueda coger de la mano el usuario
cuando entra en el producto y llevar los resultados y así no perder el contexto. Esto me lleva a
cómo definir o cómo typeform define el roadmap del negocio. Tiene que haber un roadmap a alto
nivel y luego cada una de estas colonias tiene un su roadmap o cómo funciona. Sí, ahora
estamos sinceramente, estamos un poco en la zona un poco gris porque estáis viendo este cambio y
claro todo todo lo que pertenecía a un equipo ahora queda un poco en el aire y otros equipos
tienen que coger por piezas. Pero históricamente bueno no es desde que yo estoy, normalmente lo
que ha habido es un ejercicio desde el equipo de leadership, desde el equipo un poco de los
CTO, CEO, BP of Product, BP of Growth. Esta gente nos daba una dirección a nivel de áreas de enfoque.
Siempre hemos intentado y siempre creo que han hecho un gran trabajo en no intentar tirar soluciones
hacia abajo. Obviamente con el equipo quieres trabajar con áreas de oportunidad y no con
soluciones y entonces nos han dado más áreas de enfoque. Ahora mismo estamos trabajando con
OKArts como los de Google que básicamente es un objetivo a nivel de empresa, una métrica que
tenemos que afectar y a partir de aquí nos dan la autonomía de encontrar las diferentes iniciativas
para cómo mover estas métricas. Ejemplos de métricas? Ejemplos de métricas por ejemplo la
que yo trabajaré ahora aquí adelante es básicamente captar 30.000, creo que puedo decir ese número,
30.000 nuevos usuarios que activen, el MIU, el monthly active users. Esa es nuestra métrica,
por lo tanto es un ejercicio no solo de adquisición de traernos usuarios sino de asegurarte de que
estos usuarios activen y la definición de que activen es que internamente es que tengan 10
respuestas en un type form, una bastante ambiciosa por cierto. La métrica de activación de un usuario
que crea una encuesta es que reciban 10 respuestas en dentro de un mes y eso los hace considerar un
monthly active users activos durante ese mes. No es que creen encuestas? No porque realmente hemos
identificado que el valor de type form es cuando recolectas la data o cuando creas el type form.
O sea, la métrica de activación es una de las grandes discusiones también en las startups. Por
ejemplo en Factoria y Cesar. Sí, ahora tenemos, hemos convido a la métrica recientemente porque
antes nos estábamos teniendo en cuenta el turn porque acabamos de empezar con el producto y
tampoco hacía mucha falta tener en cuenta el turn. Básicamente nuestra métrica es que una empresa se
considera activa si durante los últimos 30 días al menos tres empleados han entrado en Factoria,
porque consideramos que los empleados pueden entrar pero no pedir vacaciones, pero pueden
ver su nómina en Factoria o pueden ver las vacaciones de los demás. Entonces entendemos que
para nosotros en el estado en el que estamos, cuanto más simple la métrica sea mejor y esta era
suficientemente simple como para que la implementación sea fácil en distintos puntos tanto en
analítica como en los channels de marketing, etcétera, etcétera. Lo que hizo Bernat es cierto,
es una métrica que llegar a ella cuesta bastante charlas. Sí, pero veo un paralismo entre las
dos empresas porque ya no es que la persona que crea o el administrador o la persona de recursos
humanos en el caso de Factoria cree o llene toda la información del empleado. El éxito de Factoria
es conseguir crear una herramienta eficaz de comunicación con el empleado con lo cual tiene
que entrar el empleado y eso nos lleva también a utilizar como métrica de activación la entrada
del empleado. Es parecido a lo concluyente. Claro, al final como os decía si un poco el valor
intrínseco que creo yo tiene typeform es el hecho de que a través de un diseño más conversacional y
una interacción más semejante a una conversación consigues más y mejores respuestas el valor está
ahí. Si tú creas una encuesta pero no consigues ni más ni mejores respuestas realmente typeform no
explota todo su potencial y por eso creo que se ha sido un poco la definición de activación. Entiendo,
entonces que tu objetivo, tu objetivo en este caso sería impactar esta métrica de activación con
30.000 nuevos usuarios activos y entonces tú cuando recibes este objetivo qué haces como
una traslada de acciones. O sea yo quiero destacar que esto es a nivel de mi equipo. Nosotros tenemos
unas metas a nivel de tenemos cinco o cuatro cinco áreas un poco de oportunidad y unas métricas,
unos key results, unos objetivos y unos key results que salen de ellos y entonces cada equipo ve
cómo puede colaborar. El mío en concreto es uno de los que nuestro objetivo hay un número de
MIUs que queremos llegar a fin de año y yo en el equipo que voy a trabajar queremos un poco afectar
ese top of the funnel desde que desde que cogemos a un usuario y lo activamos. A partir de aquí ya
quizás otro equipo lo coge y hace más trabajo con estos usuarios. ¿Cómo lo que os los haremos
a iniciativas es el trabajo que estamos haciendo ahora? Es básicamente identificar otra vez áreas
de oportunidades pero allá a un nivel más granular y también con el equipo si puede ser siempre
como cuando yo creo bueno al menos también soy una persona muy junior por lo tanto me va genial
rodearme de mentes brillantes como los ingenieros y diseñadores de UX y todo y empezar a explorar
de ostras con nuestra interacción con los usuarios que es lo que realmente están pidiendo. ¿Qué tipo
de usuarios son? Por ejemplo en qué device, en qué nos están visitando móvil, nos están visitando
en ordenador y empiezas a ver áreas de oportunidad donde quizás no estamos haciendo del todo bien
para un cierto tipo de usuario y te agarras un poco, haces un poco más de investigación y
empiezas a ver cosas. Siempre decimos al menos como lo enfocamos nosotros lo vemos muy tangible
a nivel de números. Ahora mismo también es algo súper transparente pero no tenemos un producto
móvil a nivel de poder crear una encuesta y los sign ups que nos llegan a través de móvil comparados
con los que nos llegan a trimel a través de ordenador, hay muchos que perdemos en el camino
obviamente. Si tú la primera interacción que tienen con tu producto que vienen a probarte
hacen el sign up y realmente no pueden probarlo, después por mucho que los enviamos el email o lo
que hagamos para que nos ponen en desktop y han perdido ese momento de hola que está y creo quiero
hacer una encuesta. Y entonces ahí por ejemplo hay una oportunidad que es una que es ahora mismo
hoy mismo estaba trabajando en ella y trabajaremos con el equipo. Pero lo que no entiendo es cómo
esto es un problema general, decíamos el proyecto. No problemas de tu parte del journey. Tú lo tienes
que ver desde tu parte del journey o en general. Déjame desbosarte como en esta oportunidad que
te he comentado, la de un poco que en móvil perdemos activación de usuarios. Tenemos muchos
usuarios entrando en móvil por lo tanto eso nos ayuda a nuestra meta de adquirir nuevos usuarios
pero la meta es adquirirlos y activarlos. Ahora tenemos un montón de usuarios que están entrando
a través de móvil y los perdemos porque no hay ese engagement. Quizás una de las soluciones
sería tener y eso es un ejemplo eso ya es trabajarlo con el equipo, pero uno sería hacer onboarding
directamente desde móvil. Eso quizás hace que les activemos, que creen un typeform y que
recojan 10 respuestas a final de mes. Entonces tenemos todo un potencial dentro de todos estos
usuarios que están entrando en móvil y ahora el ejercicio es cómo los activamos que es nuestra meta.
Entonces ahí aportaríamos a esa métrica que queremos mover nosotros y esto es solo una
oportunidad no digo que vayamos a hacer esto, pero sí que es entender este tipo de razonamiento de
cómo donde ves un poco diferentes coeficientes donde que te dan un poco por qué aquí no están
activando como o por qué este tipo de usuarios no están activando como los que vienen de un
segmento de recursos humanos por ejemplo. Entonces para entenderlo bien, se actúa esta parte de
exploración juntamente con el equipo, decir el equipo que está trabajando probablemente en el
anterior esprin o en la anterior acción que se ha determinado para presentarse contigo, discutir
estas oportunidades, ¿no? Entiendo. Y entonces ¿qué, cómo lo hacéis? ¿Cómo definís? ¿Se escribís
un roadmap? ¿A cuánto tiempo? ¿Cómo funcionan los esprins de trabajo? Parece que lo hayamos
hablado antes, pero un poco esto es literalmente de lo que se trata dual track agile y el discovery
delivery que es básicamente involucrar al equipo a nivel de descubrimiento y a nivel de entrega,
hay dos cosas, una cosa cuando estamos intentando identificar oportunidades y valor en las soluciones
que queremos que es un poco donde vamos y por eso tenemos un backlog de descubrimiento y un backlog
de delivery. ¿Cómo trabajaré con este nuevo equipo? Aún no he empezado, no te sé decir,
pero sí que te puedo decir por la experiencia el que dices el hecho de parárselo un poco drástico,
¿no? En plan nos trasparemos aquí entrega y ahora nos pongamos a investigar. Lo que intentamos
hacer al final el backlog de descubrimiento y el backlog de entrega tienen dos caminos que van
en paralelo y entonces yo mientras el equipo está entregando una solución que ha sido validada a
nivel de desarrollo, yo puedo estar trabajando con diseñadores, con data, con producto, con marketing
para identificar las oportunidades que pueden venir después. Sí, durante este enfoque del equipo
de realmente entregar algo, identificamos una oportunidad y vemos que podemos hacer un experimento
pequeño con o sin desarrollo, pues ya es trabajo que podemos avanzar para mover esta oportunidad a
entrega en el próximo paso. Así que no lo veo como algo que realmente para el equipo depende de la
situación. Ha habido experimentos que hemos hecho yo con diseñadores, poniendo un prototipo en
sketch o así, sentándonos con usuarios y eso nos ha dado información de si esta es una idea
válida o no. Y entonces una vez que es una idea válida, la puedes ya presentar al equipo y decir
cómo a nivel de desarrollo podemos entender si esto tiene sitio en nuestro producto. Entonces
ya empiezas a hacer ese primer trabajo de descubrimiento con el equipo. Cuando digo que hago
descubrimiento con el equipo, no significa que desde que la idea toca la mesa y se hace el
research de mercado y todo, están involucrados. Obviamente tienen mucho más valor porque pueden
desarrollar cosas y entonces sí que intento dar un poco más de contexto de dónde está la oportunidad
y cómo podemos enfocarlo. A nivel de project management, concretamente utilizáis alguna
metodología tipo agile, Scrum, Kanban, en cada uno de estos backlogs. Sí, sí, nosotros trabajamos,
creo que puedo hablar por casi todos los equipos del producto en Scram y Sprints de dos semanas,
el Dualtrak Agile es totalmente compatible con Scram y realmente cuando lo presentamos dijimos
podemos romperlo de Scram, es una regla no escrita, no hace falta, pero el equipo decidió trabajar en
Scrum y bueno, creo que nos ha ido muy bien. Vamos a esa experiencia personal que he tenido. Entonces
en el backlog de descubrimiento, ¿qué escribís? ¿Problemas o necesidades del cliente? ¿Cuál es un
item? Solen ser preguntas, de hecho la manera más fácil es y te puedo dar el ejemplo con Google
Sheets, que es una integración que me voy a basar mucho en mi presentación ahí, lo que hicimos
realmente es hicimos un trabajo previo de entender de todas las integraciones cuál era la que querían
nuestros usuarios, esto fue tan fácil como poner una encuesta, un typeform, y enviarlo a los usuarios
y realmente tuvimos mucha información de qué es lo que querían, una forma muy fácil de privatizar,
pero a partir de aquí tenemos la más la que se quiere, la que nuestros usuarios quieren usar más,
pero falta mucho entender cómo lo quieren usar, qué tipos de usuarios son y entonces hicimos un
trabajo sin desarrollo para entender que Google Sheets era la que más querían, ahora lo traemos
al equipo y vamos a hacer el trabajo de UX de validar cómo esta solución tiene que implementarse.
Entonces la primera pregunta de descubrimiento fue qué es lo que nuestros usuarios quieren de
una integración con Google Sheets y a partir de aquí entró en este flow de descubrimiento y lo que
hicimos con el equipo es y quizás no voy a entrar en detalle, pero básicamente es romper lo que el
diseño puso, diseño nos puso una propuesta de cómo la integración de Google Sheets podía ser,
un poco romperla y decir cuál es la hipótesis mínima que queremos validar aquí, qué es realmente
el uso principal de nuestros potenciales de usuarios de Google Sheets y eso nos dio mucho
contexto porque antes habíamos hablado con usuarios que pedían Google Sheets y lo que querían
simplemente es una nueva respuesta cuando llega que me la envíen a las pre-sheets y entonces en
el diseño había cosas como cuando ya tienes respuestas y te integras que se que entren esas
respuestas pues eso lo dejamos fuera porque no no atacaba esta hipótesis inicial de nuestros
usuarios lo que quieren es una respuesta nueva a las pre-sheets cada vez que llega y ese fue el
experimento que hicimos una semana pusimos un producto yo diría bastante inestable al 20%
de nuestros usuarios con esa funcionalidad y vimos que la adopción fue increíble y vimos que
realmente había mucho valor ahí entonces tiramos ese código de la basura, refactorizamos,
lo hicimos bien y lo lanzamos al 100% de los usuarios y ahora a poco a poco estamos añadiendo
las funcionalidades que ya determinamos al principio como un poco secundarias para completar
el packaging pero sí que el ejercicio de romper realmente el de verdad por qué nos están usando
y por qué un producto tan barato a nivel de coste de desarrollo que lo hicimos en la semana el
entender ahí qué tipos de usuarios y por qué les estamos ayudando con algo tan barato nos dio
la dirección totalmente para después enfocar lo que venía y volviendo un poco hacia atrás
cómo decidí en qué momento decidís si hacer la integración está con welsheets o hacer
una cosa completamente distinta en qué momento se hicié entre una oportunidad u otra y cómo lo
hacéis yo creo aquí sinceramente fue yo creo que fue bastante bastante fácil porque tuvimos el
recurso este de una encuesta que enviamos a tuvimos muchas respuestas y tanto melchim que es la
integración de la que veníamos que ya habíamos hecho como welsheets estaban por encima de todas
las otras entonces ya te da una indicación que a nivel de adopción serán las que sean mejores
mejor recibidas pero igualmente también hay otros factores quizás una que no pidan tanto se
puede monetizar y por lo tanto es más valuable para el aquí simplemente fue el factor también
de trabajar con el equipo traer la idea y preguntarle a nivel de esfuerzo que es lo que es lo más fácil
de poner delante de los usuarios obviamente las apps de google son súper fáciles de trabajar en
contra de otras de otros que teníamos en la mesa y el equipo dijo yo creo que una semana podemos
tener esta hipótesis funcional y una vez tienes eso sabes que en una semana tienes la segunda
integración más más peida de tus usuarios y dijimos vamos a por ella fue una semana
de una semana sí hay un truco que es que nos fuimos alquilamos una una masía afuera
de barcelona si estuvimos una semana con el con este equipo ahí pero realmente no nos penséis
que ni que sobrevivíamos a redbulls ni que trabajamos más de la cuenta fue realmente el enfoque de
tener bien definido el problema bien definido el producto y también obviamente el equipo estaba
sin distracciones siempre hay cuando estás en la oficina siempre hay otras cosas que aparecen
aquí nos dio enfoque y en una semana el que empezamos el lunes y creo que el viernes hicimos el
release interno siempre hacemos primero a todas las cuentas de nuestra empresa para que te estén
un poco y creo que el martes ya lo estamos abriendo el 20 por ciento lo de la masía escala
estamos creciendo bastante y creo que de momento lo seguiremos haciendo siempre y cuando el resultado
sea una integración que acaba yendo todos los usuarios pero tenemos cada realmente fue una
masía porque el equipo el equipo decidió usarlos y pero sí que tenemos un presupuesto para usar
como equipo y un poco se usa como que crea gente que que se va a un barco un día y se lo gasta
todo nosotros dijimos una masía para hacer esto y la verdad es que fue increíble fue la mejor
experiencia que teníamos y creo que de momento como compara esto es ser con factor y nosotros
no no vamos a masías porque lo plantearemos quizás pero no digo tanto la masía sino cómo definir
las prioridades en el rock map bueno es más o menos similar al final o sea nosotros decimos igual
no tenemos tan definido en papel por así decirlo vamos un poco más a saco pero sí que claramente
tenemos una serie de oportunidades que desarrollar dentro del producto hacemos una estimación del
coste hacemos una estimación del impacto que tendría y y lo acabamos desarrollando no y ya
está tenemos dos escalas una escala más grande de caral rotma principal que son pues yo que sé
proyectos que nos van a llevar más de una semana por ejemplo y luego están también las features
más pequeñas o improvements que llamamos pero al final todas siguen más o menos el mismo el mismo
sistema sobre todo en las pequeñas estuve investigando cómo lo hacen otras empresas y encontré un
post muy interesante de los de intercom que ellos usan el sistema rise que es rich impact cost si
todos saben mejor que yo y y básicamente ellos lo que hacen es tienen una serie de escalas nosotros
las modificamos un poco para aptarlas a nuestro caso pero básicamente mides el la cantidad de
usuarios a los que va a llegar este improvement o arreglar este bag mides el impacto que tendrá en
otra escala distinta el coste que tendrá multiplicas esos tres y no el coste no no es coste es
confianza multiplicas los tres primeros por el efor y los divididos por el efort y te sale pues un
número que un coeficiente que puedes comparar y al final es lo que lo que hacemos el siguiente podemos
sustituir un producto aúner por un algoritmo bueno al final al final el trabajo del producto
aúner es decir que que numeritos pone dentro de la de la fórmula de todo el equipo de type form
como cuánta gente hay que sea productowner y diseñadores ingenieros como cuál es del explet
del equipo el equipo de producto creo que ahora mismo debe ser unos ocho productowners y normalmente
trabajo uno uno por equipo y los equipos de ingenieros deben ser de entre de ocho y diez
personas máximo hay equipos más pequeños también y ingeniería en total creo que debemos ser unos
70 80 personas todo esto te lo digo a nivel de ocho equipos 10 ingenieros por equipo sí sí más
o menos bueno 10 ingenieros por equipo no son más porque tienes que sumar diseñador yuex yuey también
que están dentro de ingeniería pero bueno sí creo que al final porque también hay ingenieros de
sistema ingenieros de arquitectura de arquitectura que ya no están dentro tanto de equipos de
producto sino que trabajan un poco más a nivel técnico tenéis un roadmap a largo plazo es
decir en el siguiente año si en estos años queremos ir hacia ahí esto se define o no se va
descubriendo siempre sí pero sí pero suelen ser no suelen ser roadmaps en un ser otra vez
trabajando con no que ya es lo que te dan es una dirección lo que te dan es la visión de dos
cinco años y yo creo que así si te puedo dar el en una frase lo que lo que type form quiere
ser es una plataforma un convertirse en un poco un nodo en esta red tecnológica donde cada uno va
montando softwares un nodo en que los otros se quieran integrar no sólo nosotros integrarnos con
otros un nodo imagino digo nodo porque también no tengo vengo muy de esta conversación al mismo
en el trabajo pero básicamente una red tiene diferentes nodos y si lo vieramos por ejemplo
yo que sé intercom sería un nodo muy grande porque muchos muchos diferentes softwares están
integrados con ellos dice a nivel de integraciones a nivel de integraciones sí sí la un poco el
querer convertirse en una plataforma está totalmente anexado a estar muy integrado y
queremos convertirnos en un nodo cada vez más potente y que la gente que quiera tener conversaciones
o interfacios conversacionales en sus webs en sus productos la primera cosa en la que pienses es
en titular y pues muchas gracias por el incésar por tu contribución y nada seguidnos en nuestros
canales en facebook twitter youtube etcétera la web de indies que tenemos una nueva sección para
podcast y muchas gracias