Cómo priorizar el roadmap con datos de uso (no solo con feedback)

En el artículo anterior cerraste la pregunta ¿Qué es lo que de verdad importa en mi producto? Ahora viene la siguiente y la que más reuniones eternas genera en cualquier equipo: ¿Qué construimos primero?

La priorización es probablemente el cuello de botella más lento y complicado del trabajo de un PM. Si te fijas, casi nadie la hace con datos: se hace con intuición, con la última conversación que tuvo el CEO, con la cuenta grande que amenazó con irse, con lo que ventas necesita para cerrar el próximo trimestre. Todo eso son señales válidas, pero el problema no es que se usen, es que se usen solas, y eso convierte la priorización en una competición de quién grita más fuerte.

Toda la idea del artículo cabe en esta frase:

El feedback sin contexto de uso distorsiona el roadmap.

Vas a ver dos tácticas concretas para meter datos de uso en tu priorización sin convertirla en un ejercicio frío de números. Sigo tirando del ejemplo ficticio de la empresa Algora de los artículos anteriores.

Por qué la intuición no debería decidir sola

Voy a anticipar la objeción más típica: «yo conozco a mis clientes, no necesito datos para priorizar». Esa frase la he oído mil veces y, no es mentira del todo. La intuición de alguien que lleva años en un producto vale mucho, pero también suele ser incompleta y, a veces, sistemáticamente sesgada.

Los sesgos más típicos cuando se prioriza sin datos:

• El cliente que más grita: Tres reuniones seguidas con la misma cuenta y de repente parece que es lo más importante.
• Lo que ventas pidió este mes: Lo que cierra una venta hoy puede no mover la métrica de retención mañana.
• Lo que el CEO recordó la última vez: Una conversación en un evento o lo que escuchó en un podcast se convierte en prioridad de Q3.
• Lo que el PM tiene ganas de construir: Sí, te ha pasado, me ha pasado.

Meter datos en la priorización no elimina estos sesgos, los hace visibles. Y eso ya es media batalla ganada, una conversación donde alguien dice «esta cuenta nos lo ha pedido cinco veces» cambia cuando otra persona pone delante el dato de que esa cuenta usa el producto un 30% menos que la media, la discusión se afila, no se cancela.

Táctica 1: prioriza feature requests por uso real

La primera táctica es la más simple y la más infrautilizada: cuando entren peticiones de mejora, ordénalas por el uso de la funcionalidad que afectan.

No priorizas solo una petición; priorizas sobre cuánta superficie de producto impacta. Cada mejora hereda el alcance de la funcionalidad que toca.

Una petición de mejora en una funcionalidad del top 5 de uso tiene un impacto potencial muy distinto a la misma petición en una funcionalidad que toca el 4% de tus cuentas. La primera afecta a una parte real de tu base, la segunda, a casi nadie, y eso debería pesar en al decisión.

Como yo lo aplico: cualquier petición que entre en el backlog se etiqueta con la funcionalidad asociada y el porcentaje de adopción actual de esa funcionalidad. En el sprint review, las que estén en funcionalidades del top entran con ventaja en la conversación; las que estén en funcionalidades en el cuadrante «sunset o fix» de la matriz del artículo del aha moment se cuestionan antes de meterlas en el backlog activo. Ojo, ventaja no es decisión: sigue habiendo discusión, sigue pesando el contexto, pero la conversación arranca con un sesgo informado, no con un empate ciego.

Una nota importante para no contradecirme: que una funcionalidad tenga poco uso hoy no significa automáticamente baja prioridad. En el artículo del Aha moment ya vimos que algunas de las mejores oportunidades viven precisamente ahí: poca adopción y alta retención (las «growth opportunities» del cuadrante arriba a la izquierda de la matriz).

Lo que esta táctica te dice es que el alcance de la mejora depende del alcance de la funcionalidad, no que poco uso = ignorar. Si vas vas a empresas grandes y quieres atacar Enterprise, una funcionalidad poco adoptada hoy puede ser exactamente la que necesitas mejorar para cerrar ese segmento. Los datos no deciden por ti, te dicen dónde estás invirtiendo.

