Quando un POC viene trattato come un MVP — e finisce per diventare, per caso, un MBI

Nel product management, un MBI è un Minimum Business Increment: la più piccola unità di valore che si può consegnare per produrre un risultato di business misurabile.

In questa storia, però, l’acronimo ha assunto un secondo significato, non voluto.

Ciò che era iniziato come Proof of Concept, promosso troppo in fretta a MVP, si è trasformato lentamente in qualcos’altro: un sistema che non consegnava più incrementi di business, ma li bloccava.

Un Minimum Business Increment è diventato, senza che nessuno se ne accorgesse, una Mission-Blocking Infrastructure.

Il cliente

Il cliente gestisce un fashion marketplace in rapida crescita, con una forte cultura imprenditoriale e un chiaro focus sull’execution.

Nella fase iniziale, l’azienda si è affidata a un singolo sviluppatore per costruire il nucleo software. Il sistema gestiva feed prodotto, processing degli ordini e la colla operativa necessaria per tenere in vita il business. I founder erano molto coinvolti e raffinavano i requisiti in modo continuo man mano che il modello evolveva.

In quel momento l’obiettivo non era la purezza architetturale.
Era la velocità.

Costruire in fretta.
Validare il mercato.
Creare il primo vero incremento di business.

E quell’obiettivo è stato raggiunto.

Il sistema è andato live, gli ordini hanno iniziato a scorrere e il business si è dimostrato. Dal punto di vista del product management, l’MVP aveva fatto il suo lavoro.

Il problema non era cosa facesse il sistema.
Era ciò che non era mai stato pensato di diventare.

Il problema

Quando un MVP viene scambiato per una fondazione

Il sistema originale era stato concepito come Proof of Concept. Il suo ruolo era testare assunzioni, non sostenere un carico operativo di lungo periodo.

Una volta portato direttamente in produzione, è diventato di fatto il Minimum Viable Product. Questa transizione è sembrata naturale, persino un successo. Il fatturato cresceva. Le operations giravano.

Ma un dettaglio sottile è stato trascurato.

Un MVP non è un core scalabile.
È uno strumento di apprendimento.

Quando l’azienda è entrata nella prima fase di crescita, nuove funzionalità venivano aggiunte continuamente sulla stessa struttura. Ogni nuovo requisito era un bisogno legittimo—nuovi partner, nuovi workflow, nuovi edge case. Eppure tutto veniva implementato estendendo un core che non era mai stato progettato per evolvere in modo coerente.

Dall’esterno, il valore sembrava ancora in consegna.
Dentro, però, la complessità si accumulava.

A quel punto, il sistema ha smesso di comportarsi come un MVP e ha iniziato ad assomigliare a quello che, in termini di prodotto, avrebbe dovuto essere un MBI: un Minimum Business Increment. Solo che, invece di essere un incremento deliberato e allineato alla strategia, era un incremento accidentale—ottenuto stirando sempre di più la stessa struttura fragile.

Ed è qui che la battuta diventa seria.

L’“MBI” non rappresentava più valore incrementale di business.
Era diventato una Mission-Blocking Infrastructure—un sistema che tecnicamente funzionava, ma che strategicamente vincolava ogni mossa successiva.

La soluzione

Ripristinare il significato di “incremento”

Si è valutata una riscrittura completa.

Ed è stata scartata.

Un refactor completo avrebbe richiesto un investimento iniziale rilevante, lunghi blocchi operativi e un alto rischio di interrompere il business quotidiano. Sostituire il motore fermando l’auto non era un’opzione.

L’approccio si è quindi concentrato sul reintrodurre incrementi intenzionali, sia tecnici che orientati al business.

Riposizionare l’architettura attorno ai futuri MBI

Un nuovo core scalabile è stato progettato e introdotto accanto al sistema esistente. Questo core non era pensato per sostituire subito quello vecchio. Il suo ruolo era diventare la fondazione per tutti i futuri incrementi—veri MBI nel senso del product management.

Sono stati definiti confini chiari. Ownership di dati e responsabilità è stata resa esplicita. L’architettura è stata costruita per evolvere senza destabilizzare ciò che già funzionava.

Reindirizzare la creazione di valore

Da quel momento, ogni nuova funzionalità—ogni nuovo “incremento di business”—è stata implementata esclusivamente sul nuovo core. Al sistema legacy non è stato più permesso di crescere.

Questa singola regola ha fermato subito la deriva architetturale.

Contenere il passato

Il core originale è stato stabilizzato e congelato nello scope. Ha continuato a operare, ma erano consentite solo modifiche correttive. Non ci si aspettava più nuovo valore da lì; non era più parte della roadmap strategica.

Migrare con intenzione, non con ideologia

Le funzionalità esistenti sono state valutate in base al reale impatto di business. Sono stati migrati solo i componenti la cui migrazione avrebbe sbloccato valore significativo o ridotto rischi rilevanti.

Gli altri sono stati deliberatamente lasciati dov’erano.

In termini di prodotto, la migrazione stessa è diventata una sequenza di MBI intenzionali, non una crociata tecnica.

Il risultato

Da MBI accidentali a MBI deliberati

L’impatto è stato visibile nel giro di pochi mesi.

Il lavoro tecnico ha riacquistato prevedibilità. Le conversazioni sulla delivery sono passate da “cosa potrebbe rompersi” a “che valore arriva dopo”. Soprattutto, il sistema ha smesso di riscrivere la strategia attraverso i propri limiti.

Indicatori chiave

L’azienda è tornata a consegnare veri MBI—incrementi progettati per servire il business, non negoziati con la codebase.

Riflessione finale

Un POC può essere fragile.
Un MVP può essere imperfetto.
Un MBI, però, deve essere intenzionale.

Quando gli incrementi vengono consegnati per caso—stirando sistemi oltre la loro natura—smettono di essere incrementi e iniziano a diventare ostacoli.

A volte, l’MBI più pericoloso è quello che consegna valore per abbastanza tempo da convincere tutti che possa farlo per sempre.

La cura non è una riscrittura eroica.
È ridare significato all’evoluzione—un incremento deliberato alla volta.