Bueno, primero de todo, gracias por venir y mientras ahora me voy a presentar un poco,
pero yo aprovecharía a coger las vírras ahora porque sí que voy a estar media ahorita
hablando como mínimo, así que me voy presentando, pero de verdad que no me molestará que se
levantéis a por una.
Soy Paul Narbona, Product Manager o Product Owner en Typeform y quería un poco empezar
explicando cómo realmente yo cruzé de caminos con Typeform porque es una historia un poco
curiosa.
Estuve en Estados Unidos y estaba en una clase que realmente tenía que hacer un proyecto
de investigación y justo una semana antes ya había oído, había leído un artículo
que hablaba de startups locales y entre las que salía Typeform, entonces obviamente
la que pensé voy a intentar usar un producto local antes de otras competiciones que no
quiero mencionar para no meteros las en la cabeza.
Entonces ya al hacer la encuesta propia, básicamente ya vi que la experiencia era
diferente, era muy simple, muy sencilla, muy nítida, pero realmente cuando pasé esa
encuesta al mercado, al tipo de mercado que estaba analizando, recibí mucho feedback
por e-mail, sobre todo la gente preguntándome, es algo que has hecho tú, es algo que has
codeado tú, has programado tú, porque realmente era un formulario diferente, ahí es un poco
donde un poco saltó la chispa con Typeform y seguí usándolo de ahí en adelante.
Visto esto ya dos años y medio después, da la casualidad que soy Product Manager de
un producto que me gusta mucho, que la verdad es un lujo y he dicho antes que os fijáis
he dicho Product Manager o Product Owner y es porque también quería explicaros que
realmente esto ha salido hoy hablando con compañeros y lo acabo de añadir hace poco,
es que realmente tenemos un poco una crisis de identidad positiva, nada malo, pero realmente
como Product Owner trabajamos muy cercanos al equipo, a nivel de backlog trabajamos
muy cercanos al equipo, trabajamos muy cercanos al equipo a nivel de las reuniones ágiles
que tenemos con el equipo, pero sí que tenemos un enfoque mucho más amplio, un enfoque a
desarrollo de estrategia, investigación de mercado, que también un poco abarcamos las
dos definiciones, así que me veréis en LinkedIn como Product Manager, me veréis en Twitter
como Product Owner, da igual, no toméis una por otra.
Realmente empezaré porque es lo que me gustaría transmitir en esta charla y un poco de que
va lo de hoy.
Ah, por cierto, ese perro es mamón, es el perro de la oficina, el nombre me mola mucho
y es uno de los fundadores de Typeform, no hay deploy que no pase por él, él hace
la última edición es suya.
Así que primero quería explicar un poco dónde estamos en Typeform ahora mismo, el contexto
y el momento y ya pasaremos a introducir el concepto de la charla en Continuous o Customer
Discovery y un ejemplo práctico, un ejemplo práctico que nos da la mejor idea del concepto
de sí mismo.
Ya entonces pasaré realmente a introducir el propio framework Dualtrak Agile o Discovery
Delivery y en concreto como en Typeform hemos visto, hemos desarrollamos una integración
con Mailchimp donde tuvimos ciertos problemas y como sacamos dos aprendizajes después
al hacer la retro y vimos la necesidad de aplicar este framework a las integraciones
que atacamos después.
Entonces esta integración que atacamos después fue Google Sheets de la que voy a hablar
y por último ya cerraré introduciendo un poco por encima el Typeform Product Playbook
que es, bueno, no quiero dar spoilers, ya lo comentaremos después y ya abrir a preguntas
y cervezas, bueno, preguntas y cervezas, eso es implícito ya casi, porque de verdad
yo creo que de ahí saldrán las preguntas y las conversaciones buenas.
Pero básicamente todo un objetivo que es el que quiero expresar que realmente Customer
Discovery es una pasada y realmente como Product Owner es donde más me gusta dedicar
mi tiempo.
Así que así mano alzada página uno del speaker, ¿quién ha usado Typeform o lo conoce?
¿Quién lo ha usado?
Te hacemos por ahí.
Bastante bien, ¿eh?
Tenía gente de Typeform por si acaso, para ver si es verdad, pero bueno.
Pues les voy a dar primero la definición aburrida, un poco la que se entraeces en Wikipedia
es Daria, no es la de Wikipedia, no soy tan cutre, pero bueno.
Typeform es un software de recolección de datos online en forma de aplicación web
para el browser, el navegador de tu ordenador y hasta ahora hemos sido conocidos simplemente
para formularios, todo tipo de formularios, el que se os pase por la cabeza, formularios
de contacto, registro de eventos, encuestas, podría estar, bueno, de verdad es que hay
muchos casos de uso, pero realmente y ahora yo lo saco de la definición un poco burocrática,
es que el valor de Typeform es realmente lo que ha impactado esa espacio en el que ha
entrado, el espacio de los formularios online, de la recolección de data online y el valor
un poco intrínseito que lo encuentro es realmente como ha convertido estos procesos burocráticos,
que es el rellenar un formulario online entre algo un poco más conversacional, un poco más
incluso elegante ¿no? y eso se traduce no solo en una mejor experiencia sino también
que tenemos más respuestas o tenemos más respuestas y de mejor calidad, esto no es algo que me
saque aquí de golpe, sino que realmente como dato y lo vendemos como producto es que la
tasa de finalización o compleción de las encuestas de los Typeforms es más alta que
cualquiera de nuestra competencia. Y esto aparte se dé cuando ves a la competencia
y votando sus diseños hacia los tuyos, un diseño de una pregunta en pantalla más
conversacional, no quiero decir el nombre pero algunos lo detenéis en mente.
Los siguientes pasos como empresa realmente es el llevar nuestra herramienta conversacional
a otros canales y acabamos realmente de atravesar un proceso de rebranding y lanzado una plataforma,
pero bueno aquí os enseño un poco el rebranding, simplemente es un gif de la página web, realmente
centrais a cualquier dominio typhoon.com ya veréis la nueva marca, hay opiniones de todos
los gustos pero bueno es yo realmente creo que de verdad expresa lo que queremos ser
en adelante y también hemos lanzado v2 que perdonar que lo llame v2 pero realmente internamente
ha sido la segunda versión del producto y es como lo llamamos y aquí si que ya me
saco la máscara y empiezo a ser super transparente en lo que hemos hecho, v2 ha sido un macro
proyecto, v2 no hemos podido ser todo lo ágiles que queremos ser y obviamente de aquí hemos
sacado muchos aprendizajes.
Hara dos semanas el 12 de febrero lanzamos la plataforma y el branding a la vez, la nueva
marca deprecando así ya la antigua versión y el typhoon que casi todos vosotros conocíais
y que casi todos nuestros usuarios conocen, una apuesta bastante arriesgada.
Esto junto a otras fuentes de aprendizaje de las que voy a estar hablando que son incluso
más relevantes a esta charla que serán la integración con Melchim como he comentado
y la integración con Google Sheets que las lanzamos más o menos a finales del año pasado
y principios de 2018.
Así que bueno, este soy yo producto owner de un equipo que se llama con Clut que exactamente
es más lo llamamos Colonia y contiene tres equipos, tres swarms, tres equipos multifuncionales
como los que conocemos de todas las otras empresas del software y básicamente yo trabajo
con los tres equipos alrededor de la experiencia de resultados e integraciones y como se vea
a nivel de producto esto es si habéis usado typhoon alguna vez a nivel de producto nos
encargamos de la parte de resultados, lo que es el display del resultados pero también
trabajamos en la parte de integrate que nos integramos con otros servicios como Melchim
o Google Sheets o cientos de otros a través de Zapier que es un servicio que usamos y
también muy brevemente quería comentaros lo que me hizo aceptar esta charla porque es
una historia curiosa y que es el síndrome de impostor, el síndrome de impostor no
voy a decir lo que es porque solamente todos hemos leído de algo pero realmente es que
la historia fue curiosa es algo que estaría sintiendo ahora mismo pero realmente el día
antes de recibir la propuesta de hacer esta charla nuestros TEOS, fundadores estos dos
David y Robert compartieron con nosotros un email donde un poco nos explicaban como
incluso ellos lo sentían y en ese email había un link a un TED Talk del CEO de Adlashan
y ahí un poco el CEO de Adlashan que es una bestia de empresa explicaba como el día a
día tras día se sentía así y eso que era un poco de empatía y dices al menos quizás
no voy tan mal y sí que la idea que un poco explicaba que me gustó mucho es que la industria
del software al final está súper acelerada, crece a ritmo exponencial, tiene sentido que
la gente de dentro de esas empresas sus carreras también crezcan al mismo ritmo y aquí estoy
la verdad es que me siento que estoy en los zapatos que me van un poco grandes pero bueno
sí que os puedo contar que he vivido el crecimiento de un producto y empresa como Typeform muy
rápido y en concreto relevante a esta presentación la razón por la que necesitamos agilizar
procesos alrededor ya de la búsqueda del valor del Customer Discovery que nos vamos a centrar.
Así que veamos ya indagar en el tema de Customer Discovery más en cuanto a cómo incluir como
un poco mantra de tu empresa o equipo de producto el Continuous Discovery y primero un ejemplo
que le dejará claro los beneficios de realmente acercarte a tus usuarios. Otra pregunta así
para ir interactuando un poco, alguien seguro que sí conocéis a Steve Blank, seguro que
todos hemos leído cosas de Steve Blank y si no las cosas os sonarían cuando las viéseis.
Steve Blank es un profesor de varias universidades de Estados Unidos pero escribió muchos sobre
comportamientos del consumidor y relevante obviamente al desarrollo de productos y presenta
un caso que me pareció muy bueno para introducir el tema de Customer Discovery. Nos presenta
un caso donde un alumno suyo le vino a proponer una idea de negocio que quería levantar una
ronda de inversión seed funding para una empresa que desarrollara adrones con cámaras
hiperespectrales para uso en la industria agrícola, ahí yo ya me perdí y tuve que
poner Google hiperespectral. Para los que no sepan como yo que es una cámara hiperespectral
básicamente toma este tipo de imágenes y lo que hace es recopilar y procesar información
a lo largo del espectro electromagnético. En el caso de este estudiante básicamente
para que estos drones sobrevolaran los terrenos y captaran imágenes para después ser procesadas
ya por un algoritmo y poder presentar a los extranjeros información como por ejemplo
el estado de las plantaciones, si había patógenos o no, la cantidad de insecticidad o la cantidad
de agua por zona, cosas obviamente muy valuables para los extranjeros. Esto de hecho se conoce
como agricultura de la precisión, otra cosa que aprendí y es un área irónicamente bastante
explotada con startups emergiendo día tras día. Pero ya es este punto y ya me gusta
ir a preguntar, espero que alguien pueda decir algo porque se no quiera un poco mal. Realmente
presentado este caso una empresa de drones con cámaras hiperespectrales que lo que quiere
es procesar estas fotos y presentarla a los extranjeros, realmente si Steve Blank lo presenta
aquí la pregunta ¿cuál creéis que es el MVP? ¿Cuál creéis que podría ser una idea
para validar este proceso? O sea que no ha ido de artículos fácil si no hay respuesta
incorrecta. ¿Alguien tiene alguna idea de cuál puede ser el MVP de este caso?
O que es un drone fabricado ya y con la cámara debe ser el drone que vendría en las baterías
digamos una tienda, que empezará a hacer fotos y va a conseguir un cliente ya.
Por ejemplo, si no se hay que respectar a lo principio, pues si se diga así.
Si el producto se dará y si es de la imagen, realmente con una imagen cualquiera puedes usar
de tal una muerte. La verdad, la gente tiene más que añadir pero realmente habéis dado
en el clavo los dos. Lo que apunta aquí Steve Blank es que realmente el producto mínimo viable,
lo que los extranjeros quieren pagar, no es el drone, no es la cámara hiperespectral,
es la información, es lo que a ellos nos parece relevante y por lo tanto la mejor manera de
realmente validar esta idea sería exactamente alquilar un avión, un helicóptero, un drone,
procesar esa data manualmente y realmente ver si los extranjeros pagarían por eso.
Esa es la idea exactamente. Así que básicamente la idea que lo que queréis de esta parte de la historia
es validar su MVP básicamente por una fracción mínima del coste inicial.
Esto es lo que se llevó el alumno y así lo hicieron. Si pensamos un poco retrospectivamente,
esta es una empresa que inicialmente estaba pensada para drones que después aplicarían
a la industria agrícola y el hecho que le dedicaran tiempo para hablar con sus credentes
en potencia, los extranjeros realmente se dieron cuenta que realmente a los extranjeros
no les importaba de dónde o cómo venía esa información. Lo que quieren es la información.
De hecho es gracioso porque como si lo anganchaban a vez migrando por la zona,
como si da igual. La verdad, el producto final es la data y es lo que tienen que validar
si pagarían por eso. Además, añade de costumers discovery y por eso, de hecho,
es mi parte preferida del desarrollo de mi trabajo como Product Owner, le añades ese toque de ser
en Deepia. Cuando vas a ver con estos usuarios, al final tú vas con la idea
que quieres aprender a validar cierta hipótesis, pero la mayoría de las veces
y yo creo el mejor beneficio del costumer discovery es ese ser en Deepia.
Entonces vamos a aprender que no tenías pensado y que acabas aprendiendo.
En este ejemplo, al hablar con los extranjeros, básicamente aprendieron
que estos ya tenían contratados aplicadores aéreos. Los aviones que habréis visto
que rocían con insecticidad a todos estos campos. Entonces ahí obviamente te clica
una bombilla y dices, realmente ya nos podemos todos imaginar
que fue el siguiente paso. El producto estaba en acoplarlos en estos aviones.
No tenían, no necesitaban drones, no necesitaban a desmigrando por esa zona,
realmente la estructura aérea ya estaba montada. Y esto realmente
es solo un ejemplo, espero que haya un poco creado el origen de esta idea,
pero es la explicación de cómo realmente tener epicentro,
en el epicentro de tu desarrollo de Product Owner Discovery
te pueden no solo hacer aprender lo que quieres, sino mucho más
y ya dirigir tu producto desde el inicio.
Una vez que ha visto el ejemplo práctico y el concepto
así por encima de Customer Discovery, ya me gustaría introducir el framework
ya así de manera más tangible y también aportando más valor viendo
cómo en Typhoon lo hemos aplicado. Así que ya introduciendo
Dualtrak Agile, Discovery and Delivery, descubrir y entregar,
voy a remarcar una cosa, en Typhoon no lo llamamos Dualtrak Agile,
es realmente no necesitamos otra palabra de la industria del SaaS,
no necesitamos otra palabra que suena a metodología, a framework,
es sobrecomplicar las cosas. Así que de aquí a adelante y realmente
en Typhoon lo hacemos así, es descubrir y entregar, es Discovery y Delivery.
La idea básicamente asume que hay dos líneas de trabajo, dos caminos,
lo podemos ver tal cual en el desarrollo del producto está la parte de
descubrir cuando estamos intentando encontrar el valor y está la parte de entregar.
La línea de trabajo de Discovery se trata realmente la búsqueda
de construir el producto correcto, de responder al que vamos a desarrollar.
Y por contrario la línea de trabajo de Delivery se encarga de construirlo
de manera correcta, ya responde al cómo. Cuando se está trabajando en Discovery,
por ejemplo, el Product Owners, diseñadores o equipo correspondiente
realmente lo que está haciendo es detectando, creando y validando nuevas oportunidades
mientras cuando uno ya está en Delivery realmente ya trabaja con un backlog
de ideas validadas y simplemente falta el responder al cómo.
Aunque va un poco abstracto pero yo creo que yendo a través de los ejemplos
quedará bastante claro. Así que realmente de dónde salió la necesidad
en Typhoon de adoptar este framework. Y es aquí donde empieza la historia.
Aparte da la casualidad que aquí es cuando entré en el equipo de producto
y por lo tanto la narrativa espero que salga bien.
Empieza básicamente con el desarrollo de la integración con MailChimp.
Para dar un contexto lo que permite hacer con Typhoon la integración con MailChimp
es básicamente suscribir usuarios a tu lista de e-mail de MailChimp
al rellenar un Typhoon. Esa es lo que automatiza la integración.
Es una integración de pago y realmente hemos visto muy buenos niveles de adopción
incluso de retención los que voy a comentar después.
Y un feedback muy bueno a nivel de experiencia de usuario.
Así que aparentemente parece todo como wow. Realmente porque vamos a sacar aprendizajes de aquí.
Pero realmente hay gato encerrado y es que tardamos ocho meses
en entregar la primera integración de esta integración.
Obviamente en una cultura ágil donde casi hoy es más la palabra MVP por la oficina
que Bitcoin no es cero, es inaceptable. En ese sentido
ya habiendo entrado entregando la integración me senté seguramente
en la retro más intensa que ha habido desde que estoy en Typhoon
para realmente documentar qué problemas había habido en esta integración
y intentar obviamente sacar los aprendizajes para que no pasase otra vez.
Y entre todos estos problemas que veis aquí, que no los voy a leer
porque veía que me se iba de las manos, me centraré en el último.
El problema es literalmente que cada uno en el equipo tenía una concepción diferente
de lo que nos referíamos cuando hablábamos de la palabra MVP,
cuando usábamos la palabra MVP. Como consecuencia de esto y de otros problemas también
ocho meses desde que alguien mencionó Melchim
hasta que entregamos la primera integración de Melchim a los usuarios.
Entregamos lo que conoceremos y veremos después como un love of a product,
un producto que nuestros usuarios ya directamente amaban.
Así que decidimos, el outcome de esta reto salió
el pactar algunas normas para así ya poder alimentar las futuras integraciones
con estos aprendizajes y que es donde creo que sacaréis más valor de esta charla.
Este problema es el que representó una tarea para nosotros como productores.
Se nos pidió básicamente que definiéramos un framework con el que trabajar con el equipo
y fue un ejercicio que presentamos al equipo, obviamente el framework era el de Discovery vs Delivery
y básicamente decidimos qué reuniones, con qué cadencia
y básicamente cómo cada equipo quería adoptarlo.
Entonces, como me gustaría a mí, es un poco hacer el ejercicio
de repasando esta primera integración que fue Google Sheets
aplicando este framework y los aprendizajes que salieron de Melchim.
Remarcar otra vez que el framework lo presentamos a tres equipos distintos
y cada equipo adoptó cómo usarlo.
Así que realmente cómo hicimos Customer Discovery ya para la integración de Google Sheets
que, repito, es la que vino después de Melchim y cómo realmente lo movimos a Delivery.
Perdón si estoy tapando la pantalla.
Imaginemos que esto es una representación de las dos líneas de trabajo
y hoy ahora se empezará a ver más claro ya.
Las flechas azules aquí representan básicamente experimentos
y una cosa que acordamos con el equipo es que los experimentos eran Time Boxed.
Lo que significa esto es básicamente que pusimos un tiempo máximo
en el que trabajaríamos en un experimento.
Si no trabaja dentro de este tiempo o lo ignorábamos o intentábamos ir recortando
hasta que entrase.
Esto lo que nos ayudó es a tener a nivel de equipo
una mentalidad de que realmente ese código iría a la basura.
Si había tajos a tomar a nivel técnico, el equipo lo tomaba
y eso nos ayudó muchísimo.
Otro punto que otra norma que quisimos adoptar para los experimentos
es el tener un objetivo, un target para ese experimento.
Es básicamente una métrica que fuera nuestra referencia para determinar el éxito o fracaso del experimento.
Las flechas verdes ya representan ideas ya validadas que se están desarrollando
para ya ser entregadas un poco más a la calidad del producto de Typhoon.
Las dos líneas de trabajo ocurren totalmente a la vez
por eso veis que están una encima de otra
y esto es otra cosa que salió de presentarlo de equipo porque somos un equipo de hecho personas.
Aquí se decidió que solo se trabajaban, si había desarrollo,
solo se trabajaba en una de las dos líneas de trabajo.
Aun así, diréis, se trabajan una de las dos líneas de trabajo
y en la primera parte la veo que se está trabajando en las dos
y esto es simplemente para remarcar que a nivel de Discovery no hace falta desarrollo.
Por ejemplo, en la primera parte de Discovery lo que hicimos como producto en LCD diseñadores
fue un prototipo en Sketch y empezaron a entrevistar usuarios
para validar si sus diseños eran los buenos o no.
Mientras los ingenieros creo que estaban entregando
si no era la última iteración de Melchim, algo similar.
Para que veáis que realmente en Discovery se puede trabajar sin desarrollo.
Pero bueno, esto quedará más claro en el ejemplo práctico.
Esto es como nuestro equipo de integraciones decidió
tener el backlog de Discovery, el backlog de descubrimiento
a otra vez al presentarlo salieron bastantes propuestas
pero al final lo que se acordó es el backlog de Discovery de descubrimiento
lo tenemos entrelo, cuando una idea está validada
creamos las stories y vamos a gira, que es el software que usamos ya
para entregar al usuario.
Aquí, hecho un círculo, sí se ve, vamos.
Es la primera vez realmente que interactuamos con la idea de Melchim.
La pregunta era, la pregunta a descubrir, digamos,
era ¿qué es lo que nuestros usuarios quieren de una integración con Google Sheets?
Y así es como lo visualizaríamos entrando en esas dos líneas de trabajo.
Aquí es buen momento para recapitular el principal objetivo
de la línea de trabajo de Discovery, es realmente descubrir
si esta es la mejor solución para después pasar a desarrollo.
Versus otras integraciones que podríamos estar desarrollando
porque realmente lo que estamos intentando hacer como equipo de producto
es atacar una área de oportunidad, que en este caso era hacer de Typhoon
un producto más integrado.
¿Por qué eso es una oportunidad?
Pues porque previamente con Melchim habíamos validado
que los usuarios de pago que estaban integrados con Typhoon y con Melchim
realmente retenían un 80% mejor que el resto.
Así que eso nos dio una dirección como que realmente queremos
que Typhoon sea un producto más integrado
y seguir ampliando esta estrategia con más integraciones.
Así que ¿cuál es realmente el primer paso para descubrir
si esta era la solución correcta?
Realmente creo que es algo que se puede aplicar a cualquier idea que tengamos
que es el de hablar y entender a los usuarios o a los potenciales usuarios
de este producto.
En otras palabras básicamente Customer Discovery.
Aquí hay un ejercicio muy fuerte como productones de análisis
cuantitativo y cualitativo.
En el caso de Typhoon miramos mucho tickets de soporte,
de atención al cliente, análisis de la competencia del mercado,
entrevistas con usuarios.
En el caso del final con un solo objetivo que es el de realmente
entender el contexto de estos potenciales usuarios
que están pidiendo la integración
y ayudarles a progresar en su día a día.
Y aquí quiero mencionar un momento, un framework que usamos
y que nos está ayudando mucho, que es el de Jobs to be done,
también se conoce como Costume Jobs.
Va para una charla entera pero sí que quería decir en dos frases
cómo nos ayuda realmente a hacer este tipo de análisis
que realmente es un framework que nos ayuda a poner mucho énfasis
en el contexto y en este sentimiento de nuestros usuarios,
de nuestros usuarios hablo del mundo del software en general,
de constantemente progresar en su día a día.
Lo he experienciado yo mismo y creo que muchos otros product owners
o product managers, solemos enamorarnos de una solución
o solemos tener cosas en mente pensadas.
Lo que haces Jobs to be done, este aparta,
es totalmente agnóstico la solución que tienes en mente
y lo que haces es ayudarte a analizar
del usuario que tienes en frente, ayudarte a analizar ese contexto.
Lo que le rodea, que es lo que realmente le ayuda a progresar.
Este stage, por lo tanto, no requiere desarrollo,
por eso vemos que en las dos líneas se está trabajando
y suele ser el esfuerzo colaborativo de UX, customer success,
marketing, data, producto, varios departamentos.
De aquí lo que tiene que salir es bien definido el problema
que estamos solucionando con esta posible idea
y ya es hora de considerar qué diferentes soluciones podemos
o cómo podrías esta integración, cómo se podría ver.
El objetivo de este segundo stage en Discovery, básicamente,
es poner algo delante de los usuarios lo antes posible.
Cuanto más mínimo sea el esfuerzo requerido ya para desarrollar algo,
antes podrás aprender e iterar en la dirección correcta.
Esto es la base de Agile, así que no debería sonar a nuevo.
Algunas de las estrategias que usamos en esta etapa,
jugadas, las llamo y a ver por qué después,
es por ejemplo prototyping,
testeando con usuarios prototipos que ponemos con diseño, sin desarrollo,
design sprints, hemos tenido muy buenas experiencias con los sprints de diseño
donde si empieza su lunes, el viernes ya tenés un prototipo
testeado con usuarios y en definitiva user testing al por mayor.
En el caso de Google Sheets, lo que hicimos es tener un producto testeable
y con desarrollo incluido.
¿Cómo lo hicimos?
Creo que alguien va a flipar. El Polska le ha contado, por cierto.
Alguien va a decir, este que le ha contado.
Básicamente, nos fuimos a una casa, pillamos una casa en la montaña,
una semana, mínimas distracciones en la oficina no hubiésemos podido hacerlo
y lo que pasaría ahí ya os lo cuento después con una cerveza,
pero en definitiva dimos aluz a la primera iteración de nuestra integración con Google Sheets.
Es una semana, increíble.
Si lo ponemos en contexto, MailChimp, ocho meses, Google Sheets,
una semana, es bastante fuerte.
Pero realmente no quiero remarcar la velocidad,
no quiero remarcar que trabajásemos más horas de los que eran porque no es la verdad.
Tampoco que fuéramos a dos redbulls por hora.
Lo que quería remarcar es que con la ayuda de este framework,
lo que nos ayudó a tener esa predisposición a nivel de equipo,
a realmente ofrecer lo mínimo para hacer funcional esa hipótesis con la que he trabajado el principio.
La importancia realmente de entender como equipo que el código con el que trabajas irá a la basura.
Otra vez que los atajos técnicos en esta etapa son totalmente aceptables.
Así que prescindimos exactamente de mucha funcionalidad
y aquí ayudó mucho el hecho de tener acordado, como he comentado antes, el límite de una semana.
Una herramienta también muy útil para perfilar estos experimentos es el Moscow.
Ustedes no saben los colores.
Bueno, el Moscow básicamente lo que nos ayuda
es a definir los diferentes criterios de aceptación de nuestra iniciativa
como must, should, could o want.
Básicamente el primer experimento de nuestra experiencia suele estar compuesto por el primer must.
En este caso, y leo de aquí, era literalmente como usuario de la integración de typeform con Google Sheets,
quiero que mis nuevas respuestas del typeform se populen automáticamente en la spreadsheet.
Así que por ejemplo dejamos fuera la funcionalidad de popular resultados y existentes
que fue lo que identificamos como un shoot.
Para hacerlo un poco más fácil de entender, simplemente lo que identificamos en costumbre de intervios
es que lo que añadía valor a una integración con Google Sheets es que el hecho que cada vez que respondía un typeform
esa respuesta iría directamente a spreadsheets.
La segunda funcionalidad que era que las respuestas que ella tenía en el momento que yo me integren
vayan a esa spreadsheet, esa funcionalidad era importante, salió de las costumbre de intervios
pero la sacamos de la hipótesis.
Por lo tanto era el primer shoot, atacar después de ese experimento.
El resultado, un earliest testable product, en contraste con la primera entrega de Melchim
fue directamente un loveable product.
Lo abrimos al 20% de nuestros usuarios y realmente vimos excelente adopción,
feedback de que la experiencia era muy nítida y realmente lo que conseguimos es coger feedback
y coger una dirección a un par de cambios de hacer, obviamente había unos cuantos bugs a arreglar
pero ya después de esto pudimos abrir al 100% con el mismo experimento, un poco más estable ya.
Los siguientes pasos básicamente ser super reactivos al feedback, iterar en el diseño
y realmente el ejercicio fuerte estaba a intentar entender cómo realmente un producto tan barato
a nivel de coste de desarrollo les ayudaba a progresar.
Esto nos dio un mosco muy claro otra vez para ya pasar la delivery
y una opinión mucho más informada de cómo y por qué nos estaban usando o se usaría esta integración.
Así que básicamente lo tocaba estimar con ingenieros cuando ya cuesta entregar esta solución,
socializar con otros departamentos, esto yo lo subrayaría casi porque es algo que nos ha ido muy bien,
sobre todo por ejemplo hablando socializando esta solución con Account Management.
Account Management en nuestro caso trata con las cuentas más grandes, las cuentas Enterprise
y muchas veces son usuarios que normalmente el día a día no hablamos con ellos
y sí que alguna vez hemos dicho, esto se nos ha pasado por alto precisamente por eso.
Entonces Account Management es crucial que entre en este stage.
Y básicamente decidir si mueve o cuándo a delivery, que de hecho es el stage en el que estamos.
Tenemos un producto abierto al 100% de los usuarios en beta
y estamos trabajando en refactorizar el código y añadir funcionalidades,
entre ellas el primer shoot y a popular respuestas que tengas en el typeform.
Así que aparte de validar este experimento lo que hemos validado realmente es que la consecuencia
de pasar por el Customer Discovery es un baclo que ya de ideas validadas
y el sueño creo al menos de todo Product Manager.
Del arretro del feedback del equipo salió básicamente también que estamos por primera vez alineados
en cuando hablábamos de MVP a qué nos referíamos.
Y esto ayudó lo que voy a presentar ahora.
Si os fijáis se ha mencionado jugadas o estrategias un par de veces
y con esto ya acabaré y es el typeform Product Playbook.
Que básicamente es un manual de jugadas un poco usando la analogía del formato de fútbol americano
que ayuda a identificar las diferentes estrategias o las diferentes jugadas
con las que afrontar las etapas de o descubrimiento de valor, el Discovery,
o la entrega de soluciones ya después del delivery.
Este vendría a ser un poco el formato.
Se verá muy pequeño, bueno, mucho poder.
Básicamente dependiendo de la etapa en la que estemos de Discovery o Delivery
hay diferentes jugadas que podemos usar.
Y lo que hacemos es cruzar estas jugadas con los conceptos y representaciones
de Henry Knickberg, de Spotify, de earliest testable, usable y lovable product.
Esto básicamente nos ayuda a no volver a cometer el error,
ese que he mencionado, de realmente confundir el término MVP
y definir correctamente cuál es el enfoque según la etapa en la que estemos de Discovery o Delivery.
Repasemos entonces brevemente ya para concluir las etapas en Discovery.
La primera etapa es identificar las oportunidades donde nuestros usuarios
realmente podrían encontrar valor.
Ya seguido por la etapa de brainstorming soluciones
y encontrar el valor y cómo pueden atacar estas oportunidades que hemos identificado.
Y por último y más importante la consecuencia, el final del Discovery
que tiene que ser un earliest testable product.
El experimento básicamente más barato que puedas conseguir para validar tu hipótesis inicial.
Escogida ya ha evaluado su valor, la iniciativa podría pasar a Delivery.
Desde el primer paso que hemos mencionado es estimar ya con los ingenieros
y pasar ya a una etapa donde realmente cumpla con la funcionalidad mínima
para ya la definición de MVP, la que todos conocemos, que sea como mínimo usable.
A esto ya le seguiría el consecuente trabajo de desarrollo
y ya entregar la funcionalidad para que sea usable lo antes posible,
así poder aprender en esa etapa de aprendizaje y de iteraciones
hasta que sea el lovable product con el que acaba.
El uso de estas jugadas quiero remarcar que no es exclusivo en la etapa a la que están asignadas.
Las etapas realmente están donde las hemos encontrado más útiles
y de hecho nos reunimos cada viernes como foro de producto y las movemos.
Alguien, un pillón, nos dice, oye, usa un Design Spring en Discovery
para testear este producto y le añadimos el link al ejemplo.
O sea, no nos lo toméis como una biblia, sino de hecho es un documento que está constantemente cambiado.
En definitiva es un manual que a nosotros nos va perfecto
y ojalá lo podáis hacer vosotros, tener impreso en el área de tu equipo
y ir añadiendo estas jugadas y estrategias usadas en diferentes experimentos
para ya compartir con otros equipos de productos.
También lo que voy a hacer es recoger emails si puedo
para enviaros esto y de hecho un Product Manager de Typhoon
tiene un artículo que lo explica mucho mejor que yo
y junto a otro material relevante de esta charla.
Y ya para acabar, porque se me ha alargado mucho entre cosa y cosa,
básicamente quería cerrar el tema de Discovery
y abrirlo ya a preguntas y todo, pero realmente lo que no quiero que os lleguéis
es que en Typhoon no desayunamos cada día con nuestros usuarios,
eso sería la idea equivocada.
Pero sí que al adoptar este framework nos ha promovido el tener esta mentalidad
de realmente acercarnos lo máximo,
involucrarnos en las conversaciones muy temprano con ellos
desde puramente ideación, durante experimentación y desde entrega.
Eso es la idea que quiero un poco que os envíais. Gracias.