La mayoría de proyectos digitales que no funcionan no fallaron por mala ejecución técnica. Fallaron porque construyeron el producto equivocado. O el producto correcto para el usuario equivocado. O el producto correcto demasiado pronto, antes de validar que alguien lo quería de verdad.

El concepto de MVP lleva 15 años en el vocabulario de cualquier empresa que hace producto. Pero en la práctica se malentiende sistemáticamente: se usa como sinónimo de "producto pequeño" o "versión barata". Y no es eso.

"Un MVP no es una versión pequeña de tu producto final. Es el experimento más simple que puede validar o refutar tu hipótesis de negocio."

Antes de construir: escribe la hipótesis

El error más común es empezar con features. "Necesitamos un dashboard, un sistema de notificaciones, onboarding automatizado y una API para integraciones." Todo eso puede ser correcto, pero no es el punto de partida.

El punto de partida es una hipótesis. Y tiene una forma específica:

Formato de hipótesis

"Creemos que [tipo de usuario] tiene [problema específico]. Lo resolveremos con [solución concreta]. Sabremos que funciona si [métrica] llega a [umbral] en [plazo]."

Ejemplo real: "Creemos que los responsables de compras de PYME tienen dificultad para hacer seguimiento de presupuestos aprobados entre departamentos. Lo resolveremos con un tablero compartido con alertas de desviación. Sabremos que funciona si el 40% de los usuarios activos lo usan al menos 3 veces por semana al cabo de un mes."

Fíjate en lo que hace esta hipótesis: define el usuario, el problema, la solución y la métrica de éxito antes de escribir una sola línea de código. Si no puedes escribir esto en un párrafo, todavía no sabes lo que estás construyendo.

La trampa de la matriz impacto/esfuerzo

La mayoría de equipos priorizan features con una matriz impacto/esfuerzo. Es útil, pero tiene un fallo de diseño: no incluye la variable más importante.

La variable que falta es: ¿esta feature valida la hipótesis central del producto?

Una feature puede tener alto impacto y bajo esfuerzo y aun así ser la equivocada para el MVP si no ayuda a responder la pregunta fundamental. El dashboard de analytics puede ser fácil de construir y los usuarios pueden pedirlo con insistencia, pero si tu hipótesis central es sobre si los usuarios completan el flujo principal, un dashboard de analytics no te dice nada.

3 meses Tiempo máximo razonable para un MVP bien definido. Si dura más, el scope se ha disparado.
1 trabajo La regla del "un trabajo": qué puede hacer bien un usuario con esta versión. Solo uno.
50k€ Presupuesto orientativo de referencia. Más sin hipótesis validada es apuesta, no inversión.

La regla del "un trabajo"

Hay una pregunta que limpia el scope mejor que cualquier matriz de priorización:

¿Qué un usuario puede hacer bien con esta versión?

Solo uno. Si la respuesta incluye un "y también", tienes demasiado scope. El MVP debe hacer una cosa tan bien que el usuario vuelva por ella. Todo lo demás puede esperar.

Ejemplos de "un trabajo" bien definido:

  • Crear un presupuesto de proyecto y compartirlo con un cliente para recibir aprobación.
  • Ver cuánto tiempo ha dedicado el equipo a cada cliente esta semana.
  • Publicar una oferta de trabajo y recibir candidaturas en un único lugar.

Fíjate: no son funcionalidades. Son trabajos completos con usuario, acción y resultado. Si no puedes describir el MVP de esta manera, construirás un sistema de features sin cohesión que no sirve a nadie del todo bien.

"El scope del MVP no lo define lo que crees que necesita el usuario. Lo define lo que necesitas aprender para saber si el negocio funciona."

El MVP no tiene por qué ser software

Uno de los errores más caros es asumir que el MVP tiene que ser un producto funcionando. En muchos casos, la hipótesis se puede validar antes de escribir una sola línea de código.

Dos técnicas que funcionan bien:

  • Wizard of Oz. El usuario cree que está usando un sistema automatizado, pero detrás hay una persona haciendo el trabajo manualmente. Sirve para validar si el usuario realmente usa el flujo antes de construirlo. Lo usó Zappos para validar el modelo de e-commerce de zapatos sin tener stock propio.
  • Concierge MVP. Haces el trabajo de forma manual y personalizada para los primeros usuarios, sin automatizar nada. El objetivo no es escalar: es aprender qué hace falta de verdad. Si el usuario no está dispuesto a pagar por el servicio manual, tampoco pagará por el producto automatizado.

Estas aproximaciones no siempre aplican — depende del tipo de producto y del mercado. Pero antes de construir, vale la pena preguntarse: ¿hay alguna forma de validar la hipótesis sin código?

Métricas de aprendizaje vs. métricas de vanidad

Una vez lanzado el MVP, la tentación es medir lo que es fácil de medir: usuarios registrados, visitas, descargas. Estas son métricas de vanidad: crecen bien en una presentación, pero no te dicen si el producto funciona.

Las métricas de aprendizaje miden comportamiento real en relación a tu hipótesis:

  • Retención semana 2. De los usuarios que se registraron, cuántos volvieron la semana siguiente. Si es inferior al 20%, el producto no resuelve nada urgente.
  • Completado del flujo principal. Qué porcentaje de usuarios llega al final del "un trabajo" que define el MVP. Si es bajo, hay fricción en el camino o el problema no era tan urgente.
  • Frecuencia de uso. ¿Cuántas veces a la semana usa el producto el segmento que más te interesa? Si el caso de uso es diario pero el producto se usa una vez a la semana, algo falla.
  • NPS cualitativo. No el número: las respuestas abiertas de los que dan 9-10 y los que dan 1-3. Los extremos te dicen la verdad.
Errores frecuentes

Señales de que el scope se está disparando

Hay patrones que se repiten en proyectos donde el MVP acaba siendo un producto de 12 meses:

  • "Necesitamos roles y permisos desde el principio." En el 90% de los casos, en el MVP tienes un solo tipo de usuario. Los roles vienen cuando tienes equipos usando el producto.
  • "El cliente ya ha pedido integraciones con su ERP." Una integración en el MVP es casi siempre scope creep. Los clientes piden integraciones con cualquier producto; no significa que las necesiten para usar el tuyo.
  • "Necesitamos que sea multi-idioma desde el día 1." Si no tienes ni un cliente, el idioma es el menor de tus problemas.
  • "Hay que hacer el diseño muy bien antes de lanzar." El diseño importa. Un MVP con UI descuidada es contraproducente. Pero "muy bien" no significa "completo". Significa claro y funcional.

El momento de expandir el scope

El MVP ha cumplido su función cuando tienes respuesta empírica a la hipótesis. No cuando "funciona bien", sino cuando tienes datos que dicen: el usuario X hace Y de forma Z con una frecuencia que justifica seguir invirtiendo.

En ese momento, y solo en ese momento, tiene sentido ampliar scope, añadir features y pensar en integraciones. Antes es construir sobre suposiciones.

¿Quieres aplicar esto?

Ayudamos a equipos a definir qué construir en la primera versión de su producto digital: hipótesis, alcance, métricas y decisiones de make-vs-buy. Sin masterclasses de metodología, con el criterio de haber pasado por esto varias veces.

Hablemos →