Para priorizar peticiones de funciones, agrúpalas según el problema que hay detrás, puntúa cada problema por alcance, dolor, encaje y esfuerzo, y habla con algunas de las personas que las pidieron antes de comprometerte. Ese último paso es el que se salta la mayoría de los equipos, y es el momento más barato para detectar una mala apuesta. Crear lo que no toca es habitual: el informe de adopción de funciones de 2019 de Pendo, basado en tres meses de datos de uso de 615 suscripciones de clientes de Pendo, concluyó que el 80 % de las funciones de un producto de software medio se usan poco o nunca.
Ideas clave
- Una petición de función es la propuesta de un cliente para una solución. Prioriza el problema que hay detrás.
- Los votos muestran quién habló, no cuánto duele el problema.
- Elige cualquier método sencillo, pero aliméntalo con lo que aprendes al hablar con quienes hicieron las peticiones.
- Decide y luego cuéntale a la gente qué decidiste, incluso si es un no.
Por qué los votos engañan
La mayoría de los equipos registran las peticiones en algún sitio: un tablero, una hoja de cálculo, un canal de Slack. Luego crean lo que tenga más votos. Parece justo, pero es arriesgado.
- Los clientes que hacen ruido cuentan. Los callados, no. Quienes publican peticiones no siempre son los clientes que más quieres conservar.
- Las peticiones son soluciones, no problemas. «Añadan una exportación a CSV» puede significar en realidad «mi jefa quiere un informe semanal». Un email de resumen programado podría resolverlo mejor.
- Los duplicados dividen los votos. Cinco peticiones redactadas de cinco formas parecen cinco problemas pequeños en lugar de uno grande.
- Los votos no tienen peso. Una petición que retendría a una cuenta grande cuenta lo mismo que algo que estaría bien tener.
- Los votos no caducan. Las peticiones antiguas siguen arriba mucho después de que la necesidad haya desaparecido.
Un voto es una señal para ir a preguntar. No es la respuesta.
Los métodos de priorización, en resumen
Verás los mismos métodos en todas las guías. Esto es para lo que sirve cada uno.
| Método | Cómo funciona | Ideal para | Cuidado con |
|---|---|---|---|
| Recuento de votos | Ordenar por número de peticiones | Una primera señal | Los clientes que hacen ruido, los duplicados divididos |
| RICE | Alcance × Impacto × Confianza ÷ Esfuerzo | Comparar muchas ideas | La confianza suele ser una suposición |
| ICE | Impacto × Confianza × Facilidad | Un triaje rápido | Muy subjetivo |
| MoSCoW | Must, Should, Could, Won’t (imprescindible, debería, podría, no ahora) | Un plazo o un lanzamiento fijo | No hay orden dentro de cada grupo |
| Impacto vs. esfuerzo | Una matriz sencilla de 2×2 | Encontrar victorias rápidas | Ignora a cuántas personas afecta |
| Kano | Funciones básicas, de rendimiento y de entusiasmo | Entender las expectativas | Necesita una encuesta para hacerlo bien |
| Ponderación por ingresos | Ponderar cada voto por el valor de la cuenta | B2B con pocas cuentas grandes | Puede dar demasiado peso a unos pocos clientes grandes |
RICE, descrito por primera vez por Sean McBride en Intercom, es una opción sensata por defecto para la mayoría de los equipos de producto. Pero todos los métodos tienen el mismo punto débil: el alcance, el impacto y la confianza dependen de lo bien que entiendas el problema. Los pasos siguientes tratan de hacer bien esa parte.
Paso 1: Reúne todas las peticiones en un solo sitio
Las peticiones llegan por tickets de soporte, llamadas de ventas, mensajes dentro de la app, emails y reseñas. Ponlas en una sola lista para verlas una al lado de otra.
De cada petición, apunta:
| Campo | Ejemplo |
|---|---|
| Petición | Exportar informes en CSV |
| Quién la pidió | Responsable de operaciones de un cliente mediano |
| Sus palabras exactas | «Cada lunes copio números en una hoja de cálculo para mi jefa». |
| Plan o segmento | Plan Business, 40 licencias |
| Origen y fecha | Ticket de soporte, 3 de marzo |
Sus palabras exactas son lo más importante. A menudo muestran el problema con más claridad que la propia petición.
No te olvides de las fuentes calladas. Las notas de las ventas perdidas y las respuestas de los clientes que cancelaron suelen contener peticiones que nunca llegan a tu tablero.
Paso 2: Encuentra el problema detrás de cada petición
Reescribe cada petición como un problema, con una frase sencilla:
Quién intenta objetivo, pero obstáculo.
Para el ejemplo del CSV: «Los responsables de equipo intentan compartir los números semanales con su jefa, pero tienen que copiarlos a mano».
Ahora agrupa las peticiones que comparten un problema. Cinco peticiones distintas (exportación a CSV, emails programados, un enlace público al panel, un botón de PDF y un endpoint de API) pueden ser todas el mismo problema. Juntas, son mucho más grandes de lo que parecía cualquiera de ellas por separado.
Esta es la idea central de los jobs to be done: la gente no quiere la función en sí. Quiere el avance que le da.
Paso 3: Habla con quienes lo pidieron
Antes de puntuar nada, habla con algunas de las personas detrás de tus grupos más grandes. Una conversación corta te dice más que un montón de votos.
Pregunta por su situación real, no por tu idea:
- «¿Qué intentabas hacer cuando pediste esto?»
- «¿Cómo lo resuelves hoy?»
- «¿Cada cuánto te pasa?»
- «¿Qué pasa cuando no se hace?»
- «¿A quién más afecta?»
Evita «¿Lo usarías si lo creáramos?». Casi todo el mundo dice que sí, así que no te dice nada. Nuestra guía de preguntas sesgadas tiene más ejemplos que conviene evitar.
Cómo suena una buena conversación
Tú: ¿Qué intentabas hacer cuando pediste la exportación a CSV?
Cliente: Meter nuestros números en el informe del lunes.
Tú: ¿Quién lee ese informe?
Cliente: Mi jefa. Solo quiere tres números y la tendencia. Cada semana los copio en unas diapositivas.
Tú: ¿Cuánto tiempo te lleva?
Cliente: Casi una hora, todos los lunes.
La petición era «exportación a CSV». La necesidad es «enseñarle a mi jefa tres números cada semana sin el trabajo pesado». Un email de resumen programado podría resolverlo en una fracción del tiempo de desarrollo, y ayudaría a todos los clientes con el mismo ritual de los lunes.
Pruebas sólidas y pruebas débiles
| Señal débil | Señal sólida |
|---|---|
| «Estaría bien tenerlo». | «Dedico una hora a esto cada lunes». |
| «Claro, lo usaría». | «Pagamos otra herramienta solo para hacer esto». |
| Un solo voto | Un apaño que se montaron ellos mismos |
| «Todo el mundo lo quiere». | Nombres, fechas y lo que les costó |
Cuántas conversaciones son suficientes
Sigue hablando con gente hasta que puedas predecir lo que dirá la siguiente persona. Cuando las historias empiezan a repetirse, entiendes el problema lo bastante bien como para puntuarlo.
Si las historias siguen cambiando, eso también es un hallazgo. Una misma petición puede abarcar varios problemas distintos, y deberías dividir el grupo. Para más preguntas, consulta nuestras preguntas para entrevistas con clientes.
Paso 4: Puntúa cada problema
Ahora puntúa los problemas, no las peticiones. Que sea sencillo. Una puntuación que tu equipo actualiza de verdad es mejor que una perfecta que nadie toca.
Valora cada problema del 1 al 3 en cuatro aspectos:
- Alcance: cuántos de los clientes que te importan tienen este problema.
- Dolor: cuánto les duele, según lo que escuchaste.
- Encaje: lo bien que encaja resolverlo con el rumbo de tu producto.
- Esfuerzo: cuánto trabajo supone. Más alto significa más trabajo.
Luego calcula: Alcance × Dolor × Encaje ÷ Esfuerzo.
| Problema | Alcance | Dolor | Encaje | Esfuerzo | Puntuación |
|---|---|---|---|---|---|
| Compartir los números semanales con los jefes | 3 | 2 | 3 | 2 | 9 |
| Inicio de sesión único para equipos grandes | 1 | 3 | 3 | 3 | 3 |
| Modo oscuro | 2 | 1 | 1 | 2 | 1 |
Gana el problema de compartir, aunque el modo oscuro tuviera más votos por sí solo. Las peticiones sobre compartir estaban repartidas entre cinco ideas de funciones distintas, así que ninguna parecía grande.
Pondera por ingresos, con cuidado
En B2B es razonable dar más peso a los problemas que afectan a tus cuentas más grandes o que más rápido crecen. Pero no dejes que la ponderación por ingresos dirija la hoja de ruta. Unos pocos clientes grandes pueden arrastrarte hacia funciones que nadie más necesita, y los segmentos nuevos que quieres conquistar todavía no generan ingresos.
Cuando lo pide un cliente grande
A veces una cuenta grande quiere algo que nadie más ha pedido. Es tentador decir que sí enseguida.
Primero, encuentra el problema que hay detrás, igual que con cualquier otra petición. Luego pregúntate si clientes más pequeños como ellos se toparán con el mismo problema a medida que crezcan. Si es así, puede tener sitio en la hoja de ruta. Si solo encaja con esa cuenta, trátalo como un acuerdo a medida con un precio y un plazo claros.
Deja espacio para tus propias apuestas
Las peticiones de los clientes te muestran los problemas de hoy. Rara vez te muestran hacia dónde va el mercado. Decide de antemano qué parte del tiempo de tu equipo va a los problemas de los clientes, a tus propias apuestas estratégicas y a los arreglos y el mantenimiento. Después prioriza las peticiones dentro de su parte, para que un tablero muy activo no se adueñe en silencio de toda la hoja de ruta.
Paso 5: Decide y cierra el ciclo
Elige el problema principal, escoge una solución y avisa a quienes lo pidieron. Los clientes que reciben respuesta siguen contándote lo que necesitan. Nuestra guía sobre el ciclo de feedback de clientes te enseña a convertirlo en un hábito.
Decir que no forma parte del trabajo. Dos plantillas que puedes adaptar:
Ahora no
Hola, nombre:
Gracias por preguntar por función. No la vamos a crear este trimestre.
Primero nos vamos a centrar en otro problema, porque afecta a más clientes.
Comentaste que intentas su objetivo. Mientras tanto, así es como
lo resuelven algunos clientes: alternativa o artículo de ayuda.
He guardado tu nota con tus palabras exactas y te avisaré si esto cambia.
No está previsto
Hola, nombre:
Gracias por la idea sobre función. Quiero ser sincero contigo:
no encaja con el rumbo que estamos dando a producto, así que no tenemos previsto crearla.
Para su objetivo, otra herramienta o alternativa puede encajar mejor.
Si tus necesidades cambian, me seguirá interesando saberlo.
Un ritmo sencillo que mantiene la lista al día
Priorizar una sola vez no sirve de mucho. Una rutina ligera, sí.
| Frecuencia | Qué hacer |
|---|---|
| Cada semana | Añade las peticiones nuevas con las palabras exactas, une los duplicados y vincula cada una a un problema |
| Cada mes | Habla con entre tres y cinco personas de tus grupos de problemas más grandes |
| Cada trimestre | Vuelve a puntuar la lista, elige lo siguiente y cuéntales a quienes lo pidieron qué decidiste |
Veinte minutos a la semana bastan para la mayoría de los equipos. Las conversaciones mensuales son las que mantienen tus puntuaciones ligadas a clientes reales y no a quien publicó lo último.
Errores que debes evitar al priorizar peticiones de funciones
- Crear para el cliente que más ruido hace. Comprueba primero si otros comparten el problema.
- Puntuar funciones en lugar de problemas. Dividirás un problema grande en peticiones pequeñas que parecen todas menores.
- Preguntar si la gente lo usaría. Pregunta cómo resuelve el problema hoy.
- No mirar nunca atrás. Vuelve a puntuar tu lista cada trimestre. Las necesidades cambian, y tu producto también.
Cómo te ayuda Diaform
Hablar con todas las personas detrás de una petición lleva tiempo, y la mayoría no va a reservar una llamada. Con Diaform puedes enviar un enlace en su lugar. Un agente de IA hace tus preguntas por voz o por texto, profundiza cuando alguien dice «estaría bien tenerlo» y resume cada conversación al terminar.
Envía el enlace por email o muéstralo dentro de tu app. Desde el plan Pro, los enlaces solo por invitación pueden llevar el email o el ID de usuario de cada persona, así que sabes qué cuenta dijo qué. Exporta las respuestas a CSV y añádelas a tu hoja de puntuación. Mira cómo gestiona Diaform el feedback de producto o empieza una prueba gratis de 14 días.
