Experimentar

El superpoder de la ciencia 👩🏻‍🔬

Como la innovación y las startups siguen estando bien de moda, palabras como “Prototipo” o “Experimentar” tomaron una connotación positiva.

No siempre la tuvieron.

Cuando mi socio Jorge fundó Continuum, le iba a poner un nombre un poco más largo. El nombre era “Continuum Prototypes”. Pero le dijeron que eso de prototipos se escuchaba poco serio y nos quedamos con el nombre corto. De repente fue para mejor, porque Continuum ya tiene su dificultad como nombre — es frecuente que nos digan “continium” con una “i” entre medio y hasta hemos considerado comprar el dominio 😅. Con apellido adicional las confusiones serían mayores, creo.

Experimentar también sonaba poco pro en un mundo donde creíamos que el trabajo era primero pensar y pensar mucho para llegar a una idea y diseño de solución potente. Luego ejecutarla casi como algo aparte. Aún recuerdo un ex-presidente de Chile sacándose los pillos con que el diseño del Transantiago habría estado bueno y los problema serían tan solo de “implementación”.

El mundo además de complejo cambia muy rápido para que eso funcione (y tampoco es que funcionara muy genial antes) así que ahora esto de experimentar ya es aceptado incluso mas allá que startups o áreas de innovación. Para empezar suena en las transformaciones, en unas cuantas metodologías ágiles, etc.

Y sin embargo, del dicho al hecho hay mucho trecho.

Partiendo por nosotros.

Sobre todo si en el trabajo nos dan el espacio para experimentar, mi experiencia es que lo usamos poco y mal.

El tip de hoy tiene que ver con partir por casa. Con que sepamos cuándo estamos experimentando en serio y cuándo estamos experimentando al tun-tun. Es una distinción importante para que cuando nos den espacio para experimentar, le saquemos el jugo.

En realidad es simple. Basta con desenredar el concepto y entender que le podemos llamar experimentar a un par de cosas muy diferentes:

• Está la version de “experimentar” estilo pegarnos un viaje de ácido a ver qué pasa. Esta es la versión más coloquial de la palabra.

• Y está la versión de jugársela con una hipótesis de lo que creo que va a pasar cuando ejecuto algo, ejecutarlo y luego ver si acerté o erré. Si aciertas la hipótesis se fortalece, si erras vuelves atrás y evalúas de nuevo lo que creías. Esta es la versión más científica.

“Estoy experimentando con React” suele ser la versión coloquial.

“Experimentemos cambiando los colores” también probablemente es la versión coloquial.

Una vez que conoces la distinción una forma que casi siempre sirve para identificar la versión coloquial es agregar “a ver qué pasa” al final de la frase. Si la frase (en su contexto) sigue tiene sentido entonces era experimentar al tun tun, no muy científico.

Tampoco digo que conviertas tooooodo a versión científica. Pero ayuda un montón cuestionarse si no vale la pena ponernos científicos en algunos de nuestros “experimentos” coloquiales.

---

Hace 6 meses comencé a dictar cursos internos en Continuum. Por el momento sólo están disponibles para “medusas” (así nos decimos a nosotros mismos en Continuum por nuestro logo, que por cierto no es cualquier medusa).

Uno de esos cursos se titula “Early Stage Product”. Está orientado a medusas que están trabajando o empezando con nuestros actuales ventures o prototipos que esperamos se conviertan en lo que llamamos “ventures”: productos internos o dónde Continuum tiene participación.

El curso es un destilado de todo lo que hemos aprendido, cagándola con productos como Rhyboo, TestMyUX o Haus — si no te suenan es porque murieron 😅 — y también acertando con Get on Board o con clientes geniales como Archdaily. Está lleno de tips y contenido que es contra-intuitivo si uno ha trabajado antes medio aislado en su mundo y relativamente lejos de los clientes y usuarios del producto (lo que incluye la manera en que funcionan la mayoría de células “ágiles”, por cierto).

