Ciclo de desarrollo de producto

Hay veces que repasar lo básico te hace avanzar como un PRO

La semana pasada comencé a dar clase de gestión de producto a alumnos de segundo de máster en la universidad. Es una asignatura en la que desarrollarán un producto a través de un caso práctico partiendo de la identificación del problema y hasta el lanzamiento al mercado.

Fue la típica primera clase de producto digital: ¿Qué es product management? ¿Cuál es la diferencia entre gestión de producto y gestión de proyectos? ¿Qué hace un product manager en su día a día? …

Los conceptos básicos para que puedan situar todo lo que cubriremos durante el resto del curso. De todos estos temas, no podía faltar el ciclo de vida de desarrollo de producto. Entiendo que es algo que todos conocemos y trabajamos en el día a día sobre él. Al haber tenido que explicar esta herramienta desde cero, me ha permitido encontrar matices que son fáciles de olvidar en el día a día que me gustaría compartir con vosotros. Empecemos por el principio.

¿Qué es el ciclo de desarrollo de producto?

El ciclo de desarrollo del producto son las distintas fases por las que pasa un producto o funcionalidad desde que se identifica la necesidad, hasta que está en manos del usuario. El ciclo de desarrollo de producto se puede simplificar en tres fases:

Conceptualización e ideación

En esta fase el objetivo es identificar posibles soluciones a un problema identificado. La definición de estas soluciones irá madurando conforme se vayan validando distintas hipótesis con usuarios. Al finalizar esta fase, deberíamos contar con una especificación clara de qué desarrollos se tendrán que acometer para resolver el problema, así como las métricas clave que se monitorizarán para validar que el problema se ha solucionado o ha mejorado.

Desarrollo y validación

Durante la fase de desarrollo y validación el objetivo es implementar una solución técnica acorde a la necesidad de ese momento. Eso quiere decir que en función de la certidumbre que se tenga sobre el éxito de la solución, el nivel de complejidad técnica podrá evolucionar de una versión sencilla y no escalable de la solución haciendo uso de herramientas no-code o incluso cubriendo parte de la funcionalidad por tareas manuales hasta una solución técnicamente compleja que pueda escalar y servir a millones de usuarios. Cómo parte de esta fase es vital que el equipo verifique que la funcionalidad opera como es esperado con el nivel de calidad definido. Por último, esta funcionalidad tiene que ser instrumentada para que se pueda comprobar que los cambios de comportamiento del usuario son los esperados.

Lanzamiento, monitorización y evaluación

Una vez la funcionalidad está desarrollada y puesta en las manos de los usuarios, es necesario comunicarla para que sea conocida y utilizada. Durante esta fase, además de las labores de comunicación, es necesario medir el impacto de la solución para poder evaluar si el impacto deseado se está logrando y tomar decisiones sobre los futuros desarrollos que se llevarán a cabo. Para cerrar el ciclo es necesario evaluar el impacto de la solución y repetir el ciclo entero en caso de que no se haya logrado el resultado esperado.

---

De la teoría a la práctica

Manu es un PM en Playtomic en el producto de gestión de clubes. Su equipo es responsable de la métrica porcentaje de ocupación de las pistas. El equipo de Manu lleva durante varios años intentando subir esta métrica sin éxito. Algunos de las barreras más fuertes que han encontrado han sido:

• Problemas climáticos: cuando llueve, éste % baja.

• El usuario target es trabajador entre 25 y 35 años. Le gusta jugar al salir del trabajo.

• Clases del club: las clases están programadas en la franja de 17:00 a 21:00 habiendo un conflicto muy fuerte con el horario favorito de los jugadores.

Manu sabe que el factor climático no depende de Playtomic. Además, llevan varios meses intentando convencer a los clubes, de que cambien sus clases por las clases de Playtomic, para conseguir subir ese número. Los clubes, ganan más dinero por sus clases privadas, por lo que esta iniciativa está teniendo poco éxito.

Un día llegando a la oficina, a Manu se le ocurre que a las 7 de la mañana, podría jugar un partido de pádel en vez de ir al gimnasio. Si consiguiese convencer a los clubes de abrir antes, podría aumentar el número de partidos que se juegan durante la semana.

Al llegar a la oficina se lo comentó al equipo:

