Cererea de funcție pe care chiar ar trebui s-o construiești (și cum să-ți dai seama)

Știi să spui nu cererilor de funcții proaste. Ai învățat să distingi scope creep-ul de funcțiile de bază. Îți protejezi granițele produsului.

Dar acum ești într-o altă încurcătură: ai o duzină de cereri care trec toate testul. Sunt toate pentru aplicația ta. Sunt toate rezonabile. Sunt toate lucruri pe care utilizatorii tăi chiar le vor. Dar poți construi doar trei dintre ele.

Care trei?

Aici merg prost cele mai multe decizii de produs. Fondatorii le aleg pe cele care sună cel mai impresionant, sau cel mai profitabil, sau pe cele care au venit de la cel mai important client al lor. Uneori au dreptate. De obicei greșesc.

Semnalele care contează

Semnalul 1: Repetiția neprovocată

Dacă trei utilizatori separați cer același lucru fără să vorbească între ei, ăsta e un semnal. Nu s-au coordonat. Tuturor le-a venit pur și simplu ideea. Dacă cinci utilizatori o cer, nu e o coincidență — e o nevoie genuină.

Inversul e important: dacă un utilizator cere și nimeni altcineva nu o face, iar tu o construiești, acum întreții o funcție pe care nimeni altcineva nu o folosește și de care acel utilizator tot s-ar putea să nu fie mulțumit (pentru că ai construit-o ușor greșit).

Numără cererile înainte să construiești. Nu pe cele de la cel mai zgomotos client sau de la cel mai mare client al tău — numără repetiția neprovocată. Doi sau trei utilizatori independenți care cer același lucru e un semnal mult mai puternic decât un client important care cere cinci lucruri.

Semnalul 2: Soluția de compromis contează

Dacă ai utilizatori și ei rămân chiar dacă funcția lipsește, înseamnă că au găsit o soluție de compromis. Poate o fac în afara aplicației tale. Poate o fac manual. Poate folosesc un alt instrument în paralel.

Dar rămân, ceea ce înseamnă că nu au nevoie de funcție ca să-ți folosească aplicația. Au nevoie de ea ca să-ți folosească aplicația mai bine. Asta e diferit de un blocaj.

Funcțiile care contează cel mai mult sunt cele care îi împiedică pe oameni să-ți folosească aplicația deloc. Funcțiile care sunt drăguț de avut sunt cele pe care oamenii le ocolesc.

Fii atent la care cereri sunt blocaje. Cineva spune „nu pot folosi asta până nu faci X” față de cineva care spune „ar fi grozav dacă ai avea X”. Distincția aceea e de aur.

Semnalul 3: Funcția se leagă de un model de afaceri

Unele funcții deblochează moduri complet noi de a face bani. „Facturează-mi clienții” deblochează un model de afaceri în care percepi bani pentru facturare. „Export către Salesforce” deblochează venituri din integrare. „White-label pentru revânzători” deblochează un canal de parteneri.

Dar iată trucul: nu știi dacă acele modele vor funcționa până nu lansezi deja. Nu poți planifica în jurul lor. Le poți observa doar după ce lansezi și vezi dacă oamenii chiar le folosesc.

Cele mai de succes adăugiri de funcții sunt cele unde lansarea funcției dezvăluie o piață despre care nu știai că există. Ai construit exportul. Se dovedește că firmele vor să-ți încorporeze exportul în fluxul lor de lucru. Acum ai o poveste de integrare pe care nu o planificaseși.

Construiește funcții pentru că utilizatorii tăi au nevoie de ele. Apoi urmărește să vezi dacă utilizatorii tăi au nevoie de ele într-un mod care creează o nouă afacere. Nu prezice modelul de afaceri mai întâi.

Semnalul 4: Cererea de ajutor

Dacă un utilizator îți cere să construiești ceva, asta e o cerere. Dacă un utilizator întreabă dacă ai putea construi ceva și se oferă să ajute la testare, asta e diferit.

Oamenii care se oferă să ajute la testare sunt oameni implicați în rezultat. Vor folosi funcția cu grijă. Vor raporta bug-uri. Îți vor spune dacă chiar le rezolvă problema.

Oamenii care doar cer sunt oameni care speră că vei construi în mod magic ce-și imaginează ei. Uneori o vei face. Adesea nu.

Construiește mai întâi cu testerii. Orice altceva e secundar.

Tentația de a construi funcția de prestigiu

Fiecare produs are o funcție care, dacă o lansezi, te face să suni mai impresionant. Pentru aplicațiile de programări, e integrarea cu Calendly. Pentru aplicațiile de sarcini, e integrarea cu Slack. Toată lumea știe care sunt acelea. Toată lumea le vrea.

Iată chestia: toată lumea le primește și de la altcineva. Dacă funcția ta nu e cea mai bună, mai ușoară integrare cu Slack, doar adaugă complexitate aplicației tale fără să te facă faimos.

Funcțiile care te fac faimos sunt cele pe care ești poziționat în mod unic să le construiești pentru că înțelegi problemele utilizatorilor tăi specifici mai bine decât oricine. Acelea nu sunt funcțiile de prestigiu. Acelea sunt funcțiile plictisitoare care rezolvă probleme reale pentru oameni reali.

Integrarea cu Slack e impresionantă. Un instrument care le permite utilizatorilor tăi să facă un lucru specific mult mai repede decât s-a gândit vreodată Slack e valoros.

Cum să decizi de fapt

Când ai un lot de cereri de funcții care trec toate testul „e asta în limitele produsului?”, clasifică-le după:

1. Câți utilizatori au cerut (independent)? Mai mulți e mai bine.
2. E un blocaj sau e drăguț de avut? Blocajele sunt mai urgente.
3. Pot utilizatorii tăi ocoli asta azi? Dacă nu, e mai important.
4. Va ajuta cineva să o testeze? Dacă da, construiește-o prima.
5. Va dezvălui asta o piață nouă? Dacă poate, ăsta e un bonus, nu un motiv.

Apoi construiește în acea ordine. Nu ordinea celor care sună impresionant. Nu ordinea celui mai mare client al tău. Ordinea semnalului real de la oamenii care îți folosesc aplicația.

Funcția pe care nu o vei construi (încă)

Vei avea cereri care nu trec selecția. Nu pretinde că le vei construi cândva. Spune-i utilizatorului: „Nu construim asta chiar acum. Iată de ce. Iată ce construim. Iată o alternativă care ar putea funcționa pentru tine”.

Acea sinceritate contează mai mult decât crezi. Utilizatorii ar prefera să știe că nu o vei face decât să aștepte șase luni sperând.

Și uneori, odată ce ai spus nu, utilizatorul găsește o soluție de compromis, sau un alt instrument, sau rezolvă problema într-un alt mod. E în regulă. Nu poți fi totul pentru toți.

Produsele care câștigă sunt cele care își fac treaba bine și ascultă cu atenție ce au nevoie cu adevărat utilizatorii, nu cele care încearcă să fie totul și ajung să fie nimic.