Priorizando Features: MoSCoW y Más
La trampa del “y también...”
El mayor enemigo de un MVP es agregar “solo una feature más”. Cada feature adicional multiplica el tiempo de desarrollo y reduce el foco en validar lo esencial.
El método MoSCoW
MoSCoW es un framework de priorización que divide las features en 4 categorías claras. El nombre viene del acrónimo:
Must Have (Debe tener)
Sin esto, el producto no funciona. Son los requisitos no negociables.
Ejemplo: En Uber, la feature de solicitar un conductor es Must Have.
Should Have (Debería tener)
Importante pero no crítico. Mejora significativamente la experiencia.
Ejemplo: En Uber, ver la foto del conductor es Should Have.
Could Have (Podría tener)
Nice to have. Solo si sobra tiempo y recursos.
Ejemplo: En Uber, compartir tu viaje en tiempo real es Could Have.
Won't Have (No tendrá)
Explícitamente fuera del alcance del MVP. Para versiones futuras.
Ejemplo: En el primer Uber, programa de lealtad era Won't Have.
Regla de oro para MVPs
Tu MVP solo debe incluir los Must Have. Si algo es “Should Have”, probablemente puedes lanzar sin él y agregarlo basándote en feedback real.
Matriz de Valor vs. Esfuerzo
Otra técnica poderosa para priorizar. Evalúa cada feature en dos ejes:
Alto valor, bajo esfuerzo
¡Hazlo primero!
Alto valor, alto esfuerzo
Planifica bien
Bajo valor, bajo esfuerzo
Si sobra tiempo
Bajo valor, alto esfuerzo
¡Evitar!
Modelo Kano
El modelo Kano clasifica features según cómo impactan la satisfacción del cliente:
Básicas (Must-be)
Esperadas por defecto. Si faltan, hay insatisfacción. Si están, nadie lo nota. (Ej: que la app no crashee)
Performance (One-dimensional)
Más es mejor, linealmente. (Ej: velocidad de carga, espacio de almacenamiento)
Delighters (Attractive)
Sorpresas positivas. Si faltan, no pasa nada. Si están, generan wow. (Ej: animaciones suaves, easter eggs)
Para tu MVP: Básicas + 1-2 Delighters
Asegura que todas las features básicas funcionan bien. Luego agrega 1-2 delighters pequeños que muestren la personalidad de tu producto y generen boca a boca.
Framework RICE
Usado por equipos de producto para scoring cuantitativo de features:
RICE Score = (R × I × C) / E
Reach (Alcance)
¿Cuántos usuarios impacta por trimestre?
Impact (Impacto)
¿Cuánto mejora la experiencia? (0.25 = bajo, 3 = masivo)
Confidence (Confianza)
¿Qué tan seguro estás de tus estimaciones? (50-100%)
Effort (Esfuerzo)
¿Cuántos persona-meses requiere?
Ejemplo práctico: App de recetas
| Feature | MoSCoW | Valor | Esfuerzo | MVP? |
|---|---|---|---|---|
| Buscar recetas | Must | 🔥🔥🔥 | Medio | ✅ |
| Ver ingredientes | Must | 🔥🔥🔥 | Bajo | ✅ |
| Guardar favoritos | Should | 🔥🔥 | Bajo | ✅ |
| Lista de compras | Should | 🔥🔥 | Medio | ❌ v2 |
| Videos paso a paso | Could | 🔥🔥 | Alto | ❌ v3 |
| Red social / followers | Won't | 🔥 | Muy alto | ❌ |
Reglas para priorizar en tu MVP
Máximo 3-5 features core
Si tienes más de 5, probablemente estás construyendo demasiado.
Cada feature debe validar una hipótesis
Si no te ayuda a aprender algo sobre tu mercado, no pertenece al MVP.
Pregunta: “¿Puedo validar sin esto?”
Si la respuesta es sí, probablemente puedes posponerlo.
Won't Have es tan importante como Must Have
Decir “no” explícitamente evita scope creep.
Para recordar
“Si todo es prioridad, nada es prioridad.” La habilidad de decir “no” es lo que separa a los MVPs exitosos de los proyectos que nunca lanzan.
Siguiente paso
En la próxima lección pondrás todo junto con un ejercicio práctico para crear tu hoja de ruta del MVP, definiendo exactamente qué construir en los próximos 30 días.