La majoria de projectes digitals que no funcionen no fallen per mala execució tècnica. Fallen perquè construeixen el producte equivocat. O el producte correcte per a l'usuari equivocat. O el producte correcte massa aviat, abans de validar que algú el volia de debò.

El concepte d'MVP fa 15 anys que és al vocabulari de qualsevol empresa que fa producte. Però a la pràctica s'entén sistemàticament malament: es fa servir com a sinònim de "producte petit" o "versió barata". I no és això.

"Un MVP no és una versió petita del teu producte final. És l'experiment més simple que pot validar o refutar la teva hipòtesi de negoci."

Abans de construir: escriu la hipòtesi

L'error més habitual és començar per les features. "Necessitem un dashboard, un sistema de notificacions, onboarding automatitzat i una API per integracions." Tot això pot ser correcte, però no és el punt de partida.

El punt de partida és una hipòtesi. I té una forma específica:

Format d'hipòtesi

"Creiem que [tipus d'usuari] té [problema específic]. Ho resoldrem amb [solució concreta]. Sabrem que funciona si [mètrica] arriba a [llindar] en [termini]."

Exemple real: "Creiem que els responsables de compres de pime tenen dificultat per fer seguiment de pressupostos aprovats entre departaments. Ho resoldrem amb un tauler compartit amb alertes de desviació. Sabrem que funciona si el 40% dels usuaris actius el fan servir almenys 3 cops per setmana al cap d'un mes."

Fixa't què fa aquesta hipòtesi: defineix l'usuari, el problema, la solució i la mètrica d'èxit abans d'escriure una sola línia de codi. Si no ho pots escriure en un paràgraf, encara no saps què estàs construint.

La trampa de la matriu impacte/esforç

La majoria d'equips prioritzen features amb una matriu impacte/esforç. És útil, però té un error de disseny: no inclou la variable més important.

La variable que falta és: aquesta feature valida la hipòtesi central del producte?

Una feature pot tenir molt impacte i poc esforç i continuar sent la equivocada per a l'MVP si no ajuda a respondre la pregunta fonamental. Un dashboard d'analytics pot ser fàcil de construir i molt demanat, però si la teva hipòtesi central és si l'usuari completa el flux principal, aquest dashboard no et diu res.

3 mesos Temps màxim raonable per a un MVP ben definit. Si dura més, l'scope s'ha disparat.
1 feina La regla d'"una feina": què pot fer bé un usuari amb aquesta versió. Només una.
50k€ Pressupost orientatiu de referència. Més, sense hipòtesi validada, és aposta, no inversió.

La regla d'"una feina"

Hi ha una pregunta que neteja l'scope millor que qualsevol matriu de priorització:

Què pot fer bé un usuari amb aquesta versió?

Només una cosa. Si la resposta inclou un "i també", tens massa scope. L'MVP ha de fer una sola cosa tan bé que l'usuari hi torni. La resta pot esperar.

Exemples d'"una feina" ben definida:

  • Crear un pressupost de projecte i compartir-lo amb un client per rebre aprovació.
  • Veure quant temps ha dedicat l'equip a cada client aquesta setmana.
  • Publicar una oferta de feina i rebre candidatures en un únic lloc.

Fixa-t'hi: no són funcionalitats. Són feines completes amb usuari, acció i resultat. Si no pots descriure l'MVP d'aquesta manera, construiràs un sistema de features sense cohesió que no serveix prou bé a ningú.

"L'scope de l'MVP no el defineix el que creus que necessita l'usuari. El defineix el que necessites aprendre per saber si el negoci funciona."

L'MVP no ha de ser necessàriament programari

Un dels errors més cars és assumir que l'MVP ha de ser un producte funcionant. En molts casos, la hipòtesi es pot validar abans d'escriure una sola línia de codi.

Dues tècniques que funcionen bé:

  • Wizard of Oz. L'usuari creu que fa servir un sistema automatitzat, però darrere hi ha una persona fent la feina manualment. Serveix per validar si l'usuari realment fa servir el flux abans de construir-lo. Ho va fer servir Zappos per validar el model d'e-commerce de sabates sense tenir estoc propi.
  • Concierge MVP. Fas la feina de manera manual i personalitzada per als primers usuaris, sense automatitzar res. L'objectiu no és escalar: és aprendre què cal de debò. Si l'usuari no està disposat a pagar pel servei manual, tampoc pagarà pel producte automatitzat.

Aquestes aproximacions no sempre s'apliquen — depèn del tipus de producte i del mercat. Però abans de construir, val la pena preguntar-se: hi ha alguna manera de validar la hipòtesi sense codi?

Mètriques d'aprenentatge versus mètriques de vanitat

Un cop llances l'MVP, la temptació és mesurar allò fàcil: usuaris registrats, visites, descàrregues. Aquestes són mètriques de vanitat: queden bé en una presentació, però no et diuen si el producte funciona.

Les mètriques d'aprenentatge mesuren comportament real en relació amb la teva hipòtesi:

  • Retenció setmana 2. Dels usuaris que es van registrar, quants tornen la setmana següent. Si és inferior al 20%, el producte no resol res urgent.
  • Compleció del flux principal. Quin percentatge arriba al final de la "feina" que defineix l'MVP. Si és baix, hi ha fricció o el problema no era prou urgent.
  • Freqüència d'ús. Quantes vegades per setmana fa servir el producte el segment que més t'interessa? Si el cas d'ús és diari però l'ús real és setmanal, alguna cosa falla.
  • NPS qualitatiu. No el número: les respostes obertes dels que et posen 9-10 i dels que et posen 1-3. Els extrems et diuen la veritat.
Errors habituals

Senyals que l'scope s'està disparant

Hi ha patrons que es repeteixen en projectes on l'MVP acaba sent un producte de 12 mesos:

  • "Necessitem rols i permisos des del principi." En el 90% dels casos, a l'MVP tens un sol tipus d'usuari. Els rols arriben quan tens equips fent servir el producte.
  • "El client ja ha demanat integracions amb el seu ERP." Una integració a l'MVP gairebé sempre és scope creep. Que els clients la demanin no vol dir que la necessitin per fer servir el teu producte.
  • "Necessitem que sigui multiidioma des del dia 1." Si encara no tens ni un client, l'idioma és el menor dels teus problemes.
  • "Cal fer el disseny molt bé abans de llançar." El disseny importa. Un MVP amb una UI descuidada és contraproduent. Però "molt bé" no vol dir "complet". Vol dir clar i funcional.

El moment d'ampliar l'scope

L'MVP ha complert la seva funció quan tens resposta empírica a la hipòtesi. No quan "funciona bé", sinó quan tens dades que diuen: l'usuari X fa Y de la manera Z amb una freqüència que justifica seguir invertint.

En aquell moment, i només en aquell moment, té sentit ampliar scope, afegir features i pensar en integracions. Abans és construir sobre supòsits.

Vols aplicar això?

Ajudem equips a definir què cal construir a la primera versió del seu producte digital: hipòtesi, abast, mètriques i decisions de make-vs-buy. Sense masterclasses de metodologia, amb el criteri d'haver passat per això diverses vegades.

Parlem →