Elige soluciones aburridas

Una de mis publicaciones favoritas de todos los tiempos es Choose Boring Technology de Dan McKinley. En esa publicación, Dan explica por qué es importante limitar el número de incógnitas con las que un equipo tiene que lidiar en un momento dado.

Él introduce el concepto de tokens de innovación como una forma sencilla de rastrear y limitar la introducción de tecnologías o arquitecturas poco familiares. Se consume un token de innovación cada vez que usas una nueva tecnología o concepto que requiere una curva de aprendizaje considerable, y solo dispones de 3 tokens de innovación al comienzo de tu recorrido.

El objetivo es crear un stack en el que la mayoría de las partes sean aburridas – es decir, que el equipo pueda entenderlas e implementarlas fácilmente. La idea no es elegir mala tecnología, sino más bien minimizar el tiempo dedicado a aprender cómo funcionan las cosas, y maximizar el tiempo dedicado a entender lo que quieren los usuarios.

Por ejemplo, una startup nueva no necesita empezar con Kubernetes, sobre todo si aún no ha encontrado su product-market fit. E incluso una empresa consolidada no necesita reescribir su servicio de facturación crítico en Rust si es la primera vez que el equipo se enfrenta a ese lenguaje.

Existen muchas tecnologías excelentes. Pero la mayoría de las empresas no las necesitan para hacer felices a sus usuarios y hacer crecer su negocio.

La innovación tiene que suceder, sí, pero solo 3 tokens a la vez.

Lo aburrido también aplica a la estrategia

La publicación de Dan se centraba sobre todo en ingeniería, pero se traslada muy bien a la estrategia. Defines tus OKRs, y luego defines la mejor hoja de ruta y tácticas para alcanzar los objetivos recién establecidos.

Pero el problema con la estrategia es que es muy difícil predecir qué va a funcionar. La mayoría de los experimentos fracasan, y es bastante probable que el 25 % (¡o más!) de tus proyectos no entreguen los resultados que esperas. Por eso deberías tratar los proyectos como apuestas. Algunas apuestas funcionarán, y entonces apostarás aún más fuerte por ellas. Pero otras apuestas fallarán el objetivo, y debería ser fácil descartarlas.

Así que la pregunta es:

¿Cuál es la forma más rápida de descubrir qué funciona y qué no?"

De forma similar al problema tecnológico, tu objetivo debería ser minimizar el tiempo dedicado a poner en marcha apuestas y maximizar el tiempo dedicado a aprender de tus clientes.

Y una forma de facilitar eso es elegir soluciones aburridas.

Una vez más, aburrido no significa malo. Solo significa que deberíamos elegir enfoques que ya conocemos o que son fáciles de aprender, para poder llegar rápidamente al punto en el que probamos nuestras ideas. También significa hacer cosas que no escalan antes de construir la versión automatizada de ello. Cuanto más complejas hacemos nuestras soluciones, por muy innovadoras que sean, más tiempo pasa antes de que podamos obtener feedback y datos reales.

Recuerdo claramente el ejemplo de un negocio de venta minorista online que probó un nuevo enfoque para las devoluciones haciendo que los desarrolladores imprimieran manualmente códigos QR para un grupo de usuarios. Rápidamente aprendieron que su solución propuesta no funcionaría, incluso si se automatizaba. Se ahorraron 3 meses de trabajo al elegir una forma aburrida de probar su apuesta, y luego cambiaron rápidamente su enfoque hacia otras oportunidades en cuanto se dieron cuenta de que no era una buena idea.

En Tability, recientemente añadimos una lista de estados de tareas para permitir más flexibilidad que un simple "abierto"/"cerrado" (ej.: planificado, en progreso, en revisión, hecho...). Sabemos que la mejor solución sería permitir personalizar la lista, pero decidimos lanzar una lista estática más simple como MVP. El uso de tareas creció un 20 % como resultado, y ahora podemos trabajar en una solución más sofisticada.

Algunos otros ejemplos:

• Comprar una solución de email marketing ya probada en lugar de montar tu propio servicio de newsletter.
• Usar Qwilr o Canva para probar rápidamente una presentación de ventas en lugar de esperar varias semanas para conseguir un diseño personalizado.

Valida con lo aburrido, escala cuando aumente la confianza

A nuestro cerebro le encanta la novedad. Hay algo bastante emocionante en explorar nuevas tecnologías, y es difícil resistir la tentación de aplicar soluciones innovadoras a problemas complejos.

Pero siempre deberíamos optimizar el tiempo hasta obtener feedback. Es decir, cuánto tiempo pasa antes de que puedas obtener feedback real del mercado. Cuanto más aceptamos que podemos equivocarnos, más fácil es empezar en pequeño.

Luego puedes iterar a medida que aumenta tu confianza.

• Empieza con un MVP aburrido: este es el enfoque no escalable que deberías poder entregar en un par de semanas. Puede que no cubra todos los casos de uso, y puede que el enfoque subyacente no sea bonito. Pero es una forma sencilla de validar tu apuesta y confirmar que vas por el buen camino.
• Luego, mejora a una solución aburrida: la solución aburrida sigue construida con herramientas y métodos sencillos. Pero ahora estás cubriendo algunos de los casos extremos y automatizando las tareas manuales.
• Por último, optimiza con innovación: una vez que estés bastante seguro de haberlo logrado, y cuando también sientas la necesidad de escalar, entonces puedes mirar enfoques innovadores para tu problema. Pero eso debería ser poco frecuente. Una solución aburrida será suficiente en la mayoría de los casos.

Una última reflexión antes de terminar. Una solución aburrida no debería resultar en una experiencia de usuario de m*erda (pardon my French).

El umbral mínimo para la UX es "Bueno". Hay una gran diferencia entre encontrar una forma sencilla de entregar algo bueno y bajar tus estándares para entregar un proyecto más rápido.

Puedes reducir el alcance de tus proyectos, pero no puedes disminuir la calidad de tus entregables.

--

¿Usas OKRs? Tenemos una forma "aburrida" de simplificar el seguimiento en lugar de crear tu propia hoja de cálculo → Descubre Tability.