El 90% de los SaaS Construye Features Porque un Cliente lo Pidió — No Porque un Usuario las Use. Tu Roadmap es un Cementerio.

Crees que tu problema es que no sabes qué construir a continuación. Que si tuvieras más feedback, más llamadas con clientes, más votos en el backlog, tendrías claridad.

Te has equivocado de diagnóstico.

El 90% de los SaaS construye features porque un cliente lo pidió — no porque los usuarios las usen. Y ese es exactamente el motivo por el que tu roadmap es un cementerio de funciones que nadie abre.

Construyes porque alguien gritó. No porque la telemetría lo confirme.

La sabiduría convencional dice "escucha a tus clientes" y "construye lo que piden". El mercado asume que el volumen de peticiones es una señal de demanda.

Es falso. Y es caro.

Vamos a desmontarlo, vamos a darte el framework, y vas a dejar de construir funciones fantasma.

---

El Sesgo de la Minoría Ruidosa: Tu "Roadmap Democrático" es una Dictadura de los que Más Gritan

Mira tu inbox. Los clientes que te escriben emails, abren tickets y exigen features no son una muestra representativa.

Son los más vocalizados. Los más grandes. Los más frustrados.

Los que se dan de baja en silencio jamás votan en tu backlog. Simplemente se van. Así que tu feedback es una muestra sesgada por diseño: solo escuchas a los que aún están enfadados contigo, no a los que ya se fueron sin decir nada.

El "roadmap democrático" que venden los frameworks de community voting no es democracia. Es captura por parte de los que más gritan.

Y hay una conexión directa con el eje de retención: la petición ruidosa casi nunca viene de la cohorte que está en riesgo de churn. Viene de la cohorte que ya está comprometida. Construyes para contentar a los que se quedan, mientras los que están a punto de irse no te dicen ni una palabra.

Piénsalo desde la mecánica del incentivo. Un cliente que lleva dos años contigo, que ya ha invertido tiempo en configurar el producto y que forma parte de tu plan enterprise, tiene todo el motivo del mundo para escribirte cuando algo le falta. Está comprometido, quiere que el producto mejore porque su éxito depende del tuyo. Pero el usuario que probó tu producto la semana pasada, tropezó con la misma carencia y simplemente cerró la pestaña… ese no te escribe jamás. Ni te envía un ticket de soporte. Ni te da un voto en tu portal de feedback. Solo desaparece.

El resultado es un bucle de retroalimentación corrompido. Cada feature que construyes para el cliente vocalizado no solo te cuesta tiempo y recursos: te aleja aún más de los usuarios que no hablan. Y mientras más te alejas, más dependes de las mismas voces ruidosas para saber qué construir. El problema se retroalimenta.

❌ El enfoque débil: "Este cliente grande pide export a CSV. Lo ponemos en el roadmap."

✅ El enfoque fuerte: "¿Qué cohorte está abandonando en silencio? ¿Qué contratan y no usan? Respondamos eso antes de tocar el backlog."

La diferencia entre ambos enfoques no es sutil. Es la diferencia entre un equipo de producto que reacciona y uno que dirige. El primero acumula deuda para la mayoría silenciosa a cambio de contentar al 5% que grita. El segundo invierte esa ecuación: la señal de retención — qué cohortes se quedan, qué cohortes se van, qué patrón de uso precede a la baja — es la brújula que guía el roadmap. Y esa señal no llega por email. Llega por telemetría.

---

Síntomas vs. Soluciones: El Cliente no Pide el Botón. Pide el Resultado.

Un cliente que pide "exportar a CSV" no quiere un botón.

Quiere resolver un problema de reporting que probablemente ya intenta resolver con copiar-pegar, con una herramienta externa o con una hoja de cálculo manual.

Si construyes el botón literal, resuelves el síntoma. Listo, una feature más que nadie usará como esperabas.

Si investigas el job-to-be-done —"¿qué resultado intentas conseguir?"— descubres que la solución real puede ser un dashboard mejor, una integración con su herramienta favorita, o un reporte programado con más impacto y menos coste de mantenimiento que el botón literal.

Cada petición es un síntoma de un problema más profundo. Rastrearlo antes de aceptarla como orden de trabajo separa a los equipos que construyen producto de los que construyen botones.

