Cómo crear una roadmap de producto con feedback de clientes

Crear una roadmap de producto se reduce a esto: reúne lo que los clientes ya han pedido, agrúpalo por el problema que hay detrás de cada solicitud, ordena los grupos con una regla que puedas explicar, decide cuán seguro estás de cada uno y publica el resultado en un formato que encaje con quien lo lee. El orden importa. Los equipos que empiezan por el diseño y lo llenan de ideas obtienen un documento que parece terminado y no lleva ninguna evidencia. Los que empiezan por las solicitudes obtienen una roadmap más corta con una razón detrás de cada fila.

¿Por dónde empiezas al crear una roadmap de producto?

Empieza por la evidencia que ya tienes, no por una página en blanco. Las solicitudes de funciones abiertas, las conversaciones de soporte etiquetadas con la misma queja, las notas de llamadas de ventas y los datos de uso de tu propio producto son todos insumos. Ponlos en una sola lista y anota de dónde salió cada elemento.

Las solicitudes casi nunca llegan en una forma utilizable. “Añadir integración con Slack” y “avisar a mi equipo cuando cambie una tarea” pueden ser la misma necesidad. Por eso el siguiente paso es agrupar, y por eso conviene un gestor que fusione duplicados; solicitudes de función duplicadas explica cómo. Ten presente que los tickets de soporte y las solicitudes de funciones aportan señales de distinto tipo, y una roadmap construida con solo una de las dos se inclinará hacia el lado equivocado.

¿Cómo conviertes las solicitudes en elementos de la roadmap de producto?

Agrupa las solicitudes por problema, nombra cada grupo como un resultado y conserva el recuento. Un grupo de catorce solicitudes que describen perder un filtro al recargar se convierte en un elemento: “Conservar el filtro que usaste la última vez”. El recuento va en la columna de origen, para que cualquiera que lea la roadmap vea el peso que hay detrás.

Escribe el resultado con las palabras del cliente. “Implementar persistencia de vistas guardadas” le dice a un ingeniero qué construir y a un cliente no le dice nada. Formularlo como resultado también obliga a hacerse una pregunta útil: si no puedes decir qué cambia para el cliente, quizá estés ante una tarea interna que va en otra lista.

¿Cómo decides qué va primero?

Elige una regla de puntuación, déjala por escrito y aplícala a cada elemento. RICE, que puntúa alcance, impacto, confianza y esfuerzo, es la más habitual; la explicación de RICE de Intercom es la fuente original. Una regla más simple funciona igual de bien si puedes explicarla: número de solicitudes, ponderado según si quien la hace es una cuenta de pago activa, dividido por un esfuerzo aproximado.

Lo importante es que la regla esté declarada, porque el primer cliente que pregunte por qué su solicitud no está en la lista querrá una respuesta. Cuando la regla y tu criterio discrepen, dilo en la fila. Priorizar solicitudes de funciones repasa los métodos de puntuación, la cuestión de ponderar por ingresos y qué dicen y qué no dicen los votos.

¿Qué tan seguro estás de cada elemento?

Marca cada elemento con su nivel de confianza antes de publicar nada. Basta una escala de tres valores: comprometido significa que al equipo le sorprendería no entregarlo en la ventana, previsión significa que es el plan salvo que algo cambie, y explorando significa que no hay ninguna promesa.

Esta única columna evita la mayor parte del daño que hacen los roadmaps. Sin ella, un cliente lee un elemento explorando como un compromiso, ventas lo cita y un trimestre después es una queja. El ensayo de Marty Cagan sobre la alternativa a los roadmaps defiende el argumento de fondo: una lista de funciones con fechas es una lista de conjeturas presentadas como planes, y la solución es ser explícito sobre lo que sabes.

¿Qué formato debe tener la roadmap?

Elige el diseño al final, según el lector. Los clientes que preguntan si los escuchaste necesitan una vista pública y corta. La dirección que pregunta por qué se hace este trabajo necesita temas o resultados. Un equipo que cambia de rumbo cada mes se las arregla bien con Ahora, Después y Más adelante, sin fechas. Ejemplos de roadmap de producto muestra seis formatos con elementos realistas y cómo falla cada uno, y la plantilla de roadmap de producto da los campos para copiar una vez que hayas elegido.

La mayoría de los equipos acaban con dos documentos: una roadmap estratégica para lectores internos y otra pública, reducida, que muestra solo aquello por lo que aceptas que te lo exijan. Si publicas uno, roadmap pública describe cómo alimentarlo con etiquetas de las incidencias que ya gestionas.

¿Cómo evitas que la roadmap se quede obsoleta?

Dale a cada fila una fecha de revisión y mantén la roadmap donde ya está el trabajo. Una roadmap que se actualiza a mano en otra herramienta se queda obsoleta porque el trabajo diario de nadie lo incluye. Si cada columna corresponde a una etiqueta de la incidencia, la roadmap cambia cuando cambia la etiqueta.

Cierra el ciclo cuando un elemento se entregue. Quienes lo pidieron deberían enterarse, y la entrada del changelog es el lugar habitual; el ciclo de feedback del cliente describe todo el camino. Si decides no construir algo, dilo también. Un no claro le sirve a quien preguntó, y rechazar una solicitud de función trata de cómo redactarlo.

FAQ

¿Cuáles son los pasos para crear una roadmap de producto? Reunir solicitudes y datos, agruparlos por el problema que hay detrás, ordenarlos con una regla escrita, marcar cada elemento según tu seguridad, elegir un formato para el lector y fijar una fecha de revisión. Partir de la evidencia mantiene la roadmap corta y defendible.

¿En qué debe basarse una roadmap de producto? En solicitudes de clientes, temas de soporte, datos de uso y tu estrategia, en ese orden según con qué frecuencia se pasan por alto. Una roadmap sin origen detrás de sus filas es una lista de deseos.

¿Qué horizonte debe cubrir una roadmap de producto? El suficiente para ser útil y el justo para ser creíble. Para muchos equipos pequeños es el trimestre actual en detalle y uno o dos más como temas. Lo que quede más lejos va bajo “más adelante” y sin fechas.

¿Quién debe participar en la creación de una roadmap de producto? El responsable de producto decide, ingeniería comprueba la viabilidad y el esfuerzo, y soporte y ventas aportan las solicitudes y los temas que escuchan. Los clientes ven el resultado en una versión pública, pero no la editan.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Ejemplos de changelog