Cómo priorizar solicitudes de funcionalidades sin perder la cabeza
Cada usuario quiere algo diferente. Aquí tienes frameworks prácticos para decidir qué construir a continuación — sin hojas de cálculo, sin reuniones de comité y sin culpa.
Tienes 47 solicitudes de funcionalidades. Tres clientes de pago amenazan con irse si no construyes integraciones. Tu cofundador piensa que el flujo de onboarding necesita un rediseño. Un usuario en Twitter acaba de pedir públicamente el modo oscuro. Y tienes exactamente un desarrollador.
Bienvenido al infierno de las solicitudes de funcionalidades.
Cada equipo de producto enfrenta este problema, pero la mayoría lo maneja mal. O construyen lo que el cliente más ruidoso pide, o ignoran completamente el feedback y construyen lo que les parece bien. Ambos enfoques fallan.
Hay una mejor manera.
Por qué la mayoría de los frameworks de priorización no funcionan
Probablemente hayas visto frameworks como RICE o MoSCoW. Se ven geniales en artículos de blog, pero en la práctica, tienen un defecto fatal: te obligan a estimar cosas que realmente no puedes estimar.
En su lugar, aquí hay tres preguntas que realmente ayudan.
Pregunta 1: ¿Cuántas personas pidieron esto?
Si 20 usuarios diferentes han mencionado el mismo problema, probablemente sea real.
Cómo rastrearlo: Cada vez que recibas feedback mencionando un tema, etiquétalo. No necesitas un sistema sofisticado.
El insight clave: no estás contando votos. Estás contando señales independientes.
Pregunta 2: ¿Qué pasa si no construimos esto?
Señales de que una funcionalidad es bloqueante:
- Los usuarios describen soluciones alternativas que han construido
- Múltiples usuarios la mencionan durante el onboarding, y luego se van
- Aparece en cada llamada con clientes
Señales de que es nice-to-have:
- Los usuarios dicen "estaría genial si..."
- Solo aparece cuando preguntas
- Nadie se ha ido por eso
Pregunta 3: ¿Se alinea con nuestra dirección?
La regla práctica: si puedes describir la funcionalidad como "también hacemos X", probablemente sea scope creep. Si puedes describirla como "esto hace que nuestra funcionalidad principal sea mejor", probablemente valga la pena.
Un proceso semanal práctico
Lunes: Leer todo
Lee cada pieza de feedback de la semana pasada. No evalúes ni priorices — solo lee.
Etiquetar temas
Etiqueta temas recurrentes. "Exportación", "móvil", "rendimiento", "integraciones", "onboarding".
Evaluar el top 3
Toma los tres temas más comunes y haz las tres preguntas.
Comunicar
Actualiza tu roadmap. Dile a los usuarios qué estás construyendo y por qué.
El anti-patrón: Construir para un solo cliente ruidoso
Resiste la tentación. La solicitud de un cliente es una anécdota. Diez clientes pidiendo lo mismo es data.
Para empezar
Necesitas:
- Un lugar donde llegue el feedback — un widget en tu sitio
- Un hábito semanal de lectura — 30 minutos, cada lunes
- Un sistema de etiquetado simple
- Un roadmap visible
Herramientas como Palmframe hacen que los pasos 1 y 4 sean triviales.
Want to start collecting feedback? Try Palmframe for free — takes 2 minutes to set up.