yampa · yampa · 2021–presente
Come strategia di business, ricerca utente e un workflow AI-first hanno rimesso in carreggiata un SaaS in difficoltà.
Staff Product Designer · Design Manager
Contesto
L'utente tipico di yampa è un piccolo imprenditore. Qualcuno che gestisce una panetteria, un negozio, un'agenzia. Il controllo finanziario è uno dei dodici compiti che si contendono la sua attenzione, e quasi sempre perde contro il core business.
Il vero dolore non è la mancanza di tempo. È la prioritizzazione: non riescono a vedere come una routine finanziaria ben gestita cambierebbe la traiettoria della loro azienda, quindi non le dedicano mai l'attenzione necessaria. Il prodotto doveva dimostrare quel valore prima di chiedere impegno.
C'era un secondo livello di complessità. yampa serviva due pubblici molto diversi: i clienti provenienti da 4blue, un'azienda di formazione finanziaria i cui corsi avevano già reso visibile il dolore, e gli utenti del mercato aperto, che arrivavano con una consapevolezza molto più bassa. Stesso prodotto, due punti di partenza completamente diversi nel percorso.
Fase Uno — Strategia di Business
Quando sono entrato, yampa era completamente dipendente dalla società madre, con un modello di prezzo che non scalava.
Prima di toccare qualsiasi schermata, ho lavorato con il CEO sul business stesso. Abbiamo introdotto un modello di abbonamento a livelli, progettato attorno a quanta guida ogni segmento avesse davvero bisogno. Gli utenti con maggiore consapevolezza potevano fare da soli. Quelli con minore consapevolezza avevano bisogno di più accompagnamento, ed erano disposti a pagarlo.
Il pricing è design. Il modo in cui un prodotto si fa pagare plasma come le persone lo usano, cosa si aspettano da esso e se restano. I ricavi sono cresciuti significativamente senza un aumento proporzionale degli abbonati.
Fase Due — yampa 2.0 e la decisione mai presa
Il 2.0 era una ricostruzione completa. Nuova esperienza, nuova architettura, mobile-first.
Abbiamo fatto la ricerca come si deve. Decine di interviste. Abbiamo mappato due profili principali: imprenditori per opportunità, che avevano ereditato l'azienda o scelto un settore che amavano, e imprenditori per necessità, che avevano avviato un'impresa perché non avevano altra scelta. In entrambi i gruppi, le realtà più grandi avevano di solito una persona dedicata alle finanze. Le più piccole, la maggioranza, facevano tutto da sole.
I test di usabilità hanno rivelato il nostro punto cieco: gli utenti disposti a partecipare erano quasi sempre clienti 4blue. Il nostro campione di ricerca era sbilanciato verso il pubblico che già capiva il valore.
Poi è arrivata la decisione mai presa. Il prodotto doveva scegliere: costruire per il cliente 4blue, più avanti nel percorso, o per l'utente del mercato aperto, che aveva bisogno prima di essere convinto.
Ho sollevato la questione ripetutamente. Ho presentato i dati di segmentazione, spinto per una decisione nelle product review, e perso quella battaglia più di una volta. Il focus continuava a spostarsi tra i due pubblici, e ogni pivot diluiva un po' di più la personalità del prodotto, finché non si è connesso con nessuno dei due.
Col senno di poi, avrei dovuto spingere più forte e prima, quando il costo della scelta era ancora basso. Anche questo è su di me. Dopo due anni di lavoro, una settimana prima del lancio, il 2.0 è stato cancellato per debito tecnico critico. L'indecisione ci era costata il tempo di cui le fondamenta tecniche avevano bisogno.
Fase Tre — La Ricostruzione AI-First
Perdere due anni di lavoro obbliga alla chiarezza. Non potevamo permetterci un altro ciclo di due anni, quindi ho cambiato il modo stesso di lavorare.
Ho introdotto un workflow AI-first: ragiono sul problema con Claude prima di aprire Figma. Intento, casi limite, specifiche. Poi progetto, e costruisco io stesso i componenti React con Claude e Cursor, rilasciando direttamente nel repository. Nessun handoff. Chi progetta è la stessa persona che rilascia.
Non è prototipazione con l'AI. È codice di produzione: la nuova home (la schermata nell'hero qui sopra), l'intero modulo di flusso di cassa, la lista dei movimenti, la navigazione. Ho progettato e implementato tutto io.
Per dare una scala: la sola nuova home avrebbe richiesto almeno un mese di andirivieni nel vecchio processo. Lavorando così, ci sono voluti tre giorni.
L'intero frontend è stato ricostruito in due mesi. Il ciclo design-produzione si è ridotto del 70%, e le decisioni di design hanno smesso di morire nella traduzione.
Impatto
Oltre ai numeri: il design system è stato adottato da tutto il team di engineering, e l'event tracking è stato implementato su tutto il prodotto, così le decisioni venivano da dati di attivazione, adozione e churn invece che da opinioni.
La crescita dell'MRR ha avuto molti padri: vendite, marketing e timing di mercato hanno fatto la loro parte. Ciò che possiedo direttamente: l'architettura del pricing, l'esperienza di prodotto e la velocità di consegna che ha reso possibile l'iterazione.
Persone
Molte persone sono passate da questo progetto. Alcune sono rimaste abbastanza a lungo da crescere con esso — e quella crescita è stata la parte migliore del lavoro.
Lauren, Silas e Matheus si sono presentati ogni giorno e sono diventati collaboratori più capaci e resilienti attraverso ogni pivot e nuovo inizio. Guardare quella evoluzione valeva più di qualsiasi lancio.
Bruno e Rapha hanno mantenuto la direzione strategica nei momenti più difficili. Le decisioni non erano sempre facili, ma venivano sempre prese.
A tutti quelli che stanno ancora costruendo yampa — buona fortuna con ciò che verrà.
Apprendimenti
Un prodotto che non sceglie il suo utente finisce per non essere scelto da nessuno. Il 2.0 non è fallito per il design o per l'engineering. È fallito perché una decisione strategica è stata rimandata finché non è stato troppo tardi. Ora spingo per quella decisione dal primo giorno, anche quando è scomodo.
La ricerca segue la stessa regola: se i partecipanti disponibili vengono tutti da un solo segmento, non stai imparando sul tuo mercato. Stai confermando il tuo bias.
E la velocità ha cambiato significato per me. Con l'AI nel workflow, il compromesso tra veloce e rifinito è crollato. Il collo di bottiglia non è più costruire. È decidere cosa merita di essere costruito.
Vuoi parlare di come questo workflow potrebbe funzionare per il tuo team?
Scrivimi →