Y aquí un problema real: priorizar por uso real puede llevarte a hiper-optimizar el core actual y descuidar el resto, lo que llamo hacer más grande solo lo que ya es grande. Mejoras incrementales sobre la funcionalidad estrella suben muy bien una curva ya alta, pero rara vez abren un nuevo motor de retención. Y ese motor suele estar en una funcionalidad secundaria que, con una mejora pequeña, salta de un cuadrante a otro de la matriz, reserva siempre una franja del backlog para las oportunidades de crecimiento, no solo para el core, si solo construyes sobre lo grande, te quedas grande pero plano.

Táctica 2: cruza presión explícita con evidencia de comportamiento de los clientes o usuarios

La segunda táctica es más sofisticada y la que más cambia conversaciones, cuando te llegue una avalancha de peticiones sobre algo, antes de priorizarlo, contrasta la presión explícita (lo que te piden) con la evidencia de comportamiento (lo que tus usuarios realmente hacen).

La diferencia aquí no es trivial «Feedback» sugiere volumen y cantidad, «Presión explícita» deja claro que es lo que llega como ruido, como petición, como queja, como llamada del Customer Success Manager: alguien lo está empujando hacia ti.

Y «evidencia de comportamiento» es lo opuesto: lo que la gente hace cuando nadie le pregunta. Las dos cosas pesan, pero no son lo mismo. Mucha presión explícita sin evidencia de comportamiento debajo es ruido caro.

Interpretación del ejemplo:

(Arriba-Derecha) Mucha presión + mucha evidencia = Prioridad alta: La funcionalidad mueve a mucha gente y mucha gente la quiere mejorar. Es donde la intuición y los datos coinciden, lo normal es seguir el proceso habitual y priorizar.

(Abajo-Derecha) Mucha presión + poca evidencia = Investigar antes. Esta es la trampa más común, aquí están los casos de «100 peticiones de la misma cosa» que resultan ser una sola cuenta escribiéndolo en cinco canales distintos, o un cliente Enterprise que llama una vez por semana al Customer Success. Antes de construir, investiga: ¿Cuántas cuentas únicas lo piden? ¿Qué tienen en común? ¿La funcionalidad asociada la usan ya o están opinando sin haberla probado?

(Arriba-Izquierda) Poca presión + mucha evidencia = Atiende a los silenciosos: Aquí están las oportunidades más jugosas que casi nadie ve, porque por definición no aparecen en el feedback explícito. Funcionalidades muy usadas pero sin peticiones suelen ser candidatas a mejoras invisibles que mueven retención: micro-fricciones que la gente sufre sin reportar, o mejoras de performance.

Mira las cohortes de churn temprano: lo que esos usuarios usaron y no volvieron suele estar aquí. Más abajo en el artículo hablamos mas sobre este cuadrante en el cierre porque es el que más se infravalora.

(Abajo-Izquierda) Poca presión + poca evidencia = Déjala como está o, si lleva muerta mucho tiempo, sunset (ver artículo 17).

Dos errores que esta matriz evita, y se ve todo el rato en equipos que priorizan solo por feedback:

1. Construir para los que más se quejan: Confundir volumen de feedback con prioridad. El que grita no representa al que se queda.
2. Construir lo que la gente cree que va a usar pero luego no usa: Las peticiones sobre funcionalidades que el usuario no ha probado son interesantes, pero no son evidencia.

El caso de Algora: tres peticiones, tres lecturas

Volviendo al ejemplo. Esta semana, en Algora llegan tres peticiones sobre la mesa del PM:

• «Exportación masiva»: 7 peticiones en cuatro semanas, todas de la misma cuenta Enterprise grande.
• «Más automatizaciones del dashboard»: 14 peticiones distintas, de 11 cuentas diferentes, mayoría Enterprise.
• «Integración con ERP X»: 3 peticiones, de 3 cuentas Enterprise, pero todas conectaron CRM en el primer mes.

Si solo miran el volumen de feedback, «automatizaciones» gana, «exportación masiva» parece importante por presión de la cuenta grande, y «ERP X» pasa desapercibido.

Al cruzar con uso real:

