La diferencia entre una PoC y un MVP (y por qué confundirlos te sale caro)
Así como hay mucha terminología propia del mundo de data + IA que genera confusión (no tenés por qué saber la diferencia entre un data warehouse y un data lake; para eso estamos nosotros), lo mismo ocurre con términos propios de la operatoria de compañías modernas que buscan ser ágiles. Entre ellas, hay dos en particular que suelen generar muchísimos conflictos: la PoC (proof of concept / prueba de concepto) y el MVP (minimum viable product / producto mínimo viable).
Una PoC responde una pregunta / Un MVP resuelve un problema.
La distinción es realmente simple, una vez que sabés qué es lo que estás mirando.
Una prueba de concepto (PoC) existe para responder una sola pregunta: ¿esto se podría hacer? Atención a la conjugación verbal: acá estamos en el terreno del potencial. El objetivo es partir de una parte acotada del problema, intentar resolverlo con los datos reales de los que se disponen (o lo más parecido que haya), y ver si la idea anda o no. En definitiva, es un experimento: no tiene usuarios, muchas veces ni siquiera tiene interfaz, no corre sola, etc. Lo que se busca con esto es, a riesgo de ser obvios, probar el concepto: ver si es factible o si tiene sentido.
Un producto mínimo viable (MVP) responde otra pregunta más compleja: ¿esto funciona en el mundo real? Acá ya hablamos en tiempo presente, sobre algo mucho más sólido y que mira al futuro inmediato. Es un desarrollo que (al menos parcialmente) debe correr en producción, tiene que poder integrarse con los sistemas que ya existen, y se lo tenés que poder dar a alguien que no tuvo nada que ver con todo el proceso de desarrollo de la solución y sea capaz de operarlo. Puesto de forma sencilla, es la forma más chica y reducida posible de algo que efectivamente ya está resolviendo un problema en particular: tal vez no con todas las features que podría tener, pero sí completo en su origen y caso de uso.
Llegado este punto, hay que aclarar que no es que uno es “mejor” que el otro. No es una diferencia de calidad, sino de propósito y función específica: la PoC tiene que demostrar que algo es posible, y el MVP tiene que demostrar que es útil.
El gap entre la PoC y el MVP es donde mueren los proyectos
Acá es donde suelen aparecer los primeros chispazos: la PoC funciona, genera un montón de entusiasmo, y quien recibió este desarrollo pide ponerla en producción. No comprender la diferencia entre ambos conceptos es lo que genera mucho malestar cuando el stakeholder (comprensiblemente ansioso por ver resultados) asume que el paso entre una cosa y la otra es apretar un botón (o peor aún, una cuestión de mera voluntad). Pero lamentablemente, la realidad no siempre es tan sencilla.
Capaz no lo pensaste nunca, pero mirá las diferencias concretas que hay entre una cosa y la otra:
- Ingesta de datos automatizada. En la PoC descargaste un CSV, un JSON, algún tipo de datos, y lo trataste de forma manual. En producción, esos datos tienen que llegar solos, todos los días, sin que nadie haga nada. Y ni hablar de que tienen que llegar limpios, prolijos y listos para usar: nada de andar acomodando cosas ad-hoc.
- Infraestructura. La PoC corrió en la máquina de alguien. Y la frase “pero no puede ser, esto funciona en mi computadora” fue dicha por miles o millones de devs en la historia por una razón: el MVP tiene que correr en algún lado que no sea la máquina de la persona que lo creó.
- Monitoreo. En una PoC, no existe tal cosa como “el error”, en tanto se presupone que se está en fase de validación de una solución. Pero el MVP sí ya está haciendo cosas reales, por lo que cuando inevitablemente algo de error, falle o se rompa, tenés que enterarte lo más pronto posible.
- Reentrenamiento. El modelo de la PoC se entrenó una vez. Pero un MVP seguramente requiera un reentrenamiento o ajustes a medida que los datos vayan cambiando.
Cada uno de esos puntos es trabajo real, con horas reales, que cuesta plata real.
PoC de churn vs. MVP de churn
Para bajarlo aún más a tierra, vamos con un ejemplo bien concreto. Supongamos que alguien nos pide un modelo para predecir qué clientes van a irse de la compañía: ni más ni menos que un clásico modelo de churn.
Si lo que necesitás es una PoC, eso significa agarrar los datos históricos, entrenar un modelo y medir si predice mejor que lo que tenés hoy. Probablemente necesites dos a tres semanas de un data scientist y algún rato libre de algún data engineer que te ayude con un primer dump de datos. Al terminar, vas a tener una notebook de prototipo, un par de métricas, y una respuesta honesta sobre si la idea es factible o no.
Ahora bien, si lo que necesitás es un MVP, eso significa conectar las fuentes de datos, armar un pipeline que corra automáticamente, se encargue de analizar la calidad de los datos, entrenar el modelo, definir umbrales de decisión con el equipo de negocio, construir una interfaz donde alguien pueda ver los resultados, monitorear la performance y definir cuándo y cómo se reentrena. Acá estamos hablando, dependiendo del caso y de la escala, de entre dos y seis meses de trabajo de un equipo con data scientists, engineers, analysts y seguramente alguien con una visión más de producto.
¿Cuál es “un modelo de churn”? Las dos. Pero una cuesta diez veces más que la otra, porque una es una promesa con muchas garantías, pero la otra genera impacto real y tangible.
Y acá está lo que te tenés que llevar de este artículo: si no tenés una conversación franca y honesta sobre cuál de las dos estás comprando antes de arrancar, las chances de que el proyecto termine bien bajan considerablemente.
Cuándo tiene sentido cada uno
No hay uno mejor que el otro: es un tema de timing.
Hacé una PoC cuando:
- No sabés si el problema se puede resolver con los datos que tenés.
- Necesitás convencer a alguien internamente de que vale la pena invertir.
- Querés comparar enfoques antes de comprometerte con uno.
Hacé un MVP cuando:
- Ya sabés que el problema se puede resolver (idealmente porque ya hiciste una PoC y tenés las decisiones y hallazgos bien documentados).
- Hay un usuario real que va a usar esto todas las semanas.
- Tenés presupuesto para construir no solo el modelo sino todo lo que lo rodea.
- Hay alguien interno que va a ser dueño de esto cuando termine.
La pregunta que vale la pena hacer
Antes de arrancar cualquier proyecto de datos o IA, hay una pregunta que debería hacerse en la primera reunión:
¿El objetivo de este proyecto es saber si algo se puede hacer, o que algo funcione en producción?
Si es lo primero, es una PoC. Tiene un alcance, un costo y un timeline. Si es lo segundo, es un MVP. Tiene otro alcance, otro costo y otro timeline. Y si no sabés cuál de los dos necesitás, esa es exactamente la conversación que hay que tener antes de hablar de presupuesto.
