← Todos los artículos
Construye lo correcto
Qué hacer cuando tu roadmap y tus clientes no coinciden
Por el equipo de FabricLoop · Mayo 2026 · 4 min lectura
Todo equipo de producto recibe esa llamada. Un cliente, a menudo uno importante, quiere algo que no está en el roadmap. Lo necesita con urgencia. Puede que incluso dé a entender que su renovación depende de ello. Tu equipo de ventas te reenvía el mensaje con dos signos de exclamación. Tu roadmap, construido con cuidado a lo largo de dos ciclos de planificación, está de un lado. El cliente, del otro. ¿Qué haces?
No es un caso excepcional. Ocurre con regularidad en cualquier producto con clientes de pago, y la forma de resolverlo revela mucho sobre cómo funciona de verdad tu proceso de desarrollo de producto. El objetivo no es decir siempre que sí ni decir siempre que no, sino contar con un método coherente para tomar la decisión.
«El peor resultado es el camino de menor resistencia: decir que sí para evitar la conversación incómoda y luego despriorizar en silencio todo lo demás para cumplir una promesa que no debiste hacer».
Un marco de decisión para los conflictos entre clientes y roadmap
Diagrama de decisión: petición del cliente frente al roadmap
¿Esta petición viene de un solo cliente o de varios?
Un solo cliente
¿Es este cliente estratégicamente importante para tu segmento objetivo?
No
Recházala con cortesía. Registra la petición. No la desarrolles.
Sí
¿Encaja con un resultado previsto en el roadmap?
Varios clientes
¿Encaja con un resultado estratégico de tu roadmap?
No
Indica una laguna en la estrategia. Coméntalo con el equipo antes de decidir.
Sí
Acelérala. Es una validación sólida: hazla avanzar.
La pregunta «¿un cliente o varios?» es el primer filtro
Si varios clientes piden lo mismo de forma independiente, es una señal que conviene tomarse en serio, sobre todo si usan un lenguaje parecido para describir el problema. Indica que la necesidad es real y generalizada, no idiosincrática.
Si es un solo cliente, el cálculo es distinto. Las necesidades de un cliente no representan a tu mercado, aunque sea tu cuenta más grande. Desarrollar funcionalidades para un único cliente es un impuesto sobre la estrategia de producto que se acumula con el tiempo: cada funcionalidad a medida añade complejidad, genera carga de mantenimiento y reduce el atractivo del producto para el mercado en general.
La trampa de los clientes enterprise
Los clientes enterprise suelen tener las peticiones más específicas y más poder de presión. Pero optimizar tu producto para el flujo de trabajo de tu mayor cuenta es la manera de acabar con un producto imposible de vender a nadie más. Trata las peticiones específicas de estos clientes como trabajo a medida, no como aportaciones al roadmap.
Cómo decir no sin dañar la relación
La clave para rechazar la petición de un cliente sin dañar la relación es reconocer el problema, no solo la petición. «No vamos a desarrollar eso» sienta mal. «Entendemos que te cuesta hacer X; así estamos pensando en ese problema y esto es lo que hay en nuestro roadmap para cubrir la misma necesidad» sienta mucho mejor.
Los clientes rara vez necesitan la funcionalidad exacta que pidieron. Necesitan que se resuelva el problema de fondo. Si puedes mostrarles un camino hacia eso, aunque no sea la funcionalidad que propusieron, la mayoría lo aceptará. Si no aceptan ningún camino que no sea su especificación exacta, eso te dice algo importante sobre si este cliente encaja con tu producto.
La fórmula de respuesta
Reconoce el problema → explica por qué no lo vas a desarrollar ahora → muestra lo que sí estás desarrollando para cubrir la misma necesidad → invítale a seguir en la conversación mientras lo desarrollas. Te llevará cinco minutos más que un «no» y conservarás mucha más buena voluntad.
Cuando el cliente tiene razón y hay que actualizar el roadmap
A veces el conflicto con un cliente revela una laguna real en tu forma de pensar. Que varios clientes pidan algo que no habías planificado indica que tu roadmap ha pasado algo por alto. La respuesta correcta no es desarrollar de inmediato lo que piden, sino investigar si el problema de fondo debe estar en el roadmap y, si es así, en qué punto.
Esta distinción importa. El cliente suele tener razón sobre el problema; rara vez la tiene sobre la solución. Usa su feedback para afinar tu comprensión del problema, no para copiar y pegar su petición de funcionalidad en el backlog.
Cómo ayuda FabricLoop a seguir las señales de los clientes
Cuando la misma petición llega de varios clientes a lo largo de varios meses, es fácil no ver el patrón si el feedback está repartido entre hilos de correo y notas del CRM. FabricLoop saca a la luz los temas recurrentes en un único lugar, para que puedas comprobar si la «petición de un cliente» es en realidad una tendencia antes de haber dicho que no cinco veces.
10 ideas para llevarte de este artículo
- Los conflictos entre clientes y roadmap son rutinarios, no excepcionales. Tener un método coherente para gestionarlos es más importante que cualquier decisión concreta.
- La peor respuesta es decir que sí para evitar la conversación y luego despriorizar en silencio todo lo demás para compensarlo.
- El primer filtro: ¿es un solo cliente o son varios? Varias peticiones independientes con un lenguaje parecido son una señal que merece investigarse.
- Desarrollar funcionalidades para un único cliente, aunque sea grande, es un impuesto sobre la estrategia de producto que se acumula con el tiempo.
- Los clientes enterprise con peticiones específicas deben tratarse como trabajo a medida, no como aportaciones al roadmap.
- Rechazar una petición sienta mejor cuando reconoces el problema de fondo y no solo la funcionalidad.
- La mayoría de los clientes necesitan que se resuelva su problema, no que se desarrolle su especificación exacta. Muéstrales el camino, no solo el «no».
- Si un cliente solo acepta su especificación exacta, eso te dice algo importante sobre el encaje entre él y tu producto.
- Cuando varios clientes revelan una laguna real, investiga el problema de fondo; no copies sin más la petición de funcionalidad en el backlog.
- Los clientes suelen tener razón sobre el problema. Rara vez la tienen sobre la solución.
