PoC vs MVP.
Per què els founders se salten el pas equivocat en productes d’IA.
“Necessitem construir un MVP.” És una de les primeres coses que els founders ens diuen quan arriben amb una idea de producte d’IA. De vegades tenen raó. Gairebé mai no la tenen — i les sis setmanes que passen construint el que no toca són la llicó més cara que s’emporten de l’experiència.
La confusió no és de vocabulari. És sobre quina pregunta estàs intentant respondre en realitat. Un PoC i un MVP responen preguntes diferents. Construir-ne un quan necessites l’altre no només malbarata temps — et dona una confiança o un dubte equivocat exactament en el moment en què més necessites claredat.
La majoria de founders se salten el PoC perquè tenen pressa, i acaben reconstruint el MVP perquè se’l van saltar.
1. Les definicions que importen (no les del llibre de text)
PoC — Proof of Concept
La pregunta que respon un PoC: ¿Pot funcionar realment això amb les nostres dades, les nostres restriccions i el nostre nivell de qualitat?
Un PoC és un experiment tècnic. La seva feina és reduir una incertesa específica — no construir un producte. No està pensat per mostrar-lo a usuaris. No està pensat per ser escalable. Està pensat per respondre una pregunta difícil abans de comprometre’t a construir sobre una suposició.
En productes d’IA, el PoC gairebé sempre gira al voltant del model: ¿Pot un LLM extreure la informació correcta d’aquests documents amb una precisió acceptable? ¿Pot un classificador detectar de manera fiable aquest patró en les nostres dades? ¿Retorna un pipeline RAG resultats rellevants en la nostra base de coneixement?
Concepte erroni freqüent: Un PoC que falla no és un fracàs — és el millor resultat possible abans d’haver invertit tres mesos construint sobre una base trencada.
MVP — Minimum Viable Product
La pregunta que respon un MVP: ¿Crea aquest producte prou valor perquè usuaris reals el vulguin?
Un MVP és un producte — la versió mínima que entrega valor real i que es pot posar davant d’usuaris reals. Està pensat per validar l’encaix producte-mercat, no la viabilitat tècnica. Assumeix que la tecnologia central funciona. Se centra en l’experiència, el flux de treball, el valor entregat.
La distinció crítica
- El PoC valida la tecnologia
- El MVP valida el producte
Són apostes diferents. Requereixen feina diferent. Responen preguntes diferents. Tractar-les com la mateixa cosa és com els founders acaben reconstruint el seu MVP des de zero després del llançament.
2. Per què els productes d’IA empitjoren aquesta confusió
En programari tradicional, saltar-se el PoC de vegades està bé. La tecnologia central — bases de dades, APIs, frameworks d’interfície — està provada. El risc està principalment en el producte, no en la implementació.
En productes d’IA, la tecnologia no està provada per al teu cas d’ús específic. Cada producte d’IA té una capa de risc tècnic que el programari tradicional no té:
- El model pot no rendre com s’espera amb les teves dades. Un model que funciona de meravella en datasets de referència pot fallar amb el teu contingut de domini específic. Documents legals, registres mèdics, comunicacions internes, dades de sectors de nínxol — sovint es comporten diferent de les dades d’entrenament amb les quals es va optimitzar el model.
- El llistó de precisió el defineix el teu cas d’ús, no el model. “Prou bo” significa coses diferents. Un chatbot d’atenció al client que s’equivoca el 10% de les vegades pot ser acceptable. Un sistema de monitoratge de compliment que falla en el 10% de les infraccions és una responsabilitat legal. Necessites saber on ets abans de construir el producte al voltant d’això.
- El perfil de cost i latència pot canviar el disseny del producte. Descobrir en fase de MVP que el teu pipeline d’IA costa 0,40€ per consulta — quan el teu model de negoci assumia 0,02€ — no afecta només els marges. Canvia el producte. Necessites saber això en fase de PoC, no després d’haver dissenyat tota la UX al voltant d’això.
En productes d’IA, el PoC no és opcional. El risc tècnic és real i específic, i s’ha de resoldre abans de dissenyar el producte al voltant d’ell.
3. L’error més car: saltar-se directament el PoC
El founder té una idea clara. Ha vist una demo que el convenç. L’equip té energia. Els inversors volen veure tracció. “No tenim temps per a experiments — a construir.”
Així que defineixen l’abast del MVP, contracten l’equip o l’agència, comencen a construir. Tres mesos després, passa una de dues coses:
Escenari A — El model no rendeix prou
El producte està construït. La UX és sòlida. El pipeline està en producció. Però els outputs no són prou bons per a usuaris reals. La precisió és massa baixa. La latència és massa alta. El cost per consulta fa inviable el model de negoci. Ara esteu reconstruint el nucli mentre intenteu mantenir un producte que ja està davant d’usuaris.
Escenari B — El model funciona, però les suposicions de producte eren incorrectes
La tecnologia rendeix bé. Però el que has construït no és el que els usuaris realment necessiten. El flux de treball no encaixa. La interfície té sentit per als enginyers però no per a les persones que fan la feina. Has optimitzat per a l’output tècnic i has oblidat validar l’experiència de producte.
En tots dos casos, un PoC ben definit — dues o tres setmanes, un enginyer, una pregunta clara — hauria tret el problema a la superfície abans que tres mesos de feina anessin en la direcció equivocada.
El cost real no és el temps de reconstrucció.
És la pèrdua de credibilitat amb els primers usuaris, el relat inversor que cal reescriure, i la moral de l’equip que se’n ressent quan tot es llença a la paperera. Hem heretat projectes en l’Escenari A més d’una vegada. La reconstrucció sempre és més difícil que havés començat des de zero.
4. L’altre error: quedar-se encallat en el PoC per sempre
Alguns founders van a l’extrem contrari: fan PoC darrere PoC, refinant el model, perseguint un nombre de precisió més alt, afegint casos extrems. Sis mesos després, tenen un experiment molt bo i cap producte.
Això passa per dues raons:
Perfeccionisme disfressat de diligència
“El model encara no és prou bo.” En la majoria de casos, prou bo per a un PoC vol dir prou bo per aprendre d’usuaris reals. La diferència entre un 82% i un 94% de precisió sovint importa menys que si estàs resolent el problema correcte. Això ho descobreixes amb un MVP, no amb una altra iteració de PoC.
Por al risc de producte
La incertesa tècnica és resoluble — només cal fer un altre experiment. La incertesa de producte requereix posar alguna cosa davant de persones reals i acceptar feedback. Això és més difícil. Alguns equips es queden en mode PoC perquè se sent productiu sense estar exposat.
El senyal que és hora de parar
Pots respondre “sí” a totes dues preguntes:
- Funciona la tecnologia prou bé per provar la proposta de valor central?
- Entenem el perfil de cost, latència i precisió prou com per dissenyar al voltant d’ell?
Si la resposta a totes dues és sí — para d’experimentar. Comença a construir.
5. Com definir l’abast de cadascun correctament
Definir l’abast d’un PoC
Un PoC ben definit té quatre elements:
- Una pregunta específica. No “¿pot la IA ajudar amb els nostres documents?” sinó “¿pot un LLM extreure els cinc camps de dades que necessitem d’aquestes 200 mostres de contractes amb una precisió ≥90%?”
- Un dataset definit. Dades reals, no sintètiques. El PoC només és vàlid si s’executa amb dades que representen el teu entorn de producció real. Idealment 100–500 mostres, suficients per detectar patrons de fallada.
- Un llistó de qualitat clar. Què vol dir “prou bo” per a aquest cas d’ús? Defineix-ho abans d’executar l’experiment, no després de veure els resultats. Això evita moure els pals de la porteria.
- Una caixa de temps. Una a tres setmanes com a màxim. Si no pots respondre la pregunta en aquest termini, la pregunta és massa àmplia. Divideix-la.
El que un PoC no és: una demo, un prototip amb UI, alguna cosa que mostres a usuaris o inversors. És un experiment tècnic intern. El seu output és una decisió: construir o no construir.
Definir l’abast d’un MVP
Quin és el conjunt mínim de funcionalitat que entrega la proposta de valor central a un usuari real en un flux de treball real? Tres preguntes per definir-ho:
- Qui és l’usuari i quina és la feina que intenta fer? No un document de persona — una persona específica fent una tasca específica. “Un responsable de compliment revisant una trucada de vendes per verificar si hi ha infraccions de política”, no “usuaris enterprise en sectors regulats”.
- Quin és el resultat que els faria dir que això té valor? No una llista de funcionalitats — un resultat. “Redueix el temps de revisió de 45 minuts a menys de 5 minuts.” Aquest és el llistó.
- Quina és la superfície mínima per entregar aquest resultat? Tot el que resta és scope creep. Retalla fins que faci mal, llavors retalla una cosa més.
L’output pràctic: un PoC és un notebook, un script, un pipeline de prova. Sense UI. Sense desplegament. Només la resposta. Un MVP és un producte que funciona, desplegat, usat per usuaris reals, mesurat contra el resultat definit.
6. Un exemple real: de PoC a MVP ben fet
Un client fintech necessitava processar documents de sol·licituds de préstec: extreure dades estructurades, validar-les contra requisits, marcar informació que faltava o inconsistent.
La pregunta del PoC: ¿Pot un pipeline basat en LLM extreure els 12 camps de dades requerits d’una mostra de 300 sol·licituds de préstec reals amb una precisió ≥95%, dins d’un pressupost de latència de menys de 8 segons per document?
El que va revelar el PoC:
- Camps amb format estructurat (dates, imports, IDs) → 98% de precisió. Resolt.
- Camps que requereixen interpretació contextual (descripcions de situació laboral, fonts d’ingressos) → 71% de precisió. No suficient.
- Latència: 4,2 segons de mitjana. Dins del pressupost.
- Cost per document: 0,07€. Viable al volum objectiu.
El que va canviar en el MVP gràcies al PoC: Els dos tipus de camp de baixa precisió es van redissenyar: en lloc d’extracció pura, el MVP utilitza un pas human-in-the-loop específicament per a aquells camps. Els altres 10 camps estan totalment automatitzats.
Sense el PoC, el MVP s’hauria construït assumint automatització completa. Hauria llançat amb un 71% de precisió en 2 de 12 camps, la qual cosa hauria fet el producte inutilitzable per als requisits de compliment del client.
Resultat: El PoC va trigar 2 setmanes. Va evitar una reconstrucció de 3 mesos.
7. Un marc de decisió senzill
Si vols el marc resumit en una única referència:
| Pregunta | Construir PoC primer | Anar directament al MVP |
|---|---|---|
| És aquest enfocament d’IA validat amb les teves dades específiques? | No → PoC | Sí → MVP |
| Coneixes el perfil de precisió, cost i latència? | No → PoC | Sí → MVP |
| És la tecnologia central provada en aquest domini? | No → PoC | Sí → MVP |
| Ja has executat un projecte similar? | No → PoC | Sí → MVP |
| El risc principal és l’encaix de producte, no la viabilitat tècnica? | No → PoC | Sí → MVP |
La regla general: si has respost “No” a dues o més preguntes, executa el PoC primer. Trigarà 2–3 setmanes. El MVP serà millor gràcies a això.
Conclusió
Els founders que se salten el PoC no estan sent audaços — estan sent optimistes en la direcció equivocada. El PoC no és un retard. És el que fa que el MVP valgui la pena construir-se.
I els founders que es queden encallats en el PoC no estan sent minuciosos — estan evitant la pregunta més difícil, que és si el producte val la pena construir-se en absolut. Aquesta pregunta només es respon amb un MVP.
Dues o tres setmanes de validació tècnica abans de tres mesos de desenvolupament de producte. Aquest és el trade-off. En productes d’IA, gairebé sempre val la pena.
Construïm junts
Unim experiència i innovació per portar el teu projecte al següent nivell.