Prototipul vs. produsul: cum îți dai seama când aplicația ta creată cu IA e cu adevărat gata

Acum câteva săptămâni, o fondatoare pe care o cunosc a construit o aplicație de programări pentru terapeuți. Tot procesul i-a luat patru zile cu un creator de aplicații cu IA. Face ce are ea nevoie: terapeuții își văd calendarul, clienții pot programa întâlniri, confirmările pleacă pe e-mail. Funcționează.

Se uită la ea de două săptămâni și n-a lansat-o.

Când am întrebat-o de ce, a spus: „Funcționează, dar… nu simt că e gata.”

Am întrebat-o ce ar schimba. A spus: „Nu știu. Asta-i problema.”

Acesta e cel mai greu moment când construiești cu un creator de aplicații cu IA. Lucrul e funcțional, dar există un gol între „funcțional” și „m-aș simți confortabil să cer unor oameni reali să folosească asta”. Înțelegerea acelui gol — și știința pe ce parte a lui te afli de fapt — face diferența între a lansa și a rămâne blocat pe vecie în faza vocii din capul tău.

Ce înseamnă de fapt „gata”

Iată distincția care contează: un prototip e ceva ce folosești ca să testezi o idee. Un produs e ceva ce folosești ca să rezolvi o problemă.

Aplicația de programări pentru terapeuți e un prototip. Dovedește că ideea funcționează. Un terapeut ar putea-o folosi. Dar sunt șaptesprezece lucruri mărunte care o fac să pară neșlefuită:

E-mailurile de confirmare sunt seci. Fără logo, fără branding personalizat, text generic.
Anulările nu trimit notificări. Clienții pur și simplu nu se prezintă.
Nu există o listă de așteptare dacă un terapeut e complet ocupat.
Fluxul de înscriere nu colectează specializările terapeutului, așa că nu există nicio modalitate de a filtra după tipul de practică.
Nu se trimite niciun e-mail de reamintire cu 24 de ore înainte de întâlnire.

Niciunul dintre aceste lucruri nu strică aplicația. Toate o fac pe un terapeut real să gândească: „Asta pare ceva ce am pus la un loc într-un weekend, nu ceva pentru care cineva îmi cere bani.”

Senzația aceea e reală și contează. Un prototip rezolvă problema în teorie. Un produs o rezolvă în practică, pentru omul real care îl folosește.

Trei întrebări care despart prototipul de produs

Iată partea grea: nu poți ști tot ce lipsește. Nici creatorul tău cu IA nu poate ști. Așa că ai nevoie de trei întrebări rapide ca să-ți dai seama pe ce parte a liniei te afli.

1. Ai folosi tu însuți asta ca să-ți rezolvi propria problemă?

Asta e o întrebare sinceră, pentru că trebuie chiar să trăiești cu propriul produs.

Dacă ești fondatorul acelei aplicații de programări pentru terapeuți, ai folosi-o ca să-ți programezi propriile ședințe de terapie? Nu „ai putea”—ai folosi-o chiar în loc de un șir de e-mailuri sau de un Google Doc partajat?

Dacă răspunsul e nu, nu ești gata. Știi exact ce nu e în regulă—o simți de fiecare dată când deschizi aplicația. Dacă răspunsul e da, ești mai aproape.

Fondatoarea pe care am menționat-o a trecut prin propria înscriere ca terapeut. S-a blocat la formular (cerea prea multe informații înainte de a o lăsa să programeze). A văzut e-mailul de confirmare și i s-a părut amatoricesc. A început să se gândească la cum și-ar primi terapeutul ei e-mailul și dacă ar ajunge în spam.

Nu-și folosea propriul produs așa cum ar face-o un client plătitor. Când a făcut-o, a găsit zece lucruri de reparat.

2. L-ai arătat la trei oameni care nu ești tu?

Să vorbești cu utilizatori potențiali e mai greu decât să construiești, iar cei mai mulți fondatori sar peste asta pentru că vor să surprindă oamenii la lansare. E o greșeală.

Nu ai nevoie de un focus grup. Ai nevoie de trei oameni similari cu cine crezi că e clientul tău. Pentru aplicația terapeuților, asta înseamnă trei terapeuți adevărați.

Iată ce cauți: unde se încurcă? Unde ezită? Ce întreabă? Nu „ce părere au despre ea?” (oamenii sunt prea drăguți). Cere-le să facă efectiv lucrul—să programeze o întâlnire, să trimită un e-mail de confirmare, să anuleze ceva.

Când fondatoarea și-a arătat aplicația pentru terapeuți la trei terapeuți, doi dintre ei au întrebat: „Pot să-mi setez reguli pentru când sunt disponibilă? Gen, primesc clienți noi doar joia și nu suprapun programări înainte de ora 14.” Aplicația avea un calendar, dar nu reguli. Construise prototipul pentru cum credea ea că funcționează programarea, nu pentru cum lucrează de fapt terapeuții.

Asta e informație de produs. N-ai fi putut ghici asta dintr-o specificație.

3. Ce s-ar strica dacă ai da asta la zece utilizatori reali?

Asta e cea mai grea întrebare, pentru că îți cere să te gândești serios la cazurile-limită.

Pentru aplicația terapeuților:

Ce se întâmplă dacă un client încearcă să programeze două întâlniri în același timp? (Aplicația nu verifică.)
Ce se întâmplă dacă un terapeut anulează o întâlnire? Clienții sunt notificați automat? (Nu.)
Ce se întâmplă dacă adresa de e-mail a unui client e greșită? Există o modalitate de a o corecta fără a o lua de la capăt? (Nu.)
Ce se întâmplă dacă un terapeut are o zi de boală și trebuie să-și închidă calendarul pentru o săptămână? (Ar trebui să șteargă manual fiecare întâlnire.)

