El arte de posponer decisiones
- Estrategia de Producto <simonmunoz@substack.com>
- Hidden Recipient <hidden@emailshot.io>
El arte de posponer decisionesEl mayor riesgo no es equivocarse rápido. Es quedarse paralizado analizando escenarios que nunca llegarán.
Hace unos meses escribí uno de tantos artículos en esta lista de correo sobre la importancia de la distribución: la gente no vendrá. En él describía como, en realidad, no importa mucho cuántas funcionalidades añadas a tu producto si no consigues captar a usuarios:
Una derivada importante que no relacioné en ese momento, aunque sí en otros artículos como en Sobreingeniería: el arte de resolver problemas que aún no existen, es la cantidad de tiempo que perdemos en la industria preparándonos para algo que probablemente no vaya a pasar, como puede ser escalar. Es curioso como la mente ingenieril juega en nuestra contra en estos casos. El poder anticipar todo lo que puede pasar al construir un producto, puede acabar haciendo que no lo construyas nunca porque te quedas paralizado analizando todas las posibilidades. Mientras tanto, los que no saben lo que no saben, generalmente gente sin experiencia o background de ingeniería, son capaces conquistar un mercado con un producto que te hace querer arrancarte los ojos. Simplemente porque llegaron primero a resolver el problema de sus clientes e iteraron desde esa posición de ventaja. Esta es la gran virtud que tienen las startups y los equipos pequeños. La falta de recursos te impone preocuparte sólo de lo importante e ignorar todo lo demás. ¿De qué sirve preocuparse por escalar si lo mismo no llego a pagar las nóminas a final de mes? Y me ha dado por pensar, ¿habría alguna forma de prevenir caer en la parálisis por análisis en organizaciones más establecidas? ¿Cómo podríamos volver a recuperar la agilidad de los primeros días? Diseñado para fallar¿Y si en vez de diseñar soluciones pensando que van a funcionar las diseñáramos con el objetivo de que fallaran? ¿Tendría sentido pasarnos días diseñando la estructura de datos? ¿Tendría sentido cubrirla de tests de integración antes siquiera de lanzarla? En mi equipo en Voicemod lanzamos varios experimentos por semana. Muchos de estos experimentos fallan y su código nunca llega a desplegarse a todos los usuarios, pero de cada uno de ellos aprendemos valiosos puntos de información que nos ayudan a diseñar mejores soluciones en el futuro. No tendría sentido invertir días en protegernos de situaciones que quizás no se den nunca, así que tenemos un acuerdo tácito entre producto e ingeniería de forma que si un test funciona y valida una funcionalidad, le reservamos tiempo a posteriori para cubrir todos los aspectos que la harán más robusta en producción. En cierto modo, y aunque nunca lo he expresado así, podría decirse que diseñamos con la idea de fallar. O de aprender fallando. Soy un firme creyente de que el aprendizaje real sólo surge de poner el producto en manos de los clientes y usuarios. Y para hacerlo eficiente, el flujo de desarrollo y la velocidad de iteración son críticos Decidir lo más tarde posibleIba a cerrar el artículo, cuando releyéndolo me he dado cuenta de que no he contado nada que los mejores y más experimentados equipos de ingeniería no conozcan ya. Decidir lo más tarde posible, es uno de los principios que Mary y Tom Poppendieck adaptaron del afamado sistema de producción de Toyota al desarrollo de software en su libro seminal, Lean software development : an agile toolkit. Citando el resumen de la Wikipedia:
Una versión menos teórica y también más basada en la experiencia sobre este principio la encontramos en el siempre recomendable blog de Eduardo Ferro, Lean Software development: The art of postponing decisions:
ConclusionesNo sabía muy bien sobre qué iba a escribir cuando hoy comencé esta entrada. Pero tenía la certeza de que si me ponía delante del ordenador e iba hilando temas que me rondaban la cabeza sería capaz de construir algo lo razonablemente aceptable para enviarlo. En cierto modo, he puesto en práctica lo que he contado. Generalmente, es mejor lanzarse a la acción que paralizarse esperando tener la solución perfecta. La alternativa hubiera sido no enviar este artículo y perder la oportunidad de aprender de vuestras reacciones al mismo. ¿Tendrá más lecturas o menos que otros artículos? ¿Interesará el tema? ¿Generará interacciones? Todos estos datos sólo se pueden conocer lanzando, y en ocasiones, lanzando cosas que nos dan vergüenza. La agilidad, especialmente en startups, no viene de tener todas las respuestas desde el principio, sino de la capacidad de adaptarse rápidamente a lo que realmente sucede al lanzar un producto al mercado. Priorizar el aprendizaje continuo por encima de una planificación perfecta es clave para generar impacto. El mayor riesgo no es equivocarse rápido. Es quedarse paralizado analizando escenarios que nunca llegarán. |
Similar newsletters
There are other similar shared emails that you might be interested in: