El ciclo de vida del producto: viaje de una característica del producto

Esta es la cuarta publicación de una serie de cinco partes que estoy escribiendo con el objetivo de ayudar a un aspirante a productos a ingresar al mundo de la gestión de productos.

En mi última publicación , dividí la disciplina de Gestión de productos en cuatro partes con el objetivo de ayudar a los aspirantes a Gestión de productos a comprender su trayectoria profesional dentro de una empresa o en general. En esta publicación, hablaré sobre el recorrido de la vida de una función de producto, desde la ideación hasta el abandono, para ayudar a un aspirante a Gestión de productos a obtener una perspectiva de 360 ​​grados sobre lo que implica el rol de un Gerente de producto.

T – 30 días

Se dice que la necesidad es la madre de la invención. Ese es literalmente el caso cuando se trata del nacimiento de una característica del producto. Todo comienza con cierto nivel de incomodidad.
Algún empleado de la empresa se siente incómodo al realizar una de sus tareas diarias; tal vez la base de usuarios ha aumentado y no puede administrarla con los procesos anteriores. Un ejecutivo de la empresa mira una hoja de Excel y piensa que la empresa está perdiendo demasiado dinero debido, por ejemplo, a la gran cantidad de cancelaciones de productos. O tal vez un competidor lanzó una característica del producto que está provocando que los clientes abandonen el producto de dicha empresa. Alguien que analizó el embudo de conversión de marketing notó grandes abandonos en una determinada etapa y sintió que optimizar eso podría ayudarlo a lograr su objetivo trimestral. O podrían ser 100 razones diferentes, desde una gran cantidad de quejas de clientes por un problema común hasta una nueva función que la mayoría de los usuarios encuestados exigieron la semana anterior. El punto es que todo comienza con cierto nivel de incomodidad.

Ahora, esta incomodidad se pone en conocimiento del Product Manager; o tal vez el Product Manager es quien lo nota primero. Este es el punto que inicia una cadena de eventos que podrían conducir al nacimiento de una nueva característica.

T – 25 días

Es hora de que el Gerente de Producto reflexione sobre la declaración del problema. Él va y habla con los clientes o partes interesadas internas que reportaron la incomodidad y luego con aquellos que realmente la están experimentando; todo con un solo objetivo: asegurarse de que ha identificado el enunciado del problema 'raíz'. Si esta etapa se toma a la ligera o el Gerente de Producto no dedica suficiente tiempo a esto, entonces las características del producto nacidas son frágiles, distorsionadas y terminan con bastante rapidez.
Una vez que el Gerente de Producto ha identificado la declaración del problema central, decide si vale la pena resolverlo. ¿La incomodidad es realmente grande o es un poco exagerada o, peor aún, simplemente inventada? ¿Solucionarlo realmente agregaría un valor significativo para el cliente y/o la empresa? ¿Resolverlo no supondría una penalización importante para el cliente y/o la empresa? ¿Hay alguna manera de resolver este problema con un ajuste menor en los procesos o a través de cualquier actividad que no requiera cambios en el producto, por ejemplo, cambiar de proveedor, negociar un mejor precio de un proveedor existente, obtener un software de terceros para resolver el problema, contratar ¿un empleado adicional, cambios en el contenido, gráficos, botón de llamada a la acción, etc.?

Básicamente, si hay una forma en que podamos obtener un valor agregado similar a partir de un método que no involucre cambios en el producto, entonces optaríamos por eso en lugar de cambiar cualquier cosa en el producto, ya sea que eso signifique agregar o eliminar. Una vez que el Gerente de Producto está convencido de que resolver el enunciado del problema proporcionará un valor significativo y un cambio en el nivel del producto dará mucho más ROI (considerando tiempo, dinero y esfuerzo v/s valor) que un cambio en el nivel que no es del producto, las semillas de un nuevo característica del producto se plantan.

T – 15 días

