Priorización MoSCoW:80 ideas de funciones, construye 5

Tienes 80 ideas de funciones: 50 tuyas y 30 más que sugirieron tus usuarios. La priorización MoSCoW (Must have, Should have, Could have, Won't have) reduce esas 80 ideas a las 5 funciones o menos que realmente ponen a prueba tu hipótesis. Todo lo demás es una distracción, y la mayor parte pertenece al grupo de lo que no se construye.

Además de tus 80, la competencia tiene otras 20 funciones que tú no tienes. No puedes construirlas todas, y no deberías. Este es el marco para recortar sin piedad: la pregunta de prueba de cada categoría, cómo se ven una buena y una mala priorización en plazos reales, y la regla que te impide construir cosas que podrías hacer simplemente a mano.

¿Qué es la priorización MoSCoW para un MVP?

MoSCoW clasifica cada función en uno de cuatro grupos, cada uno con una única pregunta de prueba. Responde con honestidad y la lista de 80 elementos se desmorona sola:

Fíjate en qué suspende la prueba de Must have en ese ejemplo. ¿Niveles de prioridad? Los usuarios pueden reordenar la lista a mano. ¿Categorías y etiquetas? Agradables, no centrales. ¿Tareas recurrentes? Se pueden crear a mano. Una función no es Must have porque sea útil: es Must have porque tu hipótesis no se puede probar sin ella.

No estás construyendo un producto mínimo viable

Estás construyendo un producto mínimo comprobable. Ese cambio de enfoque lo cambia todo, porque ancla cada decisión de priorización a tu hipótesis en lugar de a tu visión. La visión es para la versión 10. Si no puedes enunciar tu hipótesis en una frase, para y arregla eso primero: sale directamente de el trabajo de validación que hiciste antes de decidir construir nada.

Y Won't have es donde vive la disciplina. No es un backlog: es una lista de funciones que decides activamente no construir, cada una con un desencadenante escrito para reconsiderarla: tras 100 usuarios, tras demostrar la V1, o si los usuarios la piden cinco veces o más. Escribir el desencadenante es lo que impide que la función vuelva a colarse en el alcance en la segunda semana.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

La segunda pasada: impacto frente a esfuerzo

MoSCoW te lleva de 80 a una lista corta. La matriz de impacto frente a esfuerzo te lleva a cinco. Puntúa cada función superviviente en dos dimensiones, cuánto ayuda al usuario (1-10) y cuántos días lleva construirla de verdad, y aparecen cuatro cuadrantes:

• Victorias rápidas (alto impacto, poco esfuerzo): son tu MVP.
• Grandes proyectos (alto impacto, mucho esfuerzo): hazlos después de validar, nunca antes.
• Rellenos (bajo impacto, poco esfuerzo): pulido, solo si hay tiempo.
• Pérdidas de tiempo (bajo impacto, mucho esfuerzo): no las construyas nunca: el motor de informes a medida que quizá quieran dos usuarios, la función de IA que nadie pidió, los permisos complejos para casos límite.

Desconfía de tus propios números. Los fundadores subestiman sistemáticamente el esfuerzo y sobrestiman el impacto, así que añade un margen del 50% a cada estimación, cuestiona cada puntuación de impacto de 9 sobre 10 y mantén el tiempo total de construcción por debajo de cuatro semanas.

Hazlo a mano antes de construirlo

Para cada función que sobreviva, hazte una pregunta más: ¿puedo hacer esto manualmente con los primeros 10 usuarios? Si la respuesta es sí, no lo construyas todavía. Envía tú mismo las notificaciones por correo. Monta el informe semanal en una hoja de cálculo. Da la bienvenida a cada usuario en una llamada personal. Factura a mano. Importa tú su CSV.

Empezar a mano lanza más rápido, te enseña lo que los usuarios necesitan de verdad y no lo que dicen que necesitan, y construye relaciones con los primeros usuarios, que son los que más importan. Además es una comprobación de demanda disfrazada: si no te molesta hacer algo a mano para 10 usuarios, ¿por qué construirlo para 1.000? Automatiza solo cuando hayas hecho la tarea manualmente más de 10 veces, te lleve más de 30 minutos cada vez, el patrón sea consistente y los usuarios lo pidan de forma explícita.

Cómo se ven una buena y una mala priorización

La misma idea de gestor de tareas, dos decisiones de alcance. La versión mala: tareas recurrentes, subtareas, etiquetas y categorías, control de tiempo, compartir con equipos, una app móvil, vista de calendario, diagramas de Gantt: 90 días de construcción. La versión buena: crear tarea, fijar fecha límite, marcar como completada, una vista de lista sencilla y un resumen diario por correo enviado a mano a los primeros 10 usuarios: 14 días. Lanzado en dos semanas en lugar de tres meses.

De todos modos, el coste real no son las funciones recortadas, sino el aprendizaje perdido. Un CRM para freelancers pasó de un plan de ocho funciones y 120 días a cinco funciones (añadir contacto, añadir notas, etiquetar estado, búsqueda simple, exportación manual a CSV) y se lanzó en 21 días, y los usuarios revelaron algo que ninguna hoja de ruta predijo: no querían gestión de proyectos en absoluto, querían recordatorios de seguimiento. Un constructor de landing pages recortado de un plan de 60 días a cinco plantillas, texto editable y un formulario básico descubrió que los usuarios querían más plantillas, no personalización. Noventa días extra de construcción habrían sido noventa días construyendo lo equivocado.

Las cinco trampas que vuelven a llenar tu alcance

1. "Pero esto es central para nuestra visión." La visión es para la V10. ¿Qué es central para probar la hipótesis?
2. "Los usuarios lo mencionaron." ¿Qué usuarios? ¿Cuánto les duele? ¿Pagarán? Una persona dispuesta a pagar pesa más que diez sugerencias de "¿no sería genial si…?".
3. "Son solo dos días más." Dos días se convierten en dos semanas con la depuración. Recórtalo; añádelo más tarde si se demuestra que hace falta.
4. "La competencia lo tiene." Ellos tardaron años en construirlo. Tú estás probando, no compitiendo.
5. "No podemos lanzar sin esto." Sí, puedes. ¿Cuál es el mínimo absoluto?

Si tu lista final tiene más de cinco funciones, aún no has terminado de recortar. La mejor función es la que no construyes: cada recorte se lanza más rápido, aprende más rápido, cuesta menos y es más fácil de mantener. Tu objetivo no es construir un producto. Tu objetivo es probar una hipótesis.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Preguntas frecuentes

¿Qué significa MoSCoW?

Must have, Should have, Could have, Won't have. Cada categoría tiene su prueba: Must have significa que la hipótesis no se puede probar sin ello; Should have significa que los primeros usuarios seguirían usando el producto sin ello; Could have significa que nadie dejaría de usar el producto si faltara; la cuarta categoría significa que distrae del valor central y se recorta de forma explícita.

¿Cuántas funciones debe tener un MVP?

Cinco o menos. Si tu lista es más larga, aún no has terminado de recortar. Mantén el tiempo total de construcción por debajo de cuatro semanas, añade un margen del 50% a cada estimación de esfuerzo y cuestiona cada función "imprescindible": la mayoría pertenecen al grupo de lo que no se construye.

¿Cuál es la diferencia entre Must have y Should have?

Una función imprescindible es una función sin la cual no puedes probar tu suposición central: quítala y el experimento está muerto. Una función deseable mejora de forma significativa la experiencia, pero los primeros usuarios seguirían usando el producto sin ella, así que espera hasta después de validar la V1.

¿Cuándo debo automatizar un proceso manual?

Solo cuando lo hayas hecho manualmente más de 10 veces, te lleve más de 30 minutos cada vez, el patrón sea claro y consistente, y los usuarios pidan la automatización de forma explícita. Hasta entonces, el trabajo manual es más barato que el código, y te enseña lo que los usuarios necesitan de verdad.