• «Exportación masiva» → 7 peticiones, 1 cuenta única. La adopción de «exportación» hoy es del 4% en cuentas Enterprise. Cuadrante «investigar antes»: probablemente es una necesidad puntual de una cuenta, no un patrón. Conversación con ese cliente para entender el problema real, no necesariamente construir.
• «Automatizaciones del dashboard» → 14 peticiones, 11 cuentas únicas. La funcionalidad asociada (dashboard de contratos) es el aha moment con 78% de adopción. Cuadrante «prioridad alta»: dato + feedback alineados. Prioriza.
• «Integración con ERP X» → 3 peticiones, pero el 89% de las cuentas Enterprise ya conectan CRM. Hay patrón de uso. Cuadrante «atiende a los silenciosos»: poco feedback pero alta probabilidad de mover retención de Enterprise, que es el objetivo del año.

Resultado de la priorización: «automatizaciones» sube al sprint, «ERP X» entra a discovery profundo, «exportación masiva» se trata como conversación con un cliente concreto, no como roadmap.

Sin los datos, seguramente el orden habría sido el contrario.

Cómo aplicarlo en tu próxima sesión de priorización

Una rutina práctica que puedes empezar mañana:

Antes de la reunión, prepara una mini-tabla con cinco columnas:

1. Petición (nombre corto).
2. Menciones totales (cuántas veces ha aparecido).
3. Cuentas únicas que la han pedido.
4. Uso actual de la funcionalidad asociada, medido como % de cuentas o usuarios activos que la usan en los últimos 30 días. No mires volumen total de eventos: una sola cuenta Enterprise muy ruidosa puede generar 10.000 eventos y enmascarar que solo la usa una.
5. Segmento que la pide (Enterprise, SMB, Free…).

Y una sexta columna que sale de las cinco anteriores: decisión sugerida según el cuadrante.

Llevar esa tabla a la reunión cambia la conversación. No resuelve los debates, pero los enfoca y te facilitará la alineación con el equipo. La pregunta deja de ser ¿quién tiene razón? y pasa a ser ¿estamos viendo lo mismo?. Y eso ya es una buena reunión de priorización.

Recuerda lo del artículo 9 sobre debates estériles: una buena estrategia analítica no elimina las discusiones, evita las inútiles, aquí pasa lo mismo, los datos no priorizan por ti, te ahorran la mitad de la pelea.

Una nota sobre los que no se quejan (Silenciosos)

Voy a cerrar con una idea que casi nadie verbaliza y que conviene tener muy en cuenta: los clientes más peligrosos no son los que se quejan, son los que se van sin decir nada.

Si solo priorizas por feedback explícito, estás optimizando para la fracción de usuarios que escribe. En la mayoría de productos, esa parte es minúscula (un 1-5% según el sector). El resto sufre micro-fricciones, abandona en silencio y desaparece de tu MAU sin avisarte.

La forma de oír a los silenciosos es mirar comportamiento, no feedback: cohortes de churn temprano, funnels donde caen sin completar, sesiones que se cortan a los pocos segundos. Cuando combinas el feedback de los que sí hablan con el uso de los que no hablan, prácticamente nunca priorizas lo mismo que cuando miras solo lo primero, y por norma general casi siempre el cambio impacta más en métricas.

Resumen rápido

• La priorización sin datos es una competición de quién grita más fuerte: No es mala la intuición, pero no debería decidir sola.
• Táctica 1: prioriza peticiones por uso real de la funcionalidad asociada. Una mejora en el top 5 pesa muy distinto que una en el #28.
• Táctica 2: cruza presión explícita con evidencia de comportamiento en una matriz 2×2. Cuatro cuadrantes (prioridad alta, investigar antes, atiende a los silenciosos, déjala como está) ordenan la conversación.
• El que grita no representa al que se queda: Atender solo a los que escriben suele ser priorizar para una minoría.
• Los datos no priorizan por ti, te ahorran la mitad de la pelea: Enfocan la conversación, no la cancelan.

Siguiente paso

Si decides bien qué construir, viene el siguiente reto: asegurarte de que se usa. Lanzar una funcionalidad y verla en un 8% de uso es uno de los dolores más comunes en producto. En el siguiente artículo cuento cómo medir la adopción de nuevas funcionalidades y qué palancas mover cuando flojea.

Cómo medir la adopción de nuevas funcionalidades y mejorarla cuando flojea →