¿Qué desarrollar después de lanzar tu SaaS? La respuesta no debería depender de quién haya pedido la última funcionalidad ni de qué idea parezca más interesante. Un buen product roadmap permite priorizar las mejoras que pueden mover el negocio y descartar las que solo añaden complejidad.
Antes de lanzar un producto el problema suele ser bastante claro: falta producto.
Después del lanzamiento ocurre justo lo contrario.
Empiezan a llegar ideas de clientes, peticiones del equipo comercial, bugs, mejoras internas, cosas que has visto en la competencia y funcionalidades que llevabas meses queriendo hacer.
De repente el backlog parece una lista infinita.
Y ahí empieza una de las partes más importantes de producto: decidir qué no desarrollar.
Un product roadmap no debería ser una lista de funcionalidades ordenadas por fecha.
Debería ser una explicación de qué problemas vamos a intentar resolver, por qué ahora y con qué evidencia.
En el vídeo que acompaña este artículo comparto decisiones reales de BCoach y HorasClaras: peticiones que sonaban urgentes, cambios que decidimos validar con un MVP y ocasiones en las que el análisis del uso de la aplicación fue más útil que una opinión aislada.
Qué es un product roadmap
Un product roadmap es una herramienta para ordenar prioridades de producto a medio plazo.
No es un contrato.
Tampoco debería ser una lista cerrada de entregas para los próximos doce meses.
Para mí sirve para responder cuatro preguntas:
- ¿Qué queremos mejorar?
- ¿Por qué creemos que merece la pena?
- ¿Qué evidencia tenemos?
- ¿Qué dejamos fuera para poder hacerlo?
Si el roadmap no ayuda a tomar decisiones, termina siendo simplemente un calendario bonito.
El error de convertir todo el feedback en tareas
Cuando un usuario pide algo, la tentación es añadirlo directamente al backlog.
Parece lógico: el cliente ha hablado.
Pero el feedback no es una especificación.
Un usuario puede pedir una solución concreta porque es la única que conoce.
Tu trabajo es entender el problema que hay detrás.
Si diez usuarios piden "exportar a Excel", quizá el problema real no sea que quieran Excel.
Quizá necesitan compartir información con alguien que no utiliza tu producto.
O hacer cálculos que tu aplicación todavía no permite.
O entregar un informe a un cliente.
La diferencia es importante porque cada problema puede tener soluciones completamente distintas.
Guarda el problema antes que la funcionalidad solicitada.
No todo el feedback pesa lo mismo
Yo no trataría igual una petición que aparece una vez que otra que aparece todas las semanas.
Tampoco pesa igual algo que molesta que algo que impide utilizar el producto.
Cuando reviso feedback intento separar al menos estas señales:
- frecuencia: cuántas veces aparece;
- gravedad: cuánto bloquea al usuario;
- perfil: qué tipo de usuario lo pide;
- impacto: qué métrica podría mover;
- evidencia: si tenemos datos además de opiniones;
- coste: cuánto esfuerzo requiere resolverlo.
Esto evita que gane siempre la persona que habla más alto.
También evita construir para un cliente concreto algo que complica el producto para todos los demás.
Caso real: la funcionalidad de BCoach que parecía imprescindible
Cuando estábamos construyendo BCoach, un usuario insistió en que los jugadores de la pizarra tenían que tener orientación: no bastaba con señalar hacia dónde se movían, también quería representar hacia dónde miraban.
Era una necesidad concreta, pero implementarla de forma completa suponía guardar ángulos de orientación, crear controles de edición y dedicar tiempo de diseño y desarrollo. Antes de asumir ese coste, decidimos lanzar una versión pequeña: una indicación visual con ocho orientaciones posibles, no una herramienta de 360 grados.
Instrumentamos el uso para comprobar si realmente resolvía una necesidad. Según lo que observamos entonces, nadie utilizó aquella mejora y nadie volvió a pedirla.
La enseñanza no es que debamos ignorar a quien nos escribe. Es que la intensidad de una petición no demuestra su prioridad. En ese momento era más importante entender por qué algunos usuarios probaban BCoach y luego dejaban de utilizarla.
Empieza por el objetivo, no por las funcionalidades
Antes de ordenar tareas decidiría qué queremos mejorar durante las próximas semanas.
Por ejemplo:
- aumentar activación;
- reducir abandono durante el onboarding;
- aumentar conversión a pago;
- mejorar retención;
- reducir soporte;
- conseguir que una funcionalidad clave se utilice más;
- desbloquear un segmento de clientes.
Esto cambia completamente la conversación.
Si el objetivo es mejorar activación, no estás comparando dos funcionalidades por lo interesantes que parecen.
Estás preguntando cuál tiene más probabilidades de hacer que un usuario llegue antes al valor.
Si todavía no tienes claro cuál es ese momento de valor, empezaría por definir la activación del SaaS.
Primero identifica el cuello de botella del SaaS
No todas las aplicaciones necesitan lo mismo después del lanzamiento:
- Si todavía no consigues usuarios, enfócate en adquisición y distribución. Otra funcionalidad puede no resolver ese problema.
- Si llegan usuarios pero abandonan, investiga activación, fricciones y retención antes de ampliar el producto.
- Si se utiliza pero no convierte a pago, estudia qué acciones preceden a las suscripciones y cómo presentar el valor.
En BCoach, por ejemplo, vimos que quienes llegaban a generar una hoja de sesión de entrenamiento tenían una mayor conversión a pago. Eso nos llevó a trabajar el onboarding para acercar a más usuarios a ese momento de valor. La decisión no nació de añadir una nueva función, sino de mejorar el recorrido hasta una que ya existía.
Un sistema sencillo para priorizar
No hace falta montar una fórmula sofisticada.
Puedes utilizar cuatro variables:
Impacto. ¿Cuánto puede mover el objetivo que hemos elegido?
Evidencia. ¿Qué nos hace pensar que el problema existe de verdad?
Alcance. ¿A cuántos usuarios afecta?
Coste. ¿Cuánto tiempo y complejidad añade?
Una forma sencilla de pensarlo es:
prioridad = impacto × evidencia × alcance / coste
No me obsesionaría con que el número sea matemáticamente perfecto.
La utilidad está en obligarte a justificar cada elemento con los mismos criterios.
Si una idea parece fantástica pero la evidencia es casi cero, eso debe verse.
Separa problemas de soluciones
En el roadmap intentaría escribir:
"Reducir el abandono antes de crear el primer proyecto."
Y no:
"Añadir un tutorial de cinco pasos."
La primera formulación deja espacio para descubrir la mejor solución.
La segunda ya ha decidido qué construir antes de investigar.
Quizá el tutorial sea correcto.
O quizá el problema desaparezca eliminando dos campos del formulario.
O precargando un ejemplo.
O cambiando una pantalla.
En cómo analizar un onboarding SaaS explico precisamente cómo encontrar esos puntos de fuga.
Caso real: una petición que se salía del alcance de HorasClaras
En HorasClaras, nuestro software de control horario y recursos humanos, una persona pidió utilizar la sección de eventos para adjuntar partes de trabajo e indicar qué debía hacer cada empleado ese día.
La petición tenía sentido para su empresa, pero nos acercaba a funciones propias de un ERP y se alejaba del objetivo de HorasClaras. Antes de desarrollarla, preguntamos qué intentaba resolver y cómo trabajaban en realidad.
Un usuario de tu producto puede tener muchas necesidades legítimas que tu producto no tiene por qué cubrir. Entender la diferencia evita transformar una aplicación enfocada en una herramienta que intenta hacerlo todo.
Si encuentras el mismo problema de forma recurrente en un grupo de clientes con necesidades distintas, eso puede justificar estudiar una nueva línea de producto. Pero no deberías cambiar el roadmap por una sola petición.
Qué hacer con las ideas que no entran
Que una funcionalidad no entre ahora no significa que sea mala.
Puede ser buena pero prematura.
Yo mantendría tres grupos:
Ahora
Problemas directamente relacionados con el objetivo actual y con evidencia suficiente.
Después
Oportunidades interesantes que necesitan más datos o que no son prioritarias todavía.
Archivo
Ideas que no encajan con la dirección del producto o cuya evidencia es demasiado débil.
Esto es importante porque un backlog sin limpieza se convierte en un cementerio de ideas antiguas.
Si llevas dos años sin priorizar una tarea, probablemente no necesitas seguir fingiendo que algún día la harás.
Cómo tratar una petición de un cliente importante
Aquí el sistema se complica.
Hay veces que una funcionalidad no tiene gran alcance pero sí un impacto comercial enorme.
Por ejemplo, puede desbloquear un contrato importante o evitar que se vaya un cliente clave.
Eso también es impacto.
Pero lo haría explícito.
No intentaría disfrazar una decisión comercial como si fuera una necesidad general de producto.
Puedes decidir desarrollar algo para un cliente concreto.
Lo importante es saber que estás tomando esa decisión y entender el coste que añade al producto.
El roadmap debería cambiar
Si después de hablar con usuarios o mirar datos descubres que tu hipótesis era incorrecta, cambia el roadmap.
Eso no significa que estuviera mal hecho.
Significa que has aprendido.
La alternativa es peor: seguir desarrollando algo porque estaba escrito hace tres meses.
Un roadmap útil tiene dirección estable y soluciones flexibles.
Los objetivos pueden mantenerse durante varias semanas.
Las funcionalidades concretas pueden cambiar cuando aparece nueva información.
Cuánto detalle pondría
Para las próximas semanas tendría bastante claridad.
Para dentro de tres o seis meses, bastante menos.
Cuanto más lejos está una decisión, más incertidumbre existe.
Por eso evitaría roadmaps de producto con veinte funcionalidades asignadas a fechas exactas durante todo un año.
Dan sensación de control, pero normalmente solo esconden incertidumbre.
Prefiero algo así:
Ahora: activación y onboarding.
Después: monetización y adopción.
Más adelante: expansión hacia equipos y colaboración.
Y debajo de cada bloque, problemas que queremos investigar y posibles soluciones.
Contrasta el feedback con la analítica de producto
Las entrevistas, los correos de soporte y las solicitudes de funcionalidades son útiles, pero hay que contrastarlos con el comportamiento real.
Antes de dar prioridad a una mejora, revisaría:
- Eventos de uso: cuántos usuarios alcanzan la funcionalidad y con qué frecuencia vuelven.
- Puntos de abandono: dónde se interrumpe el onboarding o un flujo clave.
- Retención y cancelaciones: qué razones dan los usuarios cuando dejan de utilizar o pagar el SaaS.
- Segmentos: si el problema afecta al público objetivo o a un grupo con necesidades muy diferentes.
- Validación cualitativa: hablar también con quienes sí están utilizando la función sin problemas.
Herramientas de analítica de producto como PostHog ayudan a estudiar eventos y recorridos, pero no necesitas instrumentarlo todo desde el primer día. Mide lo mínimo que te permita tomar la siguiente decisión.
El roadmap no sustituye a validar
Una idea puede tener una puntuación alta y seguir siendo incorrecta.
Antes de invertir semanas en algo grande, intentaría buscar una forma más barata de aprender.
Prototipo.
Entrevistas.
Landing.
Proceso manual.
Feature flag.
Una versión reducida.
En cómo validar una idea sin gastar de más explico por qué prefiero comprar evidencia antes que comprar desarrollo.
Preguntas frecuentes al priorizar funcionalidades
¿Cómo priorizar funcionalidades después de lanzar un MVP?
Empieza por identificar el problema que más frena tu objetivo: conseguir usuarios, activar a quienes llegan, retenerlos o convertirlos a pago. Ordena las posibles mejoras por impacto, evidencia, alcance y coste. Después valida la solución más pequeña antes de comprometer semanas de desarrollo.
¿En qué se diferencia un product roadmap de un backlog?
El roadmap de producto explica hacia qué resultados quieres avanzar y por qué. El backlog reúne ideas, tareas y mejoras que podrías ejecutar. No todo lo que aparece en el backlog debe entrar en el roadmap, y el roadmap puede cambiar cuando aprendes algo nuevo.
¿Debo hacer caso a todas las peticiones de mis usuarios?
No. Escucha todas las peticiones relevantes, pero investiga el problema que hay detrás, comprueba si encaja con tu público objetivo y contrasta su importancia con datos de uso. Una necesidad individual puede ser real sin ser la siguiente prioridad de tu SaaS.
La regla que usaría después de lanzar
Antes del lanzamiento preguntas:
¿qué necesitamos para que esto funcione?
Después del lanzamiento la pregunta cambia:
¿qué evidencia tenemos de que esto es lo siguiente que merece la pena construir?
Ese cambio parece pequeño.
Pero separa un producto que acumula funcionalidades de otro que aprende.
Y para mí, esa es la función real de un product roadmap.