Astea nu sunt bug-uri. Aplicația nu se prăbușește. Dar sunt zgârieturi mici. Cu zece utilizatori reali și cazuri-limită reale, le vei lovi pe toate în prima săptămână.

Un produs gestionează cazurile-limită. Nu pe toate—unele lucruri pot aștepta. Dar cele care se întâmplă în primele două săptămâni cu utilizatori reali, alea trebuie să funcționeze.

Cum decizi: testul în trei straturi

Folosește-l ca să-ți dai seama unde te afli:

Stratul 1: fluxul principal — Funcționează drumul fericit? Poate un utilizator să facă lucrul principal pentru care e proiectată aplicația ta?

Pentru aplicația de programări pentru terapeuți: da. Cineva se poate înscrie, programa o întâlnire, primi o confirmare. Funcționează.

Stratul 2: cazuri-limită din utilizarea reală — Ai arătat-o la trei utilizatori adevărați. Au lovit ceva pentru care nu ai construit? S-au încurcat undeva?

Pentru aplicația de programări pentru terapeuți: da. Cei trei terapeuți voiau disponibilitate bazată pe reguli. Unul s-a încurcat pentru că e-mailul de confirmare arăta prea generic. Unul a încercat să șteargă în bloc întâlnirile și n-a putut.

Stratul 3: șlefuire și profesionalism — Simți că îți pasă? Sau pare că ai cârpit-o la un loc?

Pentru aplicația de programări pentru terapeuți: pare cârpită. E-mailurile de confirmare sunt seci. Nu există branding personalizat. Nu există niciun mesaj de eroare dacă ceva merge prost, așa că, dacă se strică ceva, utilizatorul habar n-are ce s-a întâmplat.

Iată regula:

Toate trei straturile funcționează? Ești un produs. Lansează-l.
Straturile 1 și 2, dar nu 3? Ești gata 80%. Petrece o zi pe șlefuire.
Stratul 1 funcționează, straturile 2 și 3 nu? Ești un prototip. Nu lansa încă.
Stratul 1 nu e solid? Nu ești gata. Continuă să construiești.

Aplicația terapeuților era blocată la granița dintre Stratul 1 și Stratul 2. Fluxul principal funcționa, dar terapeuții reali au găsit-o cu piese lipsă. Așa că fondatoarea avea o alegere: să mai petreacă o săptămână cu creatorul ei cu IA adăugând funcțiile de care terapeuții chiar au nevoie, sau să lanseze cu ce avea și să le adauge mai târziu.

(Le-a adăugat. A durat trei zile. Acum e un produs.)

Lucrul care face asta greu

Motivul pentru care atât de mulți fondatori se blochează aici e că a construi e distractiv, iar a lansa e înfricoșător.

A construi e o conversație cu instrumentul tău cu IA. Ai o idee, o descrii, instrumentul o execută. Există o buclă de feedback care durează minute. A lansa e altceva. Apeși publică și, dacă ceva e greșit, oamenii reali află. Nu există a doua șansă.

Așa că găsim motive să nu lansăm. „Nu e suficient de șlefuit.” „Ar trebui să adaug încă o funcție.” „Și dacă fonturile sunt greșite?” Iar șase săptămâni mai târziu, tot stai pe ceva ce funcționează, dar care nu pare gata, și te-ai convins că e din cauza fonturilor.

Nu e din cauza fonturilor.

De obicei e pentru că n-ai petrecut timp cu un utilizator real, sau ai construit ceva care avea sens în capul tău, dar care nu se potrivește chiar cu felul în care lucrează oamenii reali. Asta se poate repara. Cere doar să recunoști că nu știi ce nu știi, și apoi să mergi să vorbești cu cineva care știe.

Lista de verificare a pregătirii pentru lansare

Folosește-o. E scurtă și sinceră.

Am folosit-o eu însumi ca să fac sarcina reală și a funcționat (nu într-un mod de demo, ci chiar).
Am arătat-o la trei oameni care chiar ar folosi-o și am reparat lucrurile care îi încurcau.
Fiecare eroare care se poate întâmpla are un mesaj care îi spune utilizatorului ce să facă (nu „eroare”, ci îndrumare reală).
Aș fi în regulă dacă asta ar fi ultima versiune pentru șase luni (adică: e suficient de completă cât să fie utilă chiar dacă n-o mai ating niciodată).
Sunt mai entuziasmat de ce voi învăța de la utilizatorii reali decât sunt de a adăuga mai multe funcții în gol.

Dacă poți bifa toate cele cinci căsuțe, ești gata. Lansează.

Dacă nu poți, nu lansa. Dar fii precis în privința motivului. „Nu pare gata” nu e un motiv. „Terapeuții reali au nevoie de reguli de disponibilitate și încă nu am construit asta” e un motiv. Asta e acționabil. Asta se poate repara. Asta e diferența dintre a fi blocat și a fi pe un drum.

Fondatoarea aplicației pentru terapeuți a lansat-o ieri. Are primul ei client plătitor. Produsul nu e perfect, dar e real, iar clientul ei deja îi spune ce să construiască în continuare. Atunci știi că ești gata: nu când aplicația e perfectă, ci când ești pregătit să afli ce înseamnă de fapt „perfect” pentru oamenii care o folosesc.