am tăiat o aplicație de la 28 la 9 funcționalități

Toți fondatorii cu care lucrăm vin cu o listă lungă. Nu pentru că greșesc, ci pentru că lista îi liniștește: dacă am tot, nu am uitat nimic, deci produsul nu poate să eșueze. În practică se întâmplă invers. Cu cât pui mai multe la lansare, cu atât amâni mai mult ziua în care un om real îți spune dacă produsul merită.

Fiecare funcționalitate în plus costă de trei ori: o construiești, o testezi și apoi o întreții la fiecare actualizare de iOS și Android. Și mai costă ceva ce nu se vede pe deviz, îți toacă atenția. Când ai 28 de lucruri de făcut, niciunul nu e bun cu adevărat. Când ai 9, le poți face pe toate impecabil.

Întrebarea corectă nu e «ce ar fi frumos să aibă aplicația», ci «fără ce anume omul nu poate folosi aplicația deloc». Aproape tot ce rămâne după a doua întrebare e zgomot pe care îl plătești cu timpul tău.

Un fondator a venit la noi cu un plan de produs mobil și 28 de funcționalități pe care voia să le lanseze deodată. Le-am pus pe toate pe masă și am întrebat, pentru fiecare: dacă lipsește, omul tot poate face lucrul principal pentru care a descărcat aplicația? Pentru 19 dintre ele răspunsul a fost da.

Am lansat cu 9 funcționalități. Cele 19 tăiate nu au dispărut, au intrat într-o listă de așteptare, ca să le adăugăm doar dacă le cer utilizatorii. Aici e partea care contează: în primele 4 luni, niciuna dintre cele 19 funcționalități tăiate nu a fost cerută de un utilizator real. Niciuna.

Asta înseamnă că fondatorul ar fi cheltuit luni de muncă și o grămadă de bani construind lucruri pe care nimeni nu le-a căutat. În loc de asta, a ajuns mai repede pe piață, cu un produs curat, și a putut investi tot efortul în cele 9 fluxuri care chiar erau folosite zilnic.

Tăierea nu e pe ghicite și nici «hai să scoatem ce e greu». Trecem fiecare funcționalitate prin câteva întrebări concrete, în această ordine:

Regula simplă pe care o repetăm: orice funcționalitate care nu trece de prima întrebare nu intră la lansare, indiferent cât de mult ți-o dorești.

Un MVP nu e o versiune ciuntită și urâtă a produsului final. E cel mai mic produs care rezolvă complet o singură problemă, suficient de bun încât omul să revină a doua zi fără să fie nevoie să-l convingi.

Diferența e subtilă, dar schimbă tot. Un MVP prost are 9 funcționalități făcute pe jumătate. Un MVP bun are 9 funcționalități pe care le poți arăta fără să-ți ceri scuze. Calitatea nu se taie niciodată; numărul de funcționalități, aproape mereu.

În experiența noastră, zona sănătoasă pentru o aplicație mobilă la lansare e undeva la 5-9 fluxuri esențiale. Sub 5 rămâi de obicei cu o demonstrație, nu cu un produs. Peste 10-12 începi deja să construiești lucruri pe care nu le-a cerut nimeni.

Pentru că produsul a pornit mic, fondatorul a avut timp și energie să facă singurul lucru care chiar contează la început: să vorbească cu oamenii. A dus aplicația direct la cei cărora le rezolva o problemă reală, a ascultat ce-i deranjează și a reparat repede, pentru că nu avea 28 de lucruri de întreținut în paralel.

Așa a ajuns la 340 de utilizatori activi cu 0 lei cheltuiți pe reclame. Nu pentru că reclamele sunt rele, ci pentru că reclamele plătite pe un produs nevalidat doar te ajută să arzi bani mai repede. Întâi validezi că oamenii rămân, apoi pui benzină pe foc.

Validarea unui produs fără bani de ads e perfect posibilă atunci când ținta e clară și produsul e mic destul cât să-l poți îmbunătăți săptămânal. E mai lent decât o campanie, dar îți dă ceva ce reclamele nu îți dau: certitudinea că ai construit ceva ce oamenii vor.

Nu e un noroc punctual. fitazi.app, aplicația de fitness pentru iOS și Android pe care am construit-o, a depășit 5.000 de utilizatori în România folosind exact aceeași disciplină: pornește de la fluxul principal, livrează-l impecabil, adaugă restul doar când datele o cer.

Diferența dintre un produs care prinde și unul care moare în store rareori ține de câte funcționalități are. Ține de cât de bine face puținul cu care a pornit. Asta vedem proiect după proiect, fie că e un app de rezervări mobile, un produs de fitness sau un MVP la prima lui lansare.

Tehnic, le poți avea pe amândouă de la început, construim oricum cross-platform, așa că o singură bază de cod ajunge și pe iOS, și pe Android. Întrebarea reală nu e tehnică, ci de prioritate: unde sunt primii tăi utilizatori?

Dacă publicul tău e clar pe o singură platformă, poți lansa întâi acolo, înveți din utilizare reală și aduci a doua platformă fără presiune. Dacă piața ta e amestecată, cum e în România, are sens să fii pe ambele de la lansare. Important e să nu dublezi efortul de mentenanță înainte să știi că produsul merită.

Dacă vorbești cu un studio sau cu un developer și acceptă lista ta de 28 de funcționalități fără să clipească, e un semn prost. Un partener bun de produs te contrazice înainte să scrie prima linie de cod, pentru că banii și timpul tăi îl interesează la fel de mult ca ai lui.

Cere-le să-ți spună ce ar tăia și de ce. Cere un scoping de produs cu priorități clare, nu doar o estimare de ore. Cere un plan de lansare, nu doar livrarea în store. La noi asta înseamnă strategie de produs, design de produs și strategie de lansare puse cap la cap, decidem ce merită construit înainte să începem și rămânem alături până crește.

Dacă pleci cu un singur lucru din articolul ăsta: lansarea bună nu e cea cu cele mai multe funcționalități. E cea care ajunge cel mai repede în mâinile unui om real care îți spune adevărul.