MVP vs MLP

L'MVP era un'idea eccellente, poi mal utilizzata. "Minimum viable product" nasceva per indicare il più piccolo esperimento in grado di testare un'ipotesi. In pratica è diventato un alibi per rilasciare qualcosa di incompleto e spacciarlo per strategia. Il minimum lovable product, MLP, è la correzione: il rilascio più piccolo che le persone vogliono davvero usare, non semplicemente tollerare. Sapere quale dei due vi serve è una decisione di scope, non di filosofia.

La differenza in una riga

Un MVP si chiede: lo useranno almeno? Un MLP si chiede: ameranno la parte che abbiamo costruito? L'MVP testa la domanda di mercato con l'artefatto più grezzo possibile. L'MLP restringe lo scope ma leviga ciò che rimane fino a renderlo genuinamente buono.

Entrambi puntano a fare meno. Divergono su dove tagliare: meno funzionalità oppure funzionalità più approssimative.

Perché l'asticella si è alzata

Quando gli utenti avevano poche alternative, un MVP grezzo poteva vincere per novità. Oggi quasi ogni categoria è affollata, e le persone giudicano un nuovo prodotto confrontandolo con gli strumenti rifiniti che già utilizzano. Una prima impressione sciatta non viene letta come "è ancora in fase iniziale", ma come "non fa per me", e non tornano. In un mercato saturo, l'amabilità è il test di fattibilità.

Quando un MVP è ancora la scelta giusta

Lanciate un vero MVP quando la domanda centrale riguarda il desiderio, non la qualità:

• Non siete affatto certi che qualcuno voglia questo prodotto.
• Il pubblico è composto da early adopter disposti a tollerare imperfezioni pur di accedervi.
• Potete imparare ciò di cui avete bisogno da un gruppo ristretto e indulgente.
• La velocità nel raccogliere un segnale conta più della forza del segnale stesso.

In questo caso, spendere settimane a rifinire qualcosa che nessuno vuole è l'errore costoso da evitare.

Quando puntare a un MLP

Scegliete un MLP quando la domanda è abbastanza chiara ma il mercato è competitivo:

• Gli utenti hanno vere alternative e vi confronteranno con esse.
• La vostra differenziazione è l'esperienza: sensazione d'uso, velocità, design.
• Le prime impressioni sono difficili da ribaltare.
• Il passaparola dipende dal piacere d'uso, non solo dalla funzionalità.

Scope ristretto, esecuzione profonda

La trappola del concetto "amabile" è interpretarlo come licenza di aggiungere funzionalità. È esattamente il contrario. Scegliete meno cose e finitele completamente. Un workflow che funziona senza frizioni vale più di cinque lasciati a metà. Tagliate lo scope finché ciò che rimane può essere genuinamente buono, poi rendetelo tale.

Decidete, poi impegnatevi

Scrivete la domanda unica a cui il vostro lancio deve rispondere. Se è le persone lo vogliono, lanciate un MVP e non over-investite. Se è le persone passeranno a noi, lanciate un MLP e rendete il core loop delizioso. Il rischio concreto è distribuire la cura di un MVP su un numero di funzionalità da MLP: tutto a metà, niente davvero amabile.

In Pykero definiamo ogni lancio attorno all'unica domanda che conta e finiamo ciò che rilasciamo. Se state pianificando un primo lancio, parliamone.