Jobs To Be Done (abreviat JTBD, adică „sarcini de îndeplinit”) este un cadru de gândire care pleacă de la o întrebare simplă: pentru ce sarcină „angajează” clientul produsul tău? Un om nu vrea o bormașină, vrea o gaură în perete, iar în spatele găurii vrea o poliță pe care să-și pună cărțile. Cu cât te apropii mai mult de situația reală, cu atât produsul tău devine mai clar.
Pentru un fondator, metoda e utilă mai ales când ai multe idei de funcționalități și nu știi pe care să o alegi. În loc să te întrebi ce îți cer utilizatorii, te întrebi ce încearcă ei să obțină și ce îi împiedică acum.
Ce înseamnă o „sarcină” în Jobs To Be Done?
O sarcină este progresul pe care o persoană vrea să-l facă într-o situație concretă, indiferent de produsul pe care îl folosește. Răspunsul scurt: sarcina descrie rezultatul dorit, nu soluția.
O sarcină are de obicei trei straturi:
- funcțional: ce trebuie făcut efectiv (de exemplu, să trimiți o ofertă unui client până la prânz);
- emoțional: cum vrea persoana să se simtă (sigură pe ea, fără stres, în control);
- social: cum vrea să fie văzută de ceilalți (organizată, competentă, modernă).
Mulți fondatori se opresc la stratul funcțional. În practică, motivul pentru care cineva schimbă o soluție cu alta are adesea legătură cu emoția: frica de greșeală, rușinea unui fișier dezordonat, nevoia de liniște.
Diferența dintre sarcină și persoană-țintă
Un profil clasic de client spune „femeie, 35 de ani, antreprenoare”. O sarcină spune „vreau să știu seara dacă am încasat tot ce mi se datorează, fără să deschid cinci aplicații”. Două persoane cu profiluri foarte diferite pot avea aceeași sarcină, iar două persoane asemănătoare pot avea sarcini diferite. Pentru decizii de produs, a doua informație contează mai mult.
Cum găsești sarcinile reale ale clienților?
Cel mai sigur te uiți la momentul în care cineva a schimbat ceva în viața lui: a început să folosească un produs nou sau a renunțat la unul vechi. Răspunsul direct: întrebi despre decizia concretă și despre context, nu despre opinii.
Metoda se leagă natural de interviurile cu clienții potențiali, dar are un accent propriu: reconstruiești povestea alegerii, pas cu pas.
Întrebările care deschid povestea
- Când ai început să cauți o soluție? Ce se întâmplase în ziua aceea?
- Ce foloseai înainte și ce nu mai mergea?
- Ce alte variante ai luat în calcul, inclusiv „să nu fac nimic”?
- Cine a mai fost implicat în decizie?
- Ce a făcut diferența la decizia finală?
- Ce te-a făcut să ezi?
Răspunsurile la întrebarea 3 sunt foarte valoroase. Concurența ta reală include foaia de calcul, agenda, mesajele pe telefon și amânarea. Un produs nou se bate adesea cu un obicei, nu cu alt produs.
Sfat: cere întotdeauna un exemplu concret, din ultima perioadă („povestește-mi ultima dată când ai făcut asta”), nu o părere generală. Oamenii își povestesc mai exact trecutul decât își prevăd viitorul.
Care sunt cele patru forțe care duc la schimbare?
Un client trece la un produs nou când forțele care îl împing și îl atrag sunt mai puternice decât cele care îl țin pe loc. Răspunsul scurt: contează deopotrivă frustrarea de acum, atracția noului, frica de schimbare și inerția obiceiului.
| Forța | Direcția | Exemplu |
|---|---|---|
| Împingerea situației actuale | spre schimbare | cifrele se adună manual, apar erori |
| Atracția soluției noi | spre schimbare | promisiunea unui raport automat |
| Anxietatea față de nou | împotriva schimbării | „și dacă pierd datele?” |
| Obișnuința | împotriva schimbării | „așa am făcut mereu” |
Poți folosi tabelul ca listă de verificare după fiecare interviu. Dacă ai multă atracție, dar și multă anxietate, nu adăuga funcționalități: reduci frica prin garanții, import simplu de date și o perioadă de probă clară.
Cum scrii o job story utilă?
O job story este o propoziție scurtă care leagă situația, motivația și rezultatul, fără să numească soluția. Forma obișnuită: „Când [situația], vreau [motivația], ca să [rezultatul].”
Câteva exemple, adaptate unor produse imaginare:
- „Când termin o ședință cu un client, vreau să trimit rapid un rezumat, ca să nu uit angajamentele luate.”
- „Când stocul unui produs scade sub un prag, vreau să fiu avertizat, ca să comand la timp.”
Diferența față de o poveste de utilizator clasică este că nu apare „utilizatorul” ca rol abstract, ci situația. Dacă te interesează varianta de specificații pentru dezvoltatori, vezi articolul despre user stories; cele două se completează, iar job story-ul vine de obicei primul.
Semne că o job story e prea vagă
- poate fi rezolvată de zece produse complet diferite, fără nicio legătură între ele;
- nu menționează nicio situație concretă;
- rezultatul este o emoție generală („să fiu fericit”), fără un indiciu observabil.
Cum folosești sarcinile în deciziile de produs?
Sarcinile devin utile când le legi de alegeri concrete: ce intră în versiunea următoare, ce mesaj pui pe pagina principală, ce nu construiești. Răspunsul direct: fiecare funcționalitate propusă trebuie să se poată lega de o sarcină validată, altfel rămâne o presupunere.
Poți face un exercițiu simplu. Scrie sarcinile pe care le-ai găsit pe un perete sau într-un document, apoi trece fiecare funcționalitate din lista ta sub sarcina pe care o servește. Funcționalitățile rămase fără sarcină sunt candidate la eliminare. Pentru ordinea de lucru poți continua cu metodele din prioritizarea funcționalităților.
Legătura cu MVP-ul
Un produs minim viabil servește bine o singură sarcină principală, iar semnul că ai nimerit-o apare mai târziu, în product-market fit. Dacă ai trei sarcini diferite într-o primă versiune, probabil construiești trei produse. Cadrul general e explicat în ghidul despre MVP, iar sarcina aleasă îți spune ce înseamnă „minim” în cazul tău.
Legătura cu mesajul de marketing
Sarcina bine înțeleasă se transformă în textul de pe pagina principală. În loc de „platformă inovatoare de gestiune”, scrii ce rezolvă: „Vezi seara cine ți-a plătit și cine întârzie”. Clienții se recunosc în propria situație, iar rata de înscriere o arată destul de repede.
Ce greșeli apar cel mai des cu Jobs To Be Done?
Cea mai frecventă greșeală este să tratezi cadrul ca pe o rețetă magică, nu ca pe o disciplină de ascultare. Alte capcane:
- confunzi sarcina cu o funcționalitate („vreau un buton de export”);
- intervievezi doar oameni care te plac deja, deci auzi doar poveștile fericite;
- uiți de cei care au renunțat, deși poveștile lor arată exact unde produsul nu convinge;
- definești sarcini atât de largi încât nu mai ghidează nicio decizie.
Atenție: zece interviuri bune bat o sută de răspunsuri într-un sondaj. Nu extrapola un procent dintr-un eșantion mic; folosește poveștile pentru a găsi tipare, apoi verifică tiparele cu date din produs.
Întrebări frecvente
Jobs To Be Done este același lucru cu persona clientului?
Nu. Persona descrie cine este clientul, iar sarcina descrie ce vrea să obțină într-o situație. Pot fi folosite împreună, dar pentru deciziile de produs sarcina oferă mai multe indicii.
Câte interviuri îmi trebuie pentru a găsi sarcinile?
De obicei, tiparele încep să se repete după opt-zece interviuri bune cu persoane care au schimbat de curând o soluție. Depinde de cât de omogenă este piața ta.
Pot folosi metoda dacă nu am încă produs?
Da. Chiar este momentul potrivit, pentru că poți afla ce soluții folosesc oamenii acum și ce îi nemulțumește, înainte să scrii prima linie de cod.
Cum diferă o job story de o user story?
Job story-ul descrie situația și motivația, iar user story-ul descrie ce face un rol dintr-un sistem. Prima ajută la descoperire, a doua la livrare.
Cine ar trebui să facă interviurile?
Ideal, fondatorii înșiși, cel puțin la început. Informația aflată direct se pierde ușor când trece prin mai multe persoane.