Si el Product Manager tiene alguna experiencia previa, podría proponer una solución basada en esa experiencia. Sin embargo, esa podría no ser la mejor solución en todos los casos.
Si la declaración del problema requiere una solución altamente técnica, el Gerente de Producto discute lo mismo con los desarrolladores y gerentes de ingeniería y toma su consejo sobre la mejor manera de hacerlo. Si la solución requiere cambios en el nivel de diseño, se puede consultar al líder de UX. Podría ser que el Gerente de Producto y la persona de UX organicen un sprint de diseño y elijan la solución que sea bien recibida por los usuarios reales de esa característica. A veces, el problema está totalmente relacionado con el negocio y, por lo tanto, requiere la participación de la alta dirección.
Por lo tanto, puede haber varias formas de finalizar una solución. Pero una vez que lo es, el Product Manager es responsable de convertir esa solución teórica en una característica activa del producto.

T = 0 (también conocido como nacimiento de la característica del producto)

Cuando se identifica una solución en particular, el Product Manager, en colaboración con el equipo correspondiente, elabora un esquema básico de la solución. Puede o no incluir un prototipo de la solución. A veces es solo una hoja de Excel básica con condiciones 'si-entonces' escritas para cuándo mostrar una CTA particular a un usuario, etc.
El Gerente de Producto pone la solución en palabras en el PRD (Documento de Requisitos del Producto) correspondiente. Si la función es pequeña, podría ser solo un párrafo en un PRD existente para una función más grande. A veces, la función es tan grande que requiere un PRD completo solo para detallarla correctamente. El PRD está a cargo de los equipos relevantes y el Product Manager se asegura de que exista un amplio consenso con respecto a la función.

T + 15 días

Las características pequeñas pueden tardar menos de un día en congelarse. A veces, las características importantes tardan más de 30 días en obtener el visto bueno de todos.
Tomemos un promedio de 15 días para decir que este es el momento en que se presenta a los desarrolladores la característica recién nacida. Se lleva a cabo un diseño adecuado y una entrega de PRD en la que se informa a los desarrolladores que están trabajando en el proyecto sobre las 5 W (qué, por qué, cuándo, dónde, quién) y los casos de prueba (cómo debe comportarse o no la función una vez que se lanza) .
Junto con el gerente de ingeniería, se decide un cronograma de lanzamiento adecuado para la función con plazos para cuándo finalizará el desarrollo, cuándo comenzarán las pruebas, cuándo se corregirán los errores informados y la fecha de lanzamiento final. Luego, toda la línea de tiempo se divide en sprints medibles (generalmente 15 días de duración). Una vez que los desarrolladores están satisfechos, comienza el desarrollo.

T + 30 días

Finaliza el sprint 1. Se implementa una parte de la característica del producto. Puede que todavía no esté orientado al cliente, pero la mayoría de los equipos siguen metodologías Agile hoy en día para el desarrollo de software, lo que significa que construimos de forma incremental e iterativa. Por lo tanto, en lugar de crear una gran característica en 6 meses y lanzarla toda de una vez, la dividimos en partes independientes que pueden funcionar por sí solas (un montón de Historias de usuarios) y están listas rápidamente para ser revisadas e iteradas.
El gerente de producto se asegura de que el cronograma de lanzamiento esté en orden a través de reuniones diarias de scrum y discusiones con el gerente de ingeniería relevante que trabaja en el proyecto. En caso de que haya un retraso, los plazos se ajustan en consecuencia o se eliminan pequeñas partes de las funciones para garantizar que el lanzamiento se realice a tiempo. Después de cada sprint, el progreso realizado se presenta al Product Manager y a las partes interesadas relevantes en una reunión, y se publica después de la aprobación.
Un año del programa de gestión de productos de UpGrad

T + x días

Después de 'n' número de sprints, el desarrollo está completo y la característica completa está disponible. No es necesario que los clientes puedan usar la función solo cuando se lance por completo. Podrían estar usándolo desde el lanzamiento al final del propio sprint 1. Cada lanzamiento de ciclo de sprint posterior solo hace que la función sea más robusta y la acerca a lo que debe ser.
Lanzar una función es en sí mismo un arte e implica muchos pasos que omitiremos y simplemente asumiremos que después de muchos tambores y golpes de pecho, se declaró al mundo que se ha lanzado una función. Esto podría ser tan complejo como un comunicado de prensa en toda regla con el propio CEO hablando sobre el nuevo lanzamiento, o podría ser simplemente algo en lo que se envía un correo electrónico a un departamento en particular que va a utilizar la función y probablemente lo solicitó en El primer lugar. Entonces, ahora que la función está disponible, démosle un nombre a esta función: Mr. Feature.

T + y días

Incluso después del lanzamiento final, a veces las cosas salen mal. Mr. Feature, que una vez fue todo brillante y valioso, podría no ser el mismo ya y podría haber múltiples razones para ello. Esta fase en el ciclo de un producto se trata de apoyar el producto. Un buen día se hizo otro lanzamiento que provocó que Mr. Feature funcionara de manera no deseada (también conocido como errores) o tal vez se eliminó otra función que tenía algunas dependencias en Mr. Feature y esto provocó el comportamiento defectuoso. También podría ser que cuando se creó la función, subestimamos la cantidad de usuarios que la usarán o no planificamos todos los casos de uso y ahora la función no puede escalar a tantos usuarios o casos de uso.

Esto lo informa el equipo de prueba en su revisión periódica, o lo informa algún miembro del equipo que acaba de descubrirlo mientras usaba la función. En el caso de las funciones orientadas al cliente, estas quejas pueden provenir de los clientes reales del producto y comunicarse al gerente de producto a través del equipo de experiencia del cliente.

El gerente de producto intenta comprender la causa raíz del error y, de acuerdo con la prioridad, programa la solución para el próximo ciclo de lanzamiento; podría agregarse en el sprint actual si es de alta prioridad o incluso en sprints posteriores. Después de corregir y publicar el error, Mr. Feature vivirá para ver otro día, aunque en una forma reformada, Mr. Feature 2.0, gracias al Gerente de Producto y al equipo de ingeniería. ¡Prestigio!

T + z días

Se dice que todo lo bueno debe llegar a su fin. Lamentablemente, ese también es el caso con Mr. Feature, sin importar cuál sea su versión, ¡tal vez Mr. Feature 9.263.75! Eso significa que el Sr. Feature ha vivido una vida larga y feliz, pero ahora el final del camino está aquí.
Puede deberse a varias razones. Apareció una nueva característica que hizo que la necesidad de Mr. Feature fuera completamente redundante. También podría ser algo extremo, como que la empresa decidió que, aunque la función agregaba valor a sus usuarios, ya no tenía sentido económico para ellos.

No importa cuál sea el motivo, se le comunica al Gerente de Producto (o él es quien inicia la discusión) que los servicios de Mr. Feature ya no serán necesarios. Ahora, a pesar de lo desgarrador que es, el gerente de producto tiene el deber de dejar descansar al Sr. Feature. Aunque, antes de eso, debe asegurarse de algunas cosas, como informar a los usuarios que estaban usando Mr. Feature que no estará disponible a partir de una fecha determinada, la nueva función funciona bien antes de eliminar Mr. Feature, ninguna otra el flujo se ve afectado cuando Mr. Feature se va, y así sucesivamente.

Entonces, es hora de decir RIP a Mr. Feature. En su carrera de gestión de productos, tendrá que hacer esto varias veces. Pero recuerda, el final de una función es el comienzo de otra y el ciclo continúa. ¡Así es la vida de la gestión de productos!

Estudie cursos de gestión de productos en línea de las mejores universidades del mundo. Obtenga programas de maestría, PGP ejecutivo o certificado avanzado para acelerar su carrera.

Programa destacado para usted: Programa de certificación Design Thinking de Duke CE