El Cliente que Gritó Más Fuerte por esa Feature que Acabas de Enviar? Probablemente ya se ha Dado de Baja
Crees que priorizar features es escuchar al cliente. Que el roadmap lo dicta el que pide más alto, el que paga más, o el que llena tu tablero de Jira de tickets.
Te has equivocado de diagnóstico.
El 90% de las startups SaaS prioriza features basándose en quién las pidió, no en datos reales de uso. Y el resultado no es un mejor producto — es un producto construido para el 10% de usuarios que hablan, ignorando al 85% que vota con los pies.
El cliente que te pidió esa feature a gritos, ese que amenazó con irse si no la construías? Hay un 70% de probabilidades de que ya haya hecho churn para cuando la lanzaste.
La sabiduría convencional dice: "Escucha a tus clientes. Construye lo que piden."
La verdad incómoda es que escuchar a tus clientes es la forma más rápida de construir el producto equivocado.
No porque los clientes mientan. Sino porque lo que te piden casi nunca es lo que necesitan.
---
La Paradoja de la Feature Request: No Es una Feature, Es un Síntoma
Cuando un cliente te pide una feature, rara vez te está pidiendo lo que realmente necesita.
Te está describiendo un síntoma disfrazado de solución. Y si construyes lo que te pide, estás recetando analgésicos para un dolor que viene de un hueso roto en otra parte del producto.
❌ Lo que la mayoría hace: Escucha la petición literal. "Necesito un dashboard de reporting avanzado." → Construye el dashboard.
✅ Lo que los datos revelan: Sesiones de grabación muestran que el usuario pasa 15 minutos exportando datos a Google Sheets cada vez que entra. El problema no es la falta de dashboard — es que no encuentra lo que ya existe en tu producto.
He visto esto docenas de veces con los productos que he enviado. En Juridica Integral, una petición recurrente de "integración con herramienta X" resultó ser, tras ver las sesiones de usuarios, que no sabían que la funcionalidad equivalente ya existía dentro del producto. El problema era de discovery, no de features.
Tool que uso para esto: Hotjar o PostHog para session replay. No preguntes qué quieren. Mira qué hacen.
La diferencia entre construir lo que piden y construir lo que necesitan es la diferencia entre mantener un producto y resolver un problema real.
---
El Problema del Churn Silencioso: El 85% que Nunca Pide Nada
Las SaaS B2B típicas pierden entre un 5% y un 7% de usuarios activos mensuales por churn.
De esos usuarios perdidos, la mayoría nunca envió una feature request. Nunca habló con soporte. Nunca rellenó una encuesta NPS.
Su única voz son sus patrones de uso: descenso en frecuencia de login, reducción del surface area de features que tocan, caída en tiempo dentro de la app.
Priorizar por peticiones explícitas significa que estás construyendo exclusivamente para el 10-15% de usuarios que hablan, mientras ignoras las señales del 85% que se va sin hacer ruido.
El churn silencioso es el asesino invisible de las SaaS. Nadie te dice por qué se van. Simplemente dejan de aparecer.
Y mientras tú estás construyendo la feature que pidió el enterprise que factura un buen contrato, los 50 usuarios que se fueron este mes no te dejaron ni un ticket. Solo datos.
---
La Falsa Democracia de los Voting Boards
Los tableros públicos de feature requests son una trampa.
Parecen democracia directa. "Votad qué queréis que construyamos." Pero en realidad están diseñados para ser manipulados por:
- Power users que pasan 8 horas al día en tu producto y piden cosas que el 95% de tus usuarios nunca usará.
- Enterprise accounts que amenazan con irse si no construyes su feature personalizada.
- Los quejicas profesionales que tienen más upvotes porque tienen más tiempo para hacer campaña.
El resultado: una feature con 50 upvotes de 5 enterprise customers puede parecer urgente. Pero si los datos de uso muestran que esos mismos clientes solo usan el 20% de tus features existentes, el riesgo real no es que se vayan por falta de la feature nueva — es que no están adoptando lo que ya tienen.
Yo he caído en esta trampa. En mis primeros proyectos, miraba el board de feedback y construía lo que tenía más votos. El resultado era un producto lleno de features que usaban 3 personas mientras los 200 usuarios silenciosos seguían sin activarse.
---
El Framework de 5 Pasos para Priorizar por Datos de Comportamiento
La alternativa no es ignorar a los clientes. Es usar datos de uso como fuente primaria y peticiones explícitas como contexto secundario.
Aquí está el framework que uso en todos mis productos — lo llamo El Modelo de Priorización Asimétrica:
Paso 1: Instrumenta la Adopción de Features
Antes de decidir qué construir, mide qué se usa hoy.
Implementa tracking de eventos en cada feature de tu producto. PostHog, Amplitude, Mixpanel — elige uno. Mide:
- Features con alta adopción (stickiness): las que tus mejores usuarios usan a diario.
- Features con baja adopción: las que construiste y nadie tocó.
❌ Error común: Asumir que lo que no se usa no sirve. A veces es discovery, no valor.
✅ La pregunta correcta: ¿Los usuarios que se quedan usan esto? Si sí, el problema es que los nuevos no lo encuentran. No es una feature muerta — es un UX flow roto.
Paso 2: Mapea Cohortes de Retención Contra Uso de Features
Segmenta a tus usuarios en tres grupos:
- Activados: usan el producto con regularidad semanal.
- Retenidos: siguen ahí después de 3 meses.
- Churned: se fueron.
Ahora mira: ¿qué features usaba cada grupo antes del punto de decisión?
Las features que correlacionan con retención no son las que más pide la gente. Son las que aparecen en los patrones de uso de quienes se quedan.
En Grot, descubrimos que los usuarios retenidos no usaban la feature más votada del board. Usaban una feature secundaria que ni siquiera estaba en el roadmap. Si hubiéramos priorizado por votos, habríamos construido algo irrelevante.
Paso 3: Construye un Modelo de Scoring Ponderado
Asigna pesos a tres señales:
- Frecuencia de uso (50%): ¿cuántos usuarios interactúan con este patrón?
- Impacto en retención (30%): ¿correlaciona con que los usuarios se queden?
- Alineación estratégica (20%): ¿esto mueve el roadmap en la dirección correcta?
El peso del 50% en datos de comportamiento no es arbitrario. Es el único input que no miente. Las peticiones explícitas pueden estar sesgadas. Los datos de uso no.
Paso 4: Audita Tus Top 20 Feature Requests
Saca las 20 peticiones más votadas de tu CRM o soporte. Ahora cruza cada una contra:
- ¿Qué porcentaje de tu base total de usuarios la ha pedido?
- ¿Cuántos de esos usuarios están realmente activos?
- ¿Existe ya una forma de resolverlo dentro del producto?
Prepárate para encontrar que las peticiones más ruidosas representan menos del 10% de tus usuarios.
Y que un porcentaje significativo de ellas ya tienen solución en el producto — el usuario simplemente no la encontró.
Paso 5: Define una Métrica de Éxito Conductual Antes de Construir
Antes de escribir una línea de código, responde: ¿qué comportamiento esperas que cambie?
❌ "Los usuarios van a amar esta feature."
✅ "Esperamos que el 25% de los power users use esta feature 3 veces por semana en el primer mes."
Trata cada feature como un experimento con una hipótesis medible. Si no sabes cómo medirás el éxito, no sabes por qué la estás construyendo.
---
Objeción 1: "Pero mi enterprise de 100k/año me pide esto. Si no lo construyo, lo pierdo."
Aquí confundes escuchar con obedecer.
A los enterprise customers hay que gestionarlos, no servirles. Muchas peticiones se resuelven con:
- Un engagement de servicios profesionales.
- Un cambio de configuración que ya existe.
- Una explicación clara de la alternativa que ya tienen disponible.
Los datos de uso te dan una herramienta poderosa aquí. Puedes mostrarle al enterprise: "Mira, el 80% de lo que necesitas ya está en esta feature que no has tocado. Déjame enseñarte cómo usarla."
He salvado contratos enterprise enteros no construyendo lo que pedían, sino mostrándoles lo que ya tenían y no sabían usar.
---
Objeción 2: "Los datos de uso miran al pasado. Si solo construyo lo que ya se usa, nunca innovo."
Falso. Esto es una falsa dicotomía.
Los datos de uso revelan necesidades no cubiertas. Busca:
- Workarounds: ¿dónde exportan datos a otras herramientas para terminar una tarea?
- Drop-offs: ¿dónde abandonan un flow porque no pueden completarlo?
- Patrones de búsqueda: ¿qué escriben en la barra de búsqueda de tu producto?
Cada uno de estos es una señal de innovación, no de optimización. Las mejores features no vienen de preguntar "¿qué quieres?" Vienen de observar "¿dónde estás luchando?"
---
Objeción 3: "Somos una B2B startup con 50 cuentas. No tenemos datos suficientes."
Con 50 cuentas, los datos de comportamiento siguen siendo más fiables que los de peticiones.
No necesitas significancia estadística para A/B tests. Necesitas:
- Tasas de adopción por cuenta.
- Correlación entre uso de features y frecuencia de login.
- Entrevistas basadas en comportamiento real: "He visto que usas Feature A a diario pero nunca has tocado Feature B. ¿Qué pasa ahí?"
Esa información vale más que un board de feature requests con 5 upvotes y 3 comentarios.
---
Lo Que Realmente Cambia Cuando Priorizas por Datos de Uso
El cambio no es solo en el roadmap. Es en la cultura del equipo.
Los equipos que priorizan por peticiones centralizan las decisiones en product managers que actúan como "centros de triaje de peticiones." Los equipos que priorizan por datos distribuyen la toma de decisiones — ingenieros, diseñadores, PMs miran los mismos dashboards.
La conversación pasa de "¿quién pidió esto?" a "¿qué dicen los datos?"
Y eso reduce la influencia política del departamento más ruidoso o la cuenta que más factura.
---
La Única Pregunta Que Importa
No es "¿qué feature deberíamos construir?"
Es "¿qué comportamiento queremos cambiar, y cómo sabremos si lo hemos conseguido?"
El cliente que grita no tiene la respuesta. Los datos de uso sí.
La próxima vez que alguien te traiga una feature request con urgencia, no le preguntes por qué la necesita. Pregúntale qué está intentando hacer. Y luego mira las sesiones de grabación de tus usuarios para ver si lo que pide es realmente lo que necesita.
El mejor roadmap no lo construye el cliente que habla más alto. Lo construye el patrón de uso que habla más claro.
Artículos relacionados
- El 90% de los Founders No Sabe Validar Ideas. Cobran un Impuesto Invisible: el "Kindness Tax"
- Entrevistas con Clientes Que No Te Mienten: Cómo Validar Tu Idea Sin Caer en el Sesgo de Solución
- El 80% de los SaaS Define Sus Precios Sin Mirar Sus Propios Datos. Luego se Preguntan Por Qué No Convierten.
- Priorización de Features en SaaS: El Sistema Que el 90% de Founders Usa Mal
- Churn Analysis en SaaS: El Framework de las 5 Señales Para Diagnosticar Causas Raíz Antes de la Cancelación
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