El otro curso se llama “Product Thinking, for Consultants”. Es un curso pariente del anterior pero enfocado en cómo nos llevamos hacia la consultoría lo que aprendemos haciendo productos propios. Y como lo aplicamos con nuestros clientes o incluso se lo enseñamos a sus equipos. Es, de alguna forma, lo que nos hace diferentes de cara a nuestros clientes.

En general uno en Continuum aprende esas cosas por osmosis. Se te pegan trabajando con tus compañeros. Pero este era mi plan para ir sistematizando mejor esto para acelerarnos a nosotros mismos.

Para comenzar con el curso me hice una tabla de contenidos en Notion y salí a buscar “clientes”. Les dije que el curso requeriría entre 4 y 8 horas semanales de dedicación que no están cubiertas por el horario laboral (era como tomar cualquier otro curso en cualquier otro lado). Me fue bien, conseguí 7 alumnos.

Igual 7 alumnos no suena a tanto.

Pero cuando digo que me fue bien, es porque mi hipótesis era que con una promesa y una tabla de contenidos podía conseguir que se animaran al menos 4 personas (2 por curso, que es como el mínimo para llamarlos curso). Si eso pasaba, alguien quería aprender lo que yo quería enseñar, y estaba dispuesto a invertir. No plata (por ahora), pero sí tiempo.

Con el feedback de ellos valdría mucho más la pena ir escribiendo el curso.

---

El ejemplo es simple pero me permite ilustrar mi punto. El yo-de-hace-varios-años atrás habría armado gran parte del curso (“a ver qué pasa”). Lo sé porque lo hice varias veces y tengo contenido a medias por ahí botado.

Lo sé porque también tengo mi propia colección de proyectos a medias y dominios comprados para jugar a inventar un producto que luego dejé a medias. Otros los alcancé a lanzar (“a ver qué pasa”) pero ahí quedaron (no pasó mucho).

Me aburrí de eso y por eso ahora experimento un montón. Además es entretenido.

Incluso si te va mal con un experimento, el haber tenido claro desde el principio lo que querías conseguir (y no tan solo “ver que pasa”) te da ideas para volver a intentarlo. Contrario al estado anímico que normalmente nos provoca fallar, pasas rápido del “buuuu 😒” al “ajá 🤔”.

Early Stage Product duró apenas 4 semanas porque sobrecargué demasiado a los alumnos. Algo aprendí de ese fail porque en el otro curso nos duró la cuerda 4 meses. Ya estoy introduciendo cambios en Early Stage Product para que la siguiente generación (que comienza en Abril) tenga un ritmo más sostenible.

Experimentar en serio te ayuda a combinar el disfrute del “hacer” con el disfrute del “conseguir”. Vas entrelazando ambas cosas, lo que como decía mas arriba, es muy entretenido.

Y por último, experimentar en serio puede ser la puerta para aprender otra cosa. Algo que al menos yo no lo aprendí en la U ni en mis primeros años laborales. Algo que hace demasiada diferencia en que la rompas en este mundillo de la tecnología. Y a la vez algo muy simple:

Conectarte con los problemas que resuelves.

Al final nuestro futuro profesional está ligado a que hay problemas que se resuelven a través de las herramientas de nuestra disciplina, lo que nos permite crear soluciones. Pero es bueno ir generando práctica en no siempre partir desde la solución, sino que desde el problema.

“People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.”

— Theodore Levitt

Suena medio filosófico y — para ser sincero — no es una distinción de blancos y negros. Pero cuando empiezas a experimentar en serio (más científico, menos coloquial) esto de enfocarte en el problema y no tan solo en la solución se transforma en algo práctico y se te empieza a generar un hábito.

Ese hábito vale oro para romperla en este mundillo del software. Porque al final del día, la mayoría de la gente no quiere software.

Nota: Me voy de vacaciones por varias semanas 🎉. La siguiente entrega será el Viernes 9 de Abril. Mientras tanto, feliz que me escribas de los temas que te gustaría que escribiera durante el año. También leeré y responderé comentarios 😉.