No pierdas el tren
Es mejor entregar poco a tiempo, que todo tarde
Esta semana parecía que no llegaba. Es lunes por la tarde y estoy en la estación de AVE, acabándome un agua, y todavía no he podido ni escribir un borrador. Todas las semanas, reviso mi lista de ideas, voy dando forma a los temas que me inspiran esa semana y por último escojo un artículo y le termino de dar forma.
Aun así voy a aprovechar para tratar un tema que considero crítico en un buen equipo de producto. La capacidad de entregar valor en el tiempo en el que se ha comprometido.
Cada vez que hablo de este tema no puedo evitar pensar en el temible triángulo de hierro de la gestión de proyectos.
Si asumimos que todo el equipo de producto está dedicado a un desarrollo y que el equipo descubre y programa a una velocidad constante, cuanto más tiempo le dejemos trabajar al equipo, mayor es el alcance que podemos esperar.
Entonces, cómo podemos asegurar de que entregaremos una funcionalidad en una fecha.
Jugando con el alcance.
Hace dos semanas, el equipo quería validar una nueva funcionalidad con usuarios desplegando una primera versión en la aplicación. A pesar de que la funcionalidad era sencilla, había una serie de cambios a desplegar en el backend en paralelo a la nueva pantalla de la aplicación.
El objetivo no era desarrollar la funcionalidad, el objetivo era probar la pantalla con usuarios para recoger feedback para seguir iterando el producto.
Quien sabía que, a mitad de semana, los desarrolladores de backend iban a tener que implementar una serie de cambios en la cola de mensajería interna para poder asumir el crecimiento de usuarios inesperado que tuvimos esa semana.
En este caso los equipos ágiles de producto pueden tomar una de estas dos opciones:
Parar el desarrollo de la funcionalidad hasta que el problema que estaba perjudicando el servicio se solucione y entregar la funcionalidad unos días más tarde.
Cambiar el alcance de la funcionalidad para que no dependa de backend e ir validando la funcionalidad del frontend con un despliegue parcial.
Seguro que al leer las opciones muchos os decantáis por la segunda. Pero ¿cuántas cosas se retrasan por culpa de imprevistos? El día a día no hace más que traer excusas: bugs, modificaciones para un cliente importante, reuniones de preventa, …
Para poder tomar estas decisiones es importante que no evaluemos tanto a los equipos por las funcionalidades que sacan y más por los resultados que obtienen.
— ¿Cuál era el objetivo? Probar si los usuarios utilizaran la nueva funcionalidad.
— ¿Los usuarios la usan? Si o no, pero el alcance no debería importar.
Por eso es importante que los equipos cumplan con esas fechas autoimpuestas de entrega de valor. Cada vez que las retrasamos, perdemos la capacidad de aprender durante esos días. Dado que pedir cumplir los plazos con alcances fijos no parece razonable, tenemos que ser flexibles y adaptarnos a las circunstancias. Lo importante es validar nuestras hipótesis y aprender de nuestros usuarios, no entregar una funcionalidad perfecta que quizás nadie use.
Espero que el mensaje de esta semana haya podido llegar bien a su destino, aunque con menos palabras de lo normal.
¡Os dejo no vaya a perder el otro tren!
Próximo invitado de Tenemos que hablar de producto
Nuestro próximo invitado es Cristian, PM en Nova Talent.
¡Déjame un comentario con preguntas para Cristian!
¡Ya tenemos confirmados los 3 próximos invitados para el podcast de este año! Si quieres venir a hablar, rellena el formulario.
Puedes escuchar la entrevista a Alex en Spotify, Apple Podcasts, iVoox o en Amazon Music.
Faltaría definir "entregar la funcionalidad a medias". Es algo que puede ser crucial para que un usuario puedo encontrarlo valioso. Puede darte un falso aprendizaje ya que no estás mostrando esa funcionalidad acorde a la hipótesis inicial y terminar desechándola ¿No os parece?
🔝