— Tenemos que crear un módulo de reservas por la mañana. Se lo ofreceremos a los usuarios para que puedan jugar antes de ir al trabajo. Los clubes ahora mismo no cobran por estas horas, por lo que tendrían un nuevo ingreso.

El equipo vio el potencial y se puso manos a la obra:

• Hablaron con 50 clubes en Madrid para que abriesen a las 7 de la mañana.

• Diseñaron nuevas pantallas con un flujo de reserva especial para jugar antes de ir a la oficina.

• Crearon una campaña de marketing “Pádel mañanero” para comunicar la nueva funcionalidad y validar el interés por el nuevo horario.

• Una vez vieron que había suficientes pre-reservas, desarrollaron los flujos en la aplicación para que todo estuviera operativo

• Por último, lanzaron la funcionalidad a todo Playtomic

Al llegar la semana siguiente a la oficina, María, la jefa de Manu le preguntó.

— ¿Qué tal ha ido la primera semana Manu? ¿Está funcionando como esperábamos?

— ¡Está yendo genial! La semana pasada conseguimos aumentar las reservas un 15%. Todos los clubes han conseguido por lo menos 10 reservas nuevas la semana pasada y el 90% de la gente que lo ha probado ha reservado para repetir esta semana.

— Manu esos números están muy bien — dijo María con poco entusiasmo — ¿qué hay del porcentaje de ocupación del club?

Manu se quedó helado. Abrió el dashboard y se le descolgó la mandíbula.

— Ha bajado el porcentaje de ocupación un 20%. — dijo en shock — Pero ¿cómo es posible? Hemos aumentado las reservas.

— Habéis aumentado las reservas, pero también el número de horas que están los clubes abiertos — dijo María con dulzura. — Hay un motivo por el que tenemos distintos equipos velando por métricas. Estoy segura de que Javier, el PM de partidos semanales, está encantado con tu lanzamiento, pero tú estás encargado de que los clubes maximicen el uso de sus instalaciones. Tendrías que haber analizado bien cuál era el problema que querías resolver y haber estudiado las consecuencias del desarrollo.

— ¿Y ahora qué hacemos? — dijo Manu preocupado — El pádel mañanero ha sido un éxito. Si lo quitamos de la aplicación los usuarios se enfadarán con nosotros.

María sonrió y le preguntó — ¿Por qué tienen que abrir todos los clubes a las 7 si no van a tener ningún partido?

— ¡Qué buena idea! Les avisaremos el día anterior para que no abran. Voy a hablar con el equipo para desarrollar la nueva funcionalidad.

María carraspeo y le miró.

Manu avergonzado sonrió y le dijo. — Pero primero voy a describir bien que es lo que quiero conseguir y documentar el impacto que espero del desarrollo. De esa forma, cuando esta funcionalidad esté en producción podremos aprender más rápido de qué está yendo bien, y qué tenemos que mejorar.

---

Está dinámica pasa continuamente en equipos de producto. Hacemos el onboarding más largo para explicarle al usuario algunas cosas mejor y baja la conversión. Mostramos un pop-up para que contraten una suscripción más cara y el churn sube. ¿Qué hacemos al lanzar una funcionalidad? ¿Monitorizamos usuarios activos al día o mensuales? Si no lo pensamos por adelantado, es muy complicado analizar esto una vez ya se ha desarrollado la funcionalidad.

Por eso cuando estamos lanzando una nueva funcionalidad, tenemos que prestar atención a este tipo de errores, que son más comunes de lo que pensamos.

Conceptualización e ideación:

• Sustituir el problema a resolver por la nueva funcionalidad a desarrollar

• Reducir la fase de ideación a un desarrollo de mockups y requisitos

• No definir las métricas de validación para el lanzamiento

Desarrollo y validación

• Usar herramientas low code para soluciones que tienen que escalar

• Hacer un desarrollo “perfecto” para soluciones que no están validadas

• Medir la fase de desarrollo por líneas de código en local o código en cualquier entorno que no sea producción

Lanzamiento, monitorización y evaluación

• Desplegar una funcionalidad y que los usuarios no se enteren

• Pensar que métricas hay que monitorizar después del lanzamiento

• No quitar funcionalidades que no han funcionado cómo se esperaba

¡Si te ha gustado este post repasando básicos de producto házmelo saber!