Existe un patrón clásico que se repite en todos los SaaS: el cliente pide la solución literal que ya se le ha ocurrido, no la solución óptima. Es humano. Es el sesgo de disponibilidad aplicado a la ingeniería de producto. Cuando alguien está harto de copiar y pegar datos de tu interfaz a una hoja de cálculo, su primera idea es "exportar a Excel". No piensa en "reporte programado" ni en "dashboard interactivo". No tiene por qué: su trabajo es gestionar sus números, no diseñar tu producto.

Tu trabajo, sin embargo, sí es entender el resultado final. Y la buena noticia es que la práctica de entrevistar el job-to-be-done tiene una técnica concreta: preguntar siempre la pregunta de rastreo. Cuando alguien te pide una feature, responde con "¿y qué estás intentando conseguir con eso exactamente?" — y cuando te responda, pregunta otra vez "¿y eso para qué?" — y así hasta llegar a la capa de resultado. Casi siempre necesitas rascar tres o cuatro capas para descubrir el problema subyacente real. La petición original, "necesito un botón de export", es lo último que deberías tomar literalmente.

Y este patrón no es un accidente aislado. Es sistémico. El 80% de los SaaS estructura sus planes de precios a ciegas, sin mirar ni un dato. El mismo síndrome de "decidir sin evidencia" que produce planes al azar produce roadmaps por petición. Son dos caras de la misma enfermedad cultural: equipos que reaccionan a voces en lugar de leer telemetría.

---

El Coste Oculto de las Features Fantasma

Cada feature construida para un solo cliente ruidoso tiene un coste que casi nadie calcula.

No es el sprint. Es el legado.

Una feature que nadie usa añade deuda permanente de mantenimiento. Superficie de bugs. Complejidad de onboarding. Cada botón nuevo que no aporta valor confunde al usuario que llega por primera vez. La feature fantasma es un impuesto que todos los usuarios futuros pagan en forma de producto más confuso.

El coste real no es el tiempo de desarrollo. Es el producto que pudo haber sido.

Cada feature construida para complacer a una voz es una feature que NO se construye para la mayoría silenciosa que ya usa el producto. El coste de oportunidad de decir "sí" a un grito es decir "no" a cientos de usuarios que simplemente no te escribieron.

Vamos a ponerle números concretos a esa deuda, porque el coste se siente abstracto hasta que lo descompones. Cada feature de baja adopción implica:

Mantenimiento perpetuo: Bugs que se descubren y se arreglan aunque nadie use la feature. Cada release que toca código colindante riesgo de romperla.
Tests y suites: Cada feature nueva necesita su cobertura de tests. Tests que ejecutan CI que debería ejecutar features que el usuario usa.
Densidad cognitiva: Cada opción visible en la interfaz compite por la atención del usuario. Un cliente nuevo que ve siete botones que no entiende abandona el onboarding más rápido que uno que ve tres botones claros.
Documentación y soporte: Artículos de ayuda, preguntas de Soporte sobre "¿cómo funciona esto?" de features que nadie usa. Recursos que se destinan a explicar algo que debería haber sido un dashboard interno.
Coste de reversión: Cuando finalmente reconoces que la feature es un lastre y decides retirarla, tienes que gestionar la migración, el versionado, y la queja inevitable del cliente que la pidió (y que quizá tampoco la usaba, pero se siente propietario).

Todo eso es un impuesto silencioso que pagas todos los días. Y el problema es que se acumula con el tiempo: diez features fantasma construidas en dos años pueden añadir más deuda de mantenimiento que todas las features reales juntas.

---

El Marco de los Tres Ejes: Impacto × Retención × Valor Estratégico

Este es el framework que uso para decidir qué construir en mis propios productos. Lo llamo El Marco de los Tres Ejes. Y la primera regla es no negociable.

Regla 1: Instrumenta antes de pedir.

Mide uso por feature y por segmento antes de aceptar cualquier petición como hecho. Frecuencia de uso, adopción, activación, abandono. Necesitas saber qué se usa, qué se ignora y qué se abandona antes de que alguien te pida nada.

Cada request se registra como una hipótesis contrastable contra la telemetría existente. No como una orden de trabajo.

La instrumentación no tiene que ser exhaustiva. Empieza por lo mínimo: ¿qué features están activas en la sesión típica de cada segmento? ¿Cuál es el rate de activación del onboarding? ¿Qué flujos terminan en abandono? Con esas tres métricas cubiertas, ya tienes suficiente señal para contrastar la mayoría de peticiones. El 80% de las peticiones de features nuevas se pueden evaluar contra "¿hay evidencia en la telemetría de que una carencia en este flujo está provocando abandono?"

