Roadmap público con votación: cómo armarlo para tu SaaS sin prometer fechas

Un roadmap público con votación es una página donde tus usuarios ven qué está planificado, qué está en curso y qué ya salió, votan lo que les importa y se enteran cuando algo cambia. Funciona con pocas reglas claras; sin ellas, termina convertido en un muro de promesas viejas.

Lo que viene a reemplazar es una hoja de cálculo que solo abre el fundador. Un cliente pregunta por tercera vez si van a sumar la integración con Google Calendar, recibe un “está en la lista” y se queda sin saber si su pedido cuenta, si alguien más lo pidió o si va a llegar este año.

Qué es un roadmap público

Un roadmap público es la parte visible del plan de producto: los pedidos y mejoras ordenados por estado, abiertos a que cualquier usuario los lea. Con votación, cada persona suma su voto a un pedido que ya existe en vez de escribir uno nuevo, y el equipo ve cuánta gente quiere cada cosa.

El roadmap interno sigue existiendo. Ahí viven las fechas de entrega, las dependencias, las estimaciones y las apuestas que todavía no se anuncian. Al público llegan los problemas de tus usuarios y el punto en que está cada uno.

Qué publicar y qué dejar afuera

Publica pedidos, no proyectos. Un pedido está escrito desde el lado del usuario (“poder exportar los reportes a Excel”); un proyecto, desde el tuyo (“migrar el motor de reportes”). El usuario vota lo primero y no entiende lo segundo.

Va al roadmap público

• Funciones nuevas que pidieron tus usuarios, con el título en sus palabras.
• Mejoras a lo que ya existe, cuando cambian algo que el usuario nota.
• Errores conocidos que afectan a varios usuarios, en un tablero aparte.

Queda en el roadmap interno

• Deuda técnica, migraciones y cambios de arquitectura.
• Trabajo comprometido con un cliente puntual, y cualquier cosa con su nombre.
• Precios, planes y apuestas que todavía no quieres mostrarle a la competencia.
• Ideas del equipo que nadie pidió. Si crees en una, publícala como pedido y mira si junta votos.

Separa ideas y errores en tableros distintos desde el primer día. Un error con veinte votos y una idea con veinte votos piden respuestas diferentes, y en la misma lista compiten mal.

Los estados: pocos y con un significado cada uno

Cada estado es una promesa chica. Con ocho, nadie recuerda la diferencia entre “En revisión” y “En evaluación”, ni siquiera tu equipo. Cinco alcanzan:

El estado que más se gasta mal es Planificado. Úsalo cuando la decisión está tomada. Si todavía lo estás pensando, déjalo en Abierto: un pedido que pasa de Planificado a Cerrado le duele más al usuario que uno que nunca salió de Abierto.

Abierto y Cerrado quedan fuera del tablero del roadmap. Ahí va solo lo comprometido; la lista completa de pedidos vive en el portal, que es donde se vota.

Cómo manejar los votos sin prometer fechas

Los votos son una señal, y el portal tiene que decirlo con todas las letras: “los votos nos ayudan a priorizar, no deciden solos”. Un pedido con muchos votos puede chocar con la dirección del producto o costar tres meses de trabajo. Uno con pocos puede venir de los clientes que más pagan.

Antes de mover algo a Planificado, tres preguntas:

• ¿Cuántas personas lo piden, sumando los votos y los pedidos duplicados que fusionaste?
• ¿Quiénes son? Diez votos de clientes que pagan no pesan lo mismo que diez de cuentas de prueba.
• ¿Cuánto cuesta, y encaja con lo que ya decidiste construir este trimestre?

La lógica de impacto y urgencia que sirve para ordenar la cola de soporte también sirve acá; está explicada en cómo priorizar tickets de soporte.

Con las fechas, la regla es corta: lo planificado no lleva fecha. En un roadmap público, una fecha se lee como compromiso, y cuando se corre, el pedido pasa de buena noticia a reclamo. Si quieres dar una referencia, ponla solo en lo que ya está en curso y en una unidad gruesa (“este mes”, “antes de fin de año”). El usuario espera el cambio de estado, y se entera solo si quienes votaron reciben un aviso cuando pasa.

Cómo fusionar duplicados sin perder votos

“Exportar a Excel”, “descargar en CSV” y “bajar los datos de un reporte” son el mismo pedido escrito por tres personas. Si quedan separados, los votos se reparten y la demanda real se esconde.

Antes: sugerir parecidos mientras escriben

Cuando alguien empieza a escribir un pedido, muéstrale los parecidos y ofrécele votar uno de ellos. Una parte de los duplicados no llega a existir.

Después: fusionar con cuidado

• Elige como principal el de título más claro, aunque no sea el más antiguo.
• Pasa los votos y los seguidores al principal. Quien votó los dos cuenta una sola vez.
• Deja en el fusionado un aviso que apunte al principal, para que nadie llegue por un enlace viejo a un pedido muerto.
• Si el fusionado tenía detalle útil, como un caso de uso o una captura, cópialo como comentario en el principal.

Cuándo cerrar un pedido

Un roadmap con cientos de pedidos abiertos desde hace años transmite que nadie lo lee. Cierra en estos cuatro casos:

• Lo lanzaste. Pasa a Lanzado y avisa a todos los que votaron.
• Decidiste no hacerlo. Pasa a Cerrado con el motivo escrito: no encaja con el producto, otra función ya lo cubre o cuesta más de lo que resuelve.
• Era un duplicado. Se fusiona con el principal en vez de cerrarse a secas.
• Ya no aplica. La función cambió o el problema desapareció con otra mejora.

Un “no” explicado genera menos reclamos que dos años de silencio. Una vez por trimestre, repasa los pedidos abiertos: los que no juntaron votos ni comentarios en ese tiempo son candidatos a cerrarse con una nota corta.

Cómo lo hace Melonhelp Feedback

Melonhelp Feedback trae este esquema listo para usar. Esto es lo que hace hoy:

• Un portal público con tableros (Ideas y Errores vienen creados) donde tus usuarios publican, votan y comentan. Quien publica, vota o comenta queda suscrito, y cualquier usuario puede seguir un pedido sin votarlo.
• Cinco estados de partida: Abierto, Planificado, En curso, Lanzado y Cerrado. Puedes cambiarles el nombre y el color, sumar otros y decidir cuáles se ven en el roadmap.
• Un roadmap con una columna por estado y los pedidos ordenados por votos.
• Una fecha estimada opcional por pedido. Si la dejas vacía, el roadmap no muestra ninguna.
• Pedidos parecidos mientras alguien escribe, en el portal o en el botón dentro de tu app, con el aviso “¿Es alguna de estas? Vota en vez de duplicar”.
• Fusión desde la bandeja: los votos y los seguidores pasan al principal, y el fusionado muestra un aviso con el enlace.
• Un correo a los suscriptores cuando cambias el estado, con el comentario público que quieras agregar. Si el cambio no amerita aviso, lo desactivas.
• Orden por votos, por tendencia o por el MRR de quienes votaron, si tu app envía el plan y el MRR de cada usuario al identificarlo.
• Moderación opcional: los pedidos nuevos pueden quedar pendientes hasta que los apruebes.

Si conectas tu agente de código por MCP, también puede listar los pedidos más votados y trabajar en ellos; el detalle está en la documentación del MCP. El paso siguiente, avisarle a cada persona cuando sale lo que pidió, está en changelog: qué es y cómo avisarle a quien pidió cada cambio.

Preguntas frecuentes