CB Insights publică anual o analiză a motivelor pentru care eșuează startup-urile. Ani la rând, motivul numărul unu a fost același: „lipsa nevoii de piață." Nu execuția slabă. Nu faptul că au rămas fără bani. Nu o echipă slabă. Pur și simplu, produsul nu rezolva o problemă pentru care oamenii să fie dispuși să-și schimbe comportamentul.
Statistica aceasta e uluitoare dacă te gândești cât efort se investește în construirea produselor. Echipele petrec luni — uneori ani — proiectând sisteme, scriind cod, dezbătând arhitectura și perfecționând fluxuri. Iar cel mai frecvent motiv pentru care eșuează este că nimeni nu s-a întrebat dacă ceva din toate astea rezolvă o problemă reală.
Construirea produselor pe care oamenii și le doresc cu adevărat nu e un talent, ci o disciplină. Are o metodă, iar metoda aceasta poate fi învățată.
Cea mai frecventă greșeală de produs este să te îndrăgostești de o soluție înainte de a înțelege profund problema. Este aproape universală printre fondatorii aflați la prima experiență și surprinzător de des întâlnită și printre cei experimentați. Tiparul e mereu același: cineva are o idee, o găsește captivantă și începe să construiască. Clientul e un gând de după — cineva care trebuie convins, nu înțeles.
Antidotul nu e complicat, dar cere disciplină: petrece mai mult timp pe problemă decât ți se pare necesar, înainte de a te gândi măcar la soluții. Vorbește cu oamenii care au problema. Privește-i cum lucrează. Înțelege improvizațiile pe care le folosesc astăzi și de ce sunt imperfecte. Abia atunci ai suficient context ca să proiectezi ceva care se potrivește cu adevărat.
Dezvoltarea bună a produsului nu e o linie dreaptă — e o buclă. Fiecare iterație în jurul buclei e o oportunitate de a înlocui presupunerile cu dovezi. Echipele care construiesc produse pe care oamenii le doresc sunt cele care termină această buclă rapid și des.
Bucla nu e o formalitate. Fiecare etapă are un rezultat specific care devine punct de plecare pentru următoarea. A sări etape — cel mai comun e a sări direct de la Problemă la Construiește — e ceea ce produce produse care ratează ținta.
Nu toate problemele merită rezolvate. O problemă bună de produs are trei calități: e frecventă (afectează oamenii adesea, nu rar), e intensă (oamenii o simt destul de intens încât să caute o soluție), iar soluțiile existente sunt de fapt inadecvate (nu doar ușor diferite de ce ai construi tu).
Greșeala este să optimizezi pentru prima calitate și să le ignori pe celelalte două. „Oamenii pierd timp în ședințe" e o problemă frecventă. Dar dacă durerea e mică — dacă oamenii au găsit soluții suficient de bune — poate că nu merită rezolvată din punct de vedere comercial. Iar dacă există deja doisprezece instrumente care fac ceea ce vrei tu să faci, ai nevoie de un motiv foarte specific pentru care al tău ar fi ales.
Cercetarea are o reputație proastă în cercurile produselor — e asociată cu firme de consultanță lente, rapoarte groase, și constatări pe care nimeni nu le citește. Acesta este un eșec de execuție, nu al practicii. Cercetarea bună a produsului e rapidă, specifică și schimbă ceea ce construiești.
Scopul cercetării nu este să confirme că problema e reală. Ar trebui să crezi deja asta înainte să investești serios în cercetare. Scopul este să înțelegi problema suficient de bine încât să știi cum arată o soluție bună: cine anume are problema, în ce context, ce a încercat deja, ce cuvinte folosește pentru a o descrie și cum ar arăta „rezolvat" pentru el.
O ipoteză este o predicție specifică și falsificabilă despre ceea ce crezi că este adevărat. Te obligă la claritate. Dacă nu poți scrie o ipoteză clară, încă nu înțelegi problema suficient de bine pentru a construi o soluție.
O ipoteză utilă de produs are trei părți:
Semnalul este cea mai importantă parte — și cea mai des omisă. Fără un semnal stabilit în prealabil, fiecare experiment „a mers cât de cât." Echipele găsesc modalități de a interpreta în mod favorabil datele ambigue. O ipoteză fără condiție de falsificare este doar o dorință.
Faza de construcție este cea în care majoritatea echipelor pierd prea mult timp. Scopul nu e să construiești produsul — ci să construiești cel mai mic lucru care îți dă un semnal despre ipoteza ta. Sunt obiective diferite și produc rezultate foarte diferite.
Pentru majoritatea ipotezelor din stadiu incipient, minimul este mult mai puțin decât cred echipele. Poți face manual, pentru zece oameni, ceea ce ar face software-ul, ca să testezi dacă prețuiesc rezultatul? Poți lega între ele instrumente existente și testa fluxul de lucru înainte să construiești infrastructură nouă? Poți schița un prototip și să-l parcurgi cu cinci utilizatori înainte de a scrie cod?
Disciplina constă în a te întreba, înainte de a construi orice: „Ce încerc să învăț?" și „Care e cel mai mic lucru care mi-ar permite să învăț?" Răspunsul e aproape întotdeauna mai mic decât ceea ce echipa vrea să construiască.
După lansare — fie că este un prototip, un pilot manual sau o funcție lansată — faza de măsurare este cea în care echipele se păcălesc cel mai des. Își întreabă utilizatorii dacă le-a plăcut. Utilizatorii spun da. Echipa marchează experimentul ca validat.
Sentimentul nu e semnal. Singurul semnal fiabil este comportamentul: au făcut oamenii lucrul? Au revenit? Au plătit? Au spus altcuiva?
Pentru măsurarea cantitativă, pregătește monitorizarea înainte de lansare. Știi exact ce acțiuni urmărești. Stabilește un prag în prealabil — „vom considera experimentul validat dacă X% dintre utilizatori finalizează Y în Z zile." Pentru măsurarea calitativă, desfășoară interviuri de follow-up structurate, nu sondaje de satisfacție cu răspunsuri deschise.
Faza de învățare înseamnă actualizarea modelului tău mental despre utilizator și despre problemă, nu doar decizia a ce să construiești în continuare. Echipele care sar peste acest pas colectează date, dar nu acumulează înțelegere. Execută rapid, dar nu-și îmbunătățesc judecata în timp.
O sesiune bună de învățare întreabă: Ce am prezis? Ce s-a întâmplat de fapt? Ce ne spune decalajul despre presupunerile noastre? Care e acum cel mai important lucru pe care nu-l știm?
Rezultatul fazei de învățare este o definiție mai precisă a problemei, o ipoteză revizuită sau — dacă experimentul a eșuat clar — decizia de a urma o cu totul altă direcție. Toate aceste rezultate sunt valoroase. Cel mai rău rezultat este ambiguitatea: „am învățat câteva lucruri, dar nu știm ce să facem mai departe." Este un semn că experimentul nu a fost suficient de specific.
Dezvoltarea produsului nu ajunge niciodată într-o etapă în care te poți opri din parcurgerea acestei bucle. Întrebările se schimbă — la început validezi dacă problema este reală; mai târziu validezi dacă un anumit element al soluției funcționează — dar structura e mereu aceeași. Observă, formulează o ipoteză, testează, învață.
Echipele care construiesc produse pe care oamenii și le doresc nu sunt cele cu cel mai ingenios insight inițial. Sunt cele care parcurg bucla cel mai rapid și cel mai onest. Viteza de învățare, nu viteza de livrare, este avantajul competitiv.