Regla 2: Clasifica cada petición por su job-to-be-done.

No preguntes "¿qué botón quieres?". Pregunta "¿qué resultado intentas conseguir?". Documenta el problema subyacente y agrupa peticiones distintas que comparten el mismo síntoma raíz.

Este registro cumple una función importante que la mayoría de backlogs no tienen: agrupar. Ocho peticiones distintas — "export a Excel", "necesito filtros avanzados", "quiero programar envios", "me gustaría un calendario de reportes" — pueden compartir el mismo síntoma raíz de "reporting nativo pobre". Si las tratas como ocho features separadas, construyes ocho soluciones parciales. Si las agrupas por síntoma raíz, construyes una solución que las resuelve todas a la vez. El registro de peticiones es la herramienta que permite esa agrupación.

Regla 3: Puntúa cada feature en tres ejes, escala 1-5.

Impacto en cliente: ¿A cuántos usuarios o segmentos beneficia? No "¿quién lo pidió?", sino "¿quiénes lo usarían?"
Riesgo de retención: ¿Qué cohorte está en riesgo si NO lo construimos? Este eje prioriza a los que se van en silencio, no a los que gritan.
Valor estratégico: ¿Nos acerca a la visión de producto o nos desvía?

Suma las tres puntuaciones. Ordena el backlog. Borra del liderazgo cualquier feature que la telemetría no respalde.

Regla 4: Umbral de corte y re-priorización trimestral.

Las peticiones antiguas no ganan prioridad por antigüedad. Ganan por su puntuación actualizada con datos frescos de uso. Re-evalúa el backlog entero cada trimestre y descarta lo que ya no pasa el umbral.

Este es el punto más difícil de interiorizar culturalmente, porque choca con la intuición de "si llevan pidiéndolo dos años, será importante". La antigüedad no es una señal de demanda. Es una señal de ruido persistente. Una petición que lleva dos años en el backlog sin que nadie la recuerde suele ser una petición que nadie necesita de verdad — o la necesita muy poca gente, y muy ruidosa. Si fuera realmente crítica, la telemetría lo demostraría en forma de abandono creciente. Si no lo demuestra, lo único que la mantiene viva es la inercia. El trimestre es tu ciclo natural de recolección de datos: con tres meses de telemetría fresca puedes comparar cómo han evolucionado los patrones de uso antes de commitear recursos.

Regla 5: Valida con el slice más pequeño.

Lanza la feature en versión mínima a un segmento. Define de antemano la métrica objetivo — retención o activación. Mide el cambio real antes de comprometer recursos completos.

El patrón de feature gating que ves en el código es exactamente lo que separa a los equipos que aprenden de los que suponen. El slice más pequeño no es un atajo cutre: es la unidad de aprendizaje más eficiente que existe en producto. Si la feature tiene el impacto esperado en el 5% de la cohorte, tienes evidencia para escalar. Si no lo tiene, has invertido el 5% del coste que habría supuesto construirla entera para descubrir que nadie la usa. El fracaso barato es una herramienta de producto tan valiosa como el éxito.

Y aquí la analogía con la ingeniería de software a gran escala es esclarecedora. Cuando un proyecto enorme se atasca, no suele ser porque alguien no sepa escribir código. Se atasca en la planificación, el diseño y la coordinación que rodean al código: entender el sistema existente, decidir qué construir y en qué orden, mantener la alineación con el objetivo original. El mismo principio aplica a tu roadmap de features: el problema rara vez es "no sabemos qué construir". El problema es que el proceso de decidir está capturado por voces ruidosas en lugar de evidencia de uso.

---

Respondiendo a Tus Objeciones

"Los clientes enterprise exigen features concretas para cerrar el deal."

Distingue entre compromisos contractuales y roadmap discrecional. Lo primero se negocia y se instrumenta igualmente. Lo segundo pasa por el mismo filtro de los tres ejes. Un deal que depende de una feature unica de un solo cliente es un deal que probablemente se cae igualmente en el primer renew.

