Priorización de funcionalidades: qué construir primero
La fundadora llegó al kickoff con una hoja de cálculo. Cuarenta y una filas, una funcionalidad en cada una, todas marcadas como “imprescindible”. Estaba construyendo una herramienta de reservas y pagos para una pequeña cadena de peluquerías caninas, tenía demanda real, y tenía un presupuesto que cubría quizá ocho de las cuarenta y una. Cuando le pregunté cuáles ocho, dijo que todas eran esenciales. Ese es el momento en que la priorización de funcionalidades de verdad empieza, y es el momento en que la mayoría de los founders se bloquea.
La priorización de funcionalidades es decidir qué features construir primero, y cuáles recortar o aplazar, cuando no puedes construir todo a la vez. Toda guía en la primera página de Google te entregará un framework de puntuación para ello: RICE, MoSCoW, Kano, matrices ponderadas. Esos frameworks son reales y funcionan, pero se hicieron para product managers que ya tienen un producto, datos de uso y un equipo. Como founder no técnico al principio, tienes una lista de deseos, un presupuesto fijo y ningún dato todavía. Tu problema no es la cuenta. Es el bloqueo.
Por qué los frameworks no arreglan tu problema de verdad
Un framework de puntuación toma una lista de features y las ordena por alguna combinación de valor y coste. El RICE, el método que Intercom popularizó, multiplica alcance, impacto y confianza, y divide por el esfuerzo. El MoSCoW separa todo en imprescindible, importante, deseable y fuera de alcance. Son genuinamente útiles cuando tienes los insumos que necesitan.
La trampa es que los insumos son la parte difícil, y al principio no los tienes. Alcance e impacto son estimaciones de a cuántos usuarios toca una feature y cuánto mueve una métrica. Tienes cero usuarios y ningún histórico de métricas, así que cada número que metes es una conjetura disfrazada de aritmética. El framework entonces lava tu conjetura en una puntuación de aspecto seguro, y tomas una decisión de build de seis cifras sobre un número que inventaste. Eso es peor que ningún framework, porque parece riguroso.
Así que el trabajo de verdad ocurre antes de la matriz. Priorizar al principio no es un cálculo. Es una decisión sobre qué estás dispuesto a lanzar sin tener. Hasta que tomes esa decisión con honestidad, ningún framework te salvará, y una vez que la tomas, casi no necesitas uno.
El método de priorización del founder
Esto es lo que de verdad corremos con los founders antes de que nadie abra una hoja de puntuación. Cuatro preguntas, hechas a cada feature de la lista.
Primera: ¿esta feature hace que alguien pague, o hace que alguien se quede? No “es bonita”. No “a un usuario le gustaría”. ¿Hace que una persona meta una tarjeta, o vuelva la semana siguiente? El flujo de reservas de las peluquerías hacía pagar a los dueños porque sustituía un sistema de teléfono y cuaderno que perdía citas. El módulo de puntos de fidelidad no hacía ni una cosa ni la otra en el lanzamiento. Una era de día uno; la otra podía esperar un año.
Segunda: si la quitaras, ¿se rompería el trabajo central? Todo producto hace un trabajo principal. Para la herramienta de las peluquerías, el trabajo era “tomar una reserva y cobrar sin una llamada”. Quita los pagos online y el trabajo se rompe. Quita el calendario de disponibilidad por profesional y el trabajo se rompe. Quita los recibos por correo personalizables y el trabajo sigue en pie, el recibo solo queda más simple. Las features que rompen el trabajo central al quitarlas no son negociables. Todo lo demás sí.
Tercera: ¿la demanda es real, o es el cliente más ruidoso? Los founders sobreponderan de forma consistente al único cliente que manda tres correos sobre una feature concreta. Ese cliente no es tu roadmap. Es una voz, a menudo la menos representativa, y construir su feature favorita primero es como acabas con un software con la forma de tu cliente más exigente en lugar de tu mercado. Pregunta cuánta gente ha pedido, de forma espontánea, lo mismo. Una es ruido. Ocho es señal.
Cuarta: ¿puede esperar a que los usuarios te lo digan? La feature más barata es la que no construyes porque el uso real dejó obvio que no la necesitabas. Si una feature no es de día uno y no rompe el trabajo central, el movimiento correcto suele ser lanzar sin ella y dejar que los usuarios reales te digan si importa. Lo harán, y serán más honestos que tu hoja de cálculo.
Pasa esas cuatro preguntas y las cuarenta y una filas se ordenan en tres montones: construir ahora, construir después y probablemente nunca. La fundadora de la herramienta de peluquería terminó con nueve features en el montón “construir ahora”, no cuarenta y una, y las nueve eran las que hacían pagar a los dueños. Lanzamos en diez semanas en vez de ocho meses, y el módulo de fidelidad que había marcado como imprescindible nunca se construyó, porque, una vez que los dueños estaban en marcha, ninguno lo pidió.
Las cuarenta y una filas, ordenadas
Ayuda ver el método corriendo contra filas reales, porque la versión abstracta hace que toda feature suene igual de importante y la concreta no. Seis de sus ítems, y dónde acabó cada uno:
Reservas online con disponibilidad en vivo fue a construir-ahora. Hacía pagar a los dueños (era la razón para dejar el teléfono) y quitarla rompía el trabajo central. Pago con tarjeta en la reserva: construir-ahora, misma lógica, ya que “cobrar sin una llamada” era la mitad del trabajo. Un calendario con horarios por profesional: construir-ahora, porque una reserva que asigna dos clientes al mismo profesional es peor que ninguna reserva.
Entonces la línea se movió. Recordatorios automáticos por SMS: construir-después. Los dueños los querían y reducen las ausencias, pero la herramienta funcionaba sin ellos en el lanzamiento, y se podían ver las tasas reales de ausencia antes de gastar en ello. Recibos por correo personalizados y con la marca: construir-después rozando el nunca, porque un recibo simple hace el trabajo y la personalización era gusto, no ingresos. El motor de puntos de fidelidad: probablemente-nunca, el ítem más caro de la lista, marcado como imprescindible por instinto, pedido por ningún dueño de peluquería real una vez en marcha.
La cuestión no es que los puntos de fidelidad sean malos. Es que la fundadora los había puesto con el mismo peso que cobrar, porque una lista de deseos aplana todo en “querer”. Las cuatro preguntas desaplanan. Convierten cuarenta y un deseos iguales en nueve cosas que el producto necesita para hacer su trabajo y treinta y dos cosas que pueden demostrar que importan después.
Cada sí es un no en otra parte
La razón de que priorizar duela es que los founders lo viven como suma. Cada feature es algo que quieren, y recortarla se siente como pérdida. El reframe que ayuda es ver la priorización como resta contra un número fijo.
Tienes un presupuesto. Sea lo que cuesta construir la app o las semanas de tiempo de tu único desarrollador, es finito, y compra una cantidad fija de build. Cada feature a la que dices sí es una feature, o una semana, a la que has dicho no en otra parte. El módulo de fidelidad no es gratis aunque lo ames. Cuesta el flujo de onboarding que no puliste, o las tres semanas que no gastaste en lo que de verdad hace pagar a los dueños. Cuando un founder ve la lista como un presupuesto que se gasta en vez de una lista de deseos que se concede, los recortes se vuelven más fáciles, porque ahora está intercambiando, no perdiendo.
Esa es también la disciplina que evita que el feature creep se coma el build. El creep ocurre cuando se añaden features nuevas sin que se quite nada para pagarlas. Un founder que prioriza por resta tiene una respuesta lista para la petición de “¿podemos añadir también?” a mitad del build: claro, ¿y qué sale para hacer sitio?
Hay una trampa más que vale la pena nombrar, porque atrapa a los founders agudos en especial. Algunas features se priorizan no por un cliente sino por un público: el dashboard vistoso que queda bien en una demo de captación, la feature de IA añadida porque un miembro del consejo preguntó si tienes una. Querer lanzar algo creíble para los inversores el próximo trimestre es una presión real, y a veces la feature de demo vale la pena. Pero pásala por las mismas cuatro preguntas, con honestidad. Si una feature solo hace asentir a un inversor y nunca hace que un cliente pague o se quede, es un coste de marketing disfrazado de producto, y debería presupuestarse como tal, no colarse a lo más alto de la lista de build.
Cuándo los frameworks por fin ganan su lugar
Nada de esto significa que RICE y MoSCoW sean inútiles. Significa que son herramientas de etapa posterior, y echas mano de ellas en el momento correcto, no en el primero.
El momento es cuando tienes usuarios. Cuando tu producto está en marcha y la gente lo usa, por fin tienes los insumos para los que los frameworks fueron diseñados: alcance real, impacto observado, evidencia en vez de conjeturas. Ahí es cuando una matriz de puntuación deja de lavar tus conjeturas y empieza a organizar tu evidencia. Un founder con tres meses de datos de uso y un backlog de cuarenta peticiones debería sin duda correr RICE sobre ellas. Un founder en el kickoff sin usuarios debería correr las cuatro preguntas y resistir las ganas de vestir una conjetura de puntuación.
El arco es simple. Antes del lanzamiento, prioriza por criterio, contra el trabajo y el presupuesto. Después del lanzamiento, prioriza por datos, con el framework que le sirva a tu equipo. El error es usar el segundo método cuando aún estás en la primera situación. Esa es la misma disciplina detrás de lanzar un producto mínimo viable de verdad y saber dónde gastar el esmero en un minimum lovable product: decide para qué sirve la primera versión de verdad, y deja que todo lo demás espere su turno.
Cómo decir que no sin perder al cliente
El último miedo que los founders plantean es que recortar features les costará el cliente que las quería. Normalmente no, si manejas bien el no. “No vamos a construir eso” cae mal. “Está en la lista, y aquí está por qué va después de las cosas que te ponen en marcha más rápido” cae bien, porque le muestra al cliente que está en una secuencia, no en la basura. La gente acepta quedar para después mucho más fácilmente que ser ignorada, y un founder que sabe explicar el orden del build suena como alguien que lo controla.
La fundadora de las peluquerías todavía tiene esa hoja de cuarenta y una filas. La mayor parte está ahora en las columnas “después” y “nunca”, anotada con qué cliente real lo pidió y cuántas veces. Resultó un roadmap mejor que el original, porque cada ítem se había ganado su lugar en vez de empezar ahí.
Preguntas frecuentes
¿Qué es el método de priorización de funcionalidades? Es el proceso de decidir qué features de producto construir primero, y cuáles aplazar o recortar, cuando no puedes construir todo a la vez. Al principio, antes de tener datos de uso, es un juicio contra el trabajo central del producto y tu presupuesto, no un ejercicio de puntuación.
¿Cuáles son los 4 niveles de priorización? El esquema de cuatro niveles más común es MoSCoW: imprescindible (el producto se rompe sin ella), importante (relevante pero no vital en el lanzamiento), deseable (buena si hay sitio) y fuera de alcance (explícitamente fuera por ahora).
¿Cuáles son los cuatro métodos de priorización? Métodos muy usados incluyen RICE (alcance, impacto, confianza, esfuerzo), MoSCoW, el modelo Kano (features básicas, de rendimiento y de deleite) y una simple matriz de valor frente a esfuerzo. Funcionan mejor cuando tienes datos de uso reales para alimentarlos.
¿Cuál es el objetivo principal de la priorización de funcionalidades? Gastar un presupuesto y un calendario finitos en las features que de verdad hacen que un cliente pague o se quede, y aplazar el resto, para que la primera versión haga bien su trabajo central en vez de hacer muchas cosas mal.