Cererile de funcționalități: cum le triezi și când refuzi

Odată ce produsul are primii utilizatori, apar și cererile de funcționalități (în engleză, feature requests): „Ne-ar trebui un export în alt format”, „Puteți adăuga o integrare cu programul nostru?”, „Un investitor a spus că ar fi bine să existe o aplicație mobilă”. Fiecare vine cu o motivație, iar un fondator amabil are tentația să spună da la toate. Rezultatul este un produs încărcat, o echipă împrăștiată și o direcție pierdută.

Cererile sunt valoroase, dar numai după ce le prelucrezi. Articolul arată cum să le aduni, să le triezi și să refuzi în așa fel încât relația cu cel care a cerut să rămână bună.

De ce nu execuți cererile exact cum sunt formulate?

O cerere descrie o soluție imaginată de client, nu neapărat problema reală. Răspunsul scurt: oamenii știu foarte bine ce îi încurcă, dar se pricep mai puțin să proiecteze remediul.

Un client care cere „buton de export în trei formate” poate avea, de fapt, problema că nu poate trimite rapid un raport colegilor. Un link de partajare ar rezolva-o mai simplu decât trei formate. Dacă construiești literal ce ți s-a cerut, riști să plătești de mai multe ori pentru o problemă pe care o puteai rezolva o dată.

De aceea, primul pas este să întrebi: „Ce ai încercat să faci când ți-ai dat seama că îți lipsește asta?” Metoda este aceeași cu cea din Jobs To Be Done: cauți situația, nu soluția.

Unde aduni cererile?

Cererile trebuie strânse într-un singur loc, indiferent de canalul pe care sosesc. Răspunsul direct: un registru simplu, într-o foaie de calcul sau într-un instrument de urmărire, în care fiecare cerere are aceleași câmpuri.

Câmpurile utile:

• cine a cerut (client, tip de client, investitor, coleg din echipă);
• ce a cerut, în cuvintele lui;
• problema din spate, formulată de tine;
• de câte ori a apărut aceeași nevoie;
• cât de important este clientul pentru strategia produsului (nu doar ca venit);
• starea: nouă, în analiză, planificată, amânată, refuzată.

Cererile vin din multe locuri: e-mailuri de suport, apeluri de vânzare, sondaje, discuții cu investitorii. Dacă ai un proces de culegere a părerilor, ca cel din feedbackul utilizatorilor, registrul devine un rezultat natural. Fără el, cererile se pierd în căsuțe de e-mail, iar cel mai insistent client câștigă atenția.

Sfat: pune în registru și cererile pe care le refuzi imediat. Peste câteva luni, o nevoie care revine de zece ori merită reevaluată.

Cum triezi cererile?

Trierea înseamnă să deosebești nevoile frecvente și legate de strategia ta de dorințele izolate. Răspunsul scurt: cauți tipare, nu voturi, și compari fiecare cerere cu direcția produsului.

Un set de întrebări îți ajută decizia:

1. Câți utilizatori au această problemă? Una singură sau o treime din baza de clienți?
2. Cât de gravă este? Îi oprește din folosirea produsului sau doar îi incomodează?
3. Se potrivește cu publicul și cu promisiunea produsului? Sau te trage spre alt tip de client?
4. Care este costul real? Nu doar construcția, ci întreținerea, testele, documentația, suportul.
5. Există alternativă mai simplă? O integrare existentă, un ghid, o schimbare mică de interfață?

Pentru ordinea concretă a lucrărilor planificate, folosește metodele RICE și MoSCoW, iar pentru direcția pe termen mediu, roadmap-ul de produs.

Ce faci cu cererile unui client mare sau ale unui investitor?

Aici presiunea este cea mai mare, iar riscul de a deveni, fără să vrei, o echipă de dezvoltare pe comandă este real. Răspunsul direct: asculți cu atenție, cauți nevoia generală din spatele cererii și nu construiești nimic doar pentru un singur partener fără un acord comercial clar.

Dacă un client mare cere ceva foarte specific, ai trei variante: îl convingi că funcția generală existentă acoperă nevoia, o construiești pentru că problema se va repeta la alții sau o tratezi ca proiect plătit separat, cu condiții scrise. A doua variantă e cea mai sănătoasă, dar numai dacă ai dovezi că și alții au nevoia.

Sugestiile investitorilor apar adesea în discuțiile din raportările către investitori și sunt tot cereri, cu greutate suplimentară. Notează-le și evaluează-le la fel ca pe celelalte. Un investitor te poate ajuta cu perspective valoroase, dar tu cunoști utilizatorii. Dacă o sugestie nu se potrivește produsului, o poți refuza politicos, explicând datele pe care te bazezi.

Cum refuzi o cerere fără să pierzi clientul?

Refuzul bun este clar, scurt, respectuos și legat de un motiv. Răspunsul scurt: spui ce ai înțeles, ce nu faci și de ce, apoi oferi o alternativă sau o ușă deschisă.

Un șablon simplu pentru răspuns:

1. Reia problema pe care ți-a descris-o clientul, ca să vadă că a fost înțeles.
2. Spune direct că nu ai planificat funcția în perioada următoare.
3. Explică într-o frază motivul (prioritate, tip de utilizatori, direcția produsului).
4. Oferă o variantă practică: o metodă existentă, o soluție ocolitoare sau un partener.
5. Păstrează deschisă posibilitatea: „O trec în registrul nostru și te anunț dacă se schimbă ceva.”

Evită promisiunile vagi, de tipul „o să vedem”. Un „nu” cinstit stârnește mai puțină frustrare decât un „poate” care nu se realizează niciodată. Dacă amâni, dă un motiv și un moment de reevaluare, nu o dată de livrare pe care nu o poți respecta.

Cum spui „nu” în interiorul echipei

Și propria echipă propune funcții. Un criteriu comun, scris, ușurează discuția: o idee intră în analiză dacă servește sarcina principală a utilizatorului sau un indicator pe care îl urmărești. Cadrul general al unui produs minimal, pe care îl poți folosi ca busolă, e în ghidul despre MVP. Iar efectul acumulării de funcții se vede în datoria tehnică: fiecare funcție adăugată se întreține, se testează și se explică.

Ce faci cu funcțiile pe care le lansezi?

Orice funcție lansată trebuie verificată după câteva săptămâni: este folosită? De cine? A rezolvat problema? Dacă nu, o simplifici sau o elimini. Această disciplină previne acumularea de funcții „fantomă”, pe care le menții fără ca nimeni să le folosească. Pentru măsurare, pregătește evenimentele potrivite din analitica de produs înainte de lansare.