Experimentación: aprende de forma rápida, segura y económica
Rodobo no era más que un experimento personal.
Bienvenido, bienvenida a Rodobo, un boletín quincenal que explora la relación entre el diseño de producto, la experimentación, los datos y las empresas.
Soy Juan Rodriguez Talavera y hoy te escribo feliz de poder empezar la nueva aventura de este boletín que empezó siendo un experimento con el objetivo de ayudarme a coger el hábito de escribir, leer y hablar con personas con intereses similares sobre producto digital.
Conversaciones
Sobre Product Management,
Esta edición del (renovado) boletín tiene conversación. Ya las echaba de menos.
Hace unas semanas tuve el placer de hablar con Irene Prieto y María Granadino, Product Manager y Product Owner del Digital Hub de Ikea, sobre gestión de producto.
Irene y María han publicado en Domestika un curso de introducción al product management, así que aprovechamos para hablar de ello y sobre muchos más temas.
Tienes el episodio aquí abajo y en este enlace.
Sobre experimentar
Me encanta experimentar. Durante los últimos años he llevado a cabo un montón de experimentos que me han entusiasmado mucho. Algunos de ellos internamente, con mis procesos, mi forma de escribir, pensar, organizarme (mi Notion personal ha cambiado 100 veces en apenas unos meses), y otros con productos digitales y organizaciones.
De entre toda esta experiencia, una cosa que he aprendido es que un experimento interno es un pequeño cambio que tiene como objetivo resolver un problema, en mi caso de hábitos y organización.
Podría decir, después de todo este tiempo, que el experimento de este boletín y las charlas han abordado:
Cómo de cómodo me encontraba escribiendo regularmente
Cómo tomaba decisiones sobre el momento para escribir y sobre qué temáticas hacerlo
Cómo elaboraba (o no, porque apenas he sido constante) estrategias para dar a conocer este proyecto
Cómo reducía la dependencia de leer más o leer menos (tengo el síndrome de comprar muchos libros y no leerlos todos. Aquí bromeé sobre ello)
Cómo de seguro me encontraba hablando sólo (con otra persona en un podcast). No es lo mismo hacerlo con Jorge y Carlos como anfitriones en Dale Una Vuelta que en solitario
Cómo quería que las personas se sintiesen al estar charlando conmigo
Cómo compartía información
Cómo impactaba en mi trabajo
Podría decir que de este experimento saco todavía más claro qué quiero hacer, qué me mueve y me motiva.
Este proceso podría definirlo con esta maravillosa imagen que encontré de Doris McComics sobre la creatividad.
Pero bueno, dejemos atrás experimentar en mis procesos (en otro boletín explicaré cómo gestiono las ideas) y pasemos a la idea central de esta edición.
Experimentar es el producto, no la tecnología
Como analista digital de formación que trabaja cerca de diseño y que cada vez más se está acercando al desarrollo, siempre me emociona descubrir nuevas definiciones sobre el trabajo de experimentación.
Hace unos días, hablando con Danny Saltaren, él hizo esta definición sobre su máxima de experimentación “Cabeza de analista corazón de diseñador. Enfocado a negocio” que me hizo pensar en que los experimentos son un problema de producto, no de tecnología, y cómo con el no-code, estamos conceptualizando aún más esta definición.
Al resolver un problema de tecnología, nos preocupamos por asegurarnos de que el software funcione. Queremos tener una solución para todos los casos extremos posibles antes de la implementación. Queremos que el código sea confiable, factible y escalable, y estamos solucionando los errores que se interponen en el camino de estas tres cosas.
He notado muchas veces en este tiempo cómo en ocasiones tratamos a los experimentos como si tuvieran que funcionar. Y sin embargo, forzar un experimento para que funcione cuando no debe hacerlo pierde información valiosa sobre por qué no funciona.
Eso no es tratar los experimentos como un problema de producto.
Cuando resolvemos un problema de producto, nos preocupa si nuestro producto es una idea viable. Queremos identificar las necesidades insatisfechas o desatendidas de las personas y comprender si nuestra idea satisface esas necesidades.
Aunque siendo justos, la similitud entre los problemas de producto y los tecnológicos, es común: si falla, queremos minimizar las consecuencias. Queremos saber todas las formas posibles en que puede salir mal de una forma temprana y segura, y es por eso por lo que existen entornos de prueba, fases de control de calidad y es por lo que, además, la entrega continua es una filosofía generalizada hoy en día.
Aprende de forma rápida, segura y económica
Pensar en un experimento como una apuesta en lugar de una característica que debe funcionar aísla la mentalidad de que todo experimento debe funcionar.
En lugar de preguntar "¿cómo podemos asegurarnos de que esto funcione?" pasamos a "¿qué podemos aprender si esto no funciona?".
El cambio es drástico y significativo. De esta forma el diseño específico de tu experimento dependerá de:
Problema que estás intentando resolver
El contexto de dónde lo pruebas
Y pensar en la mejora continua como un desafío de producto ayuda.
El no-code y la transversalidad, entendida como la amplia capacidad de perfiles que podemos desempeñar en la actualidad, nos ha capacitado más. Nos ha dado las armas necesarias para pasar de un problema tecnológico en experimentación a un problema de producto. Para educar en que la filosofía correcta no debe ser el experimento que te ayude a mejorar ventas sino el que te dé más luz a lo que debes construir a continuación en una relación a largo plazo.
Un par de recursos
Un par de recursos que complementan este texto.
Cómo hacer mejores experimentos por John Cutler del equipo de producto de Amplitude HQ, guías retrospectivas y el caso de los Squads de Spotify como experimento organizacional y por qué no funcionó al aumentar dependencia entre equipos.
Una guía para observadores de buenas retrospectivas - Adrian Howard
Independencia, autonomía y demasiados equipos pequeños de Kislay Verma
Una frase
Haz mejoras, no excusas. Busca respeto, no atención. – Roy T. Bennett
Sinceramente…
Reconozco que los momentos de migración de una plataforma a otra estuvieron llenos de estrés y que el número anterior fue totalmente improvisado.
Inconscientemente me preocupaba fallar y no sacar edición, olvidándome de lo que he aprendido y de lo que explico sobre experimentación en esta edición.
Ya estamos aquí y lo primero, con sinceridad es que la lista de personas suscritas ha bajado de 411 a 337 (ya este número me parece una pasada). ¿Por qué? Porque llevaban sin abrir una edición, aproximadamente, un año y medio.
¿Qué objetivo tengo con esto? Ver cómo afecta a las métricas del boletín. Obviamente tengo a esas personas en otro grupo e intentaré hacerles llegar esta edición de otra forma más personal con un enlace directo.
Os seguiré contando en próximos boletines.
Gracias por haber llegado hasta aquí.
Nos leemos,
Juan
Por cierto, la foto principal la hice en Madrid en el Cerro del Tío Pío de Vallecas. Cuando cae la noche tiene unos atardeceres increíbles.