¡Hola, Feriantes!
Algunos equipos digitales funcionan así: surge una idea, la meten al backlog, la estiman… y se lanzan a construir el “proyecto completo”. Nueva funcionalidad, nuevo módulo, nuevo flujo entero. Semanas o incluso meses de trabajo, diseño, IT, releases… para que luego el uso real sea discreto o directamente un fracaso silencioso.
No suele fallar la ejecución técnica, falla el enfoque:
– Se atacan síntomas (“la gente no convierte aquí, añadamos X”) en lugar del problema de fondo.
– Se toman decisiones basadas en suposiciones, no en datos.
– Y cada feature que no aporta valor no solo consume tiempo: quema presupuesto y desmotiva al equipo.
Este artículo de Speero plantea un trabajo previo que ya se hace en ciertos equipos, pero resulta interesante porque lo bautiza de forma explícita: dejar de ir directos al MVP (Minimum Viable Product) y pasar antes por el MCP (Minimum Change Possible).
El MCP introduce una pregunta antes de avanzar con cualquier idea del backlog:
“¿Cuál es el cambio más pequeño, rápido y simple que se puede lanzar para validar la hipótesis clave detrás de esta idea?”
En la práctica, se trata de desacoplar la idea de la solución completa.
Si se quiere un nuevo motor de recomendaciones, en lugar de arrancar un proyecto de meses, se puede empezar con un bloque manual de recomendaciones en la home para un 10% del tráfico.
Si se está valorando una nueva tarifa o plan premium, puede arrancarse con un fake door: mostrar el nuevo plan en la página de precios y, al hacer clic, llevar a un “Próximamente – Apútntate a la lista de espera”. Así se mide interés sin haber construido nada.
Cuando se trabaja así, algo cambia:
Solo se desarrolla en serio aquello que ya ha demostrado potencial con datos reales.
Se reduce el peso de las decisiones por instinto (“esto seguro que funciona”) y cada desarrollo se convierte en una apuesta más calculada.
En el fondo, el MCP actúa como vacuna contra el “hay que sacar esto ya” que tanto presiona a producto, marketing e IT. Primero, el experimento mínimo que prueba la hipótesis. Después, y solo si realmente merece la pena, el proyecto grande.
Cómo podría aterrizarse este enfoque en un equipo:
Las iniciativas del backlog pueden formularse como: Hipótesis → MCP para validarla. Cuando cuesta encontrar un MCP claro, suele ser señal de que la idea aún no está bien definida.
Puede establecerse un umbral de recursos para la validación: por ejemplo, que ningún test inicial supere un sprint ni cierto límite de inversión.
El MCP puede incorporarse a los rituales de equipo: en cada planning, se puede revisar cada iniciativa preguntándose “¿Cuál sería aquí el Minimum Change Possible?” antes de comprometerse con algo grande.
También ayuda tratar como éxito tanto los MCP que validan ideas como los que las descartan rápido: estos últimos evitan dedicar meses a features que nunca debieron construirse.
Si cada proyecto tuviera que pasar primero por su MCP, algunos roadmaps serían más ligeros… y los equipos, menos quemados.
:
