Cum decizi ce feedback de la utilizatori merită construit (și pe care să-l lași să treacă)
Odată ce oamenii încep să-ți folosească aplicația, cererile încep să curgă. Iată o metodă simplă prin care decizi care feedback de la utilizatori merită construit cu creatorul tău de aplicații cu IA, pe care să-l parchezi și pe care să-l refuzi politicos.
Primele câteva săptămâni după ce oamenii încep să-ți folosească aplicația sunt liniștite. Apoi încep mesajele. „Ați putea adăuga un mod întunecat?” „Ar fi grozav să pot exporta în PDF.” „Puteți face butonul albastru?” „Chiar avem nevoie de integrări cu instrumentul pe care îl folosim deja.” Într-o lună ai o listă cu patruzeci de lucruri și un creator de aplicații cu IA care ți le va construi cu plăcere pe oricare dintre ele într-o după-amiază.
Ultima parte e capcana. Când construirea fiecărei funcții e ieftină și rapidă, întrebarea grea nu mai e „pot construi asta?”, ci „ar trebui?”. Gâtul de sticlă se mută din mâinile tale în judecata ta, și nimeni nu-ți dă un ghid pentru asta.
Articolul ăsta e o metodă simplă de a sorta feedbackul primit în trei grămezi — construiește-l, parchează-l, lasă-l să treacă — fără să ai nevoie de o pregătire în product management. Scopul nu e să le spui oamenilor nu. E să te asiguri că lucrurile pe care le construiești sunt cele care chiar îți împing aplicația înainte.
De ce „pur și simplu construiește-l” încetează să mai funcționeze
Pentru primele zece funcții, „construiește pur și simplu orice cere cineva” e o strategie bună. Nu ai destui utilizatori cât să existe opinii contradictorii, iar fiecare funcție face aplicația mai utilă decât lucrul gol care era săptămâna trecută.
Încetează să mai funcționeze cam în momentul în care ai utilizatori reali și diferiți. Un freelancer vrea un lucru, o agenție mică vrea opusul, iar un vizitator de o singură dată vrea ceva ce niciunul dintre ei nu va folosi vreodată. Construiește-le pe toate trei și aplicația ta se transformă într-un sertar de vechituri — plin de lucruri, greu să găsești ceva, greu de cărat. Fiecare funcție pe care o adaugi e o funcție pe care trebuie s-o menții funcțională la nesfârșit, s-o explici utilizatorilor noi și să n-o strici când schimbi ceva în apropiere.
Un creator de aplicații cu IA înrăutățește asta înainte s-o îmbunătățească, pentru că îndepărtează frâna naturală. Când o funcție îi lua unui dezvoltator două săptămâni, te gândeai bine dacă merită cele două săptămâni. Când îi ia creatorului douăzeci de minute, nu te mai gândești deloc — spui pur și simplu da. Costul n-a dispărut. S-a mutat din „timpul de construit” în „greutatea de cărat”, iar greutatea e mai greu de văzut.
Trei întrebări care sortează aproape totul
Când vine o cerere, treci-o prin trei întrebări, în ordine. Majoritatea lucrurilor se sortează singure după primele două.
1. Asta ajută oamenii pentru care am construit aplicația? Ți-ai construit aplicația pentru cineva anume — fotografi de nuntă, antrenori de fotbal pentru copii, gazde de podcasturi independente. O cerere de la unul dintre acei oameni valorează mai mult decât o cerere de la cineva care a nimerit pe acolo și nu va mai reveni niciodată. Dacă o funcție îi ajută pe oamenii tăi de bază să facă lucrul principal pentru care au venit, urcă spre vârf. Dacă ajută un vizitator care nu e cu adevărat utilizatorul tău, coboară spre coadă, oricât de tare ar fi cerut-o.
2. Câți oameni o vor folosi de fapt? Nu „cine a cerut-o” — cine o va folosi. O persoană care cere zgomotos nu e același lucru cu zece oameni care ar beneficia în liniște. Fii sincer aici, pentru că cererile zgomotoase par cereri mari, și de obicei nu sunt. Un indiciu bun: întreabă persoana ce face în loc, în prezent. Dacă are o soluție improvizată și stângace pe care o folosește zilnic, e o nevoie reală. Dacă „probabil ar folosi-o uneori”, e un moft deghizat.
3. Cât mă costă să o car la nesfârșit? Unele funcții sunt ușoare. O nouă opțiune de culoare, o etichetă reformulată, un câmp în plus pe un formular — construiește-o și uită de ea. Unele funcții sunt grele: orice atinge plățile, orice trimite e-mail unor oameni reali, orice adaugă o întreagă secțiune nouă cu propriile reguli. Funcțiile grele nu sunt rele, dar ar trebui să-și merite greutatea trecând primele două întrebări cu loc de manevră.
Cele trei grămezi
Pune întrebările alea și aproape totul aterizează într-unul din trei locuri.
Construiește-l. Ajută oamenii tăi de bază, mai mulți dintre ei îl vor folosi, iar costul de cărat e rezonabil. Astea sunt ușoare. Fă-le și spune-i persoanei care a cerut — oamenii care își văd ideea lansată devin cei mai loiali utilizatori ai tăi și cea mai bună sursă pentru următoarea idee bună.
Parchează-l. Idee bună, dar e devreme, sau o vrea o singură persoană, sau e grea și încă nu ești sigur. Nu spune nu și nu o construi. Notează-o undeva unde chiar te vei uita — o listă simplă, o notiță, un board. Dacă alți trei oameni cer același lucru în luna următoare, tocmai s-a promovat singur în grămada de construit și ți-a spus-o. Parcarea nu e un cimitir; e o sală de așteptare.
Lasă-l să treacă. Nu se potrivește cu ceea ce e aplicația ta, ar servi vreodată o singură persoană, sau ar înrăutăți aplicația pentru toți ceilalți. Astea au nevoie de un nu politicos și sincer. „E o idee chibzuită, dar nu e ceva ce plănuiesc să adaug — iată ce ți-aș sugera în loc” păstrează relația și protejează aplicația. A spune nu e o funcție în sine. Fiecare nu e un da pentru păstrarea aplicației suficient de simplă încât oamenii s-o înțeleagă.
Un mic exemplu
Cineva pe care îl cunoaștem are o aplicație de rezervări pentru profesori de muzică, construită în întregime cu un creator de aplicații cu IA. Într-o săptămână a primit trei cereri: un profesor voia mesaje automate de reamintire pentru elevi, un părinte voia un mod de a vedea toate lecțiile copiilor lui într-o singură vizualizare, iar o persoană voia aplicația tradusă în latină „de amuzament”.
Reamintirile au trecut toate cele trei întrebări — utilizatori de bază, mulți dintre ei se confruntă cu neprezentări, iar mesageria e grea, dar merită. Construit. Vizualizarea pentru părinte era o idee bună de la o singură persoană, așa că a parcat-o; alți doi părinți au cerut-o în trei săptămâni și s-a promovat singură. Traducerea în latină a primit un nu cald. Niciuna dintre acele decizii n-a avut nevoie de o foaie de calcul. Au avut nevoie de trei întrebări și de disponibilitatea de a răspunde sincer la a treia.
Partea pe care nimeni nu ți-o spune
Cel mai greu feedback de gestionat nu sunt ideile proaste. Sunt ideile bune de la oameni care îți plac, pentru o aplicație care nu poate fi totul. Să le lași să treacă pare că dezamăgești persoana. Nu e așa. Cel mai bun lucru pe care îl poți face pentru oamenii care îți folosesc aplicația e s-o păstrezi suficient de focalizată încât să rămână bună la lucrul pentru care au venit.
Data viitoare când se adună cererile, nu deschide mai întâi creatorul tău de aplicații cu IA. Deschide lista, treci fiecare element prin cele trei întrebări și sortează-l într-o grămadă. Construirea e partea ușoară acum. A decide ce merită construit e adevărata slujbă — și e o slujbă pe care o poți face fără să scrii o singură linie de cod.