Esta objeción es la más común y la más legítima. Nadie dice que ignores a los enterprise. Lo que dice el framework es que distingas entre lo que se negocia en el contrato y lo que entra en el roadmap. Si un cliente enterprise quiere una integración con su ERP, eso se negocia, se presupuesta, se instrumenta — y se entrega con métricas de adopción definidas. Eso es un proyecto. Pero cuando el mismo cliente enterprise te pide, fuera de contrato, una feature "que su equipo lleva pidiendo meses", esa petición entra en el mismo embudo de los tres ejes que cualquier otra. El tamaño del cliente infla el volumen de la voz, pero no la evidencia de uso. Y cuidado con el patrón perverso: el cliente que te chantajea con el renewal para conseguir features suele ser el mismo que se da de baja igualmente porque su problema real era otro. Construyes el plugin de SAP que pidió, no lo usa nadie de su equipo, y el renewal se cae igualmente porque el problema era la falta de soporte, no la falta del plugin.

"Los datos de uso solo te dicen lo que existe, no lo que falta."

Existen señales proxy medibles. Workarounds detectados en sesiones. Tickets de soporte recurrentes. Búsquedas fallidas. Rate de abandono en flujos clave. Y los experimentos de feature gating miden demanda real con audiencia pequeña antes de comprometer el roadmap.

Los datos de uso no te dicen directamente qué falta, es cierto. Pero te dicen dónde buscar. Un usuario que copia manualmente datos de tu interfaz para pegarlos en otra herramienta es una señal proxy. Un usuario que escribe "export" en la búsqueda de tu documentación y no encuentra nada es una señal proxy. Un flujo de onboarding con un 70% de abandono en el tercer paso es una señal proxy. Todas son medibles con las herramientas que ya tienes. El problema no es que los datos no digan qué falta — es que los equipos no los leen con la intención de averiguarlo. La telemetría convierte la "falta" en una hipótesis contrastable, y eso es una ventaja enorme sobre la petición literal.

"No tengo data team ni infraestructura de analytics."

El framework no exige un data warehouse sofisticado. Evidencia cualitativa estructurada a escala — clasificar tickets, entrevistas de job-to-be-done, sesiones grabadas — supera a una sola voz ruidosa. Y la instrumentación mínima se hace con herramientas de producto estándar.

Este es el mito más extendido y el más fácil de desmontar. No necesitas un equipo de data engineering para aplicar el Marco de los Tres Ejes. Necesitas:

Una hoja de cálculo donde clasifiques tickets por síntoma raíz — puedes hacerlo en una tarde y ya tendrás más señal que la mayoría de los SaaS.
Tres preguntas estructuradas en tus entrevistas de cliente: "¿qué intentabas conseguir?", "¿cómo lo resuelves hoy?", "¿qué te ha frenado?". Con esas tres preguntas en veinte entrevistas has matado la ambigüedad de mil peticiones.
Herramientas de producto estándar para el gating: la mayoría de plataformas de analytics de producto — PostHog, Amplitude, Mixpanel — incluyen feature flags y tracking de eventos con una configuración mínima. La instrumentación mínima no es un proyecto: es una tarde de trabajo.

El verdadero coste no es la infraestructura. Es la disciplina de preguntarse "¿qué evidencia tengo?" antes de preguntarse "¿qué me han pedido?".

---

Del Backlog Congelado al Bucle de Aprendizaje

Priorizar bien no termina en la decisión. Termina en la validación.

La disciplina de lanzar el slice más pequeño con una métrica objetivo definida convierte la priorización en un bucle: cada feature lanzada y medida actualiza el score de las siguientes. El backlog mejora con cada iteración en lugar de congelarse en la opinión del día uno.

Fíjate en cómo funciona el bucle. Lanzas el slice pequeño de la feature A. Mides retención. Los datos dicen que la adopción es baja pero la activación sube en el segmento de prueba. Ese resultado actualiza el score de la feature B (que compartía síntoma raíz con A) y te dice si vale la pena mejorarla. Mientras tanto, la petición del cliente C que llegó la semana pasada se evalúa contra la telemetría recién generada — y quizá se agrupa con A y B en lugar de abrir un frente nuevo. El backlog deja de ser una lista estática de deseos y se convierte en un conjunto de hipótesis vivas que evolucionan con cada dato nuevo.

Los equipos que sobreviven en SaaS no son los que escuchan mejor. Son los que miden primero y preguntan después. La próxima vez que un cliente grite una feature, no abras el código.

Abre la telemetría.

El 90% de los SaaS Construye Features Porque un Cliente lo Pidió — No Porque un Usuario las Use. Tu Roadmap es un Cementerio.