CB Insights publică o descompunere anuală a motivelor pentru care startupurile eșuează. Ani de-a rândul, motivul nr. unu a fost același: „fără nevoie de piață." Nu execuție slabă. Nu insolvență. Nu o echipă proastă. Produsul pur și simplu nu rezolva o problemă pe care oamenii se grăbeau destul de mult să-și schimbe comportamentul pentru.
Acea statistică e șocantă când iei în considerare cât efort intră în construirea produselor. Echipele petrec luni — uneori ani — proiectând sisteme, scriind cod, argumentând despre arhitectură, și perfecționând fluxuri. Și motivul cel mai comun pentru care eșuează este că nimeni nu a întrebat dacă vreunul din asta rezolva o problemă reală.
Construirea produselor pe care oamenii le doresc nu e un talent. E o disciplină. Are o metodă, și acea metodă poate fi învățată.
Greșeala produsului cea mai comună e a te îndrăgosti de o soluție înainte de a înțelege profund problema. Asta e aproape universală printre fondatori pentru prima dată și surprinzător de comună chiar și printre cei experimentați. Modelul e mereu același: cineva are o idee, o găsește captivantă, și începe să construiască. Clientul e o gândire secundară — cineva de convins, nu de înțeles.
Antidotul nu e complicat dar necesită disciplină: petrece mai mult timp pe problemă decât crezi că e necesar, înainte să iei în considerare soluții deloc. Vorbește cu oameni care au problema. Privește-i lucrul. Înțelege soluțiile provizorii pe care le folosesc astăzi și de ce alea sunt imperfecte. Abia atunci ai suficient context pentru a proiecta 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 produste pe care oamenii le doresc sunt cele care termină această buclă rapid și adesea.
Bucla nu e o formalitate. Fiecare etapă are un rezultat specific care devine intrare 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 nu pun pe gânduri.
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 mult pentru a dori ușurare), și soluțiile existente sunt de fapt inadecvate (nu doar ușor diferite de ce ai construi tu).
Greșeala e optimizând pentru prima calitate și ignorând celelalte două. „Oamenii risipesc timp în întâlniri" e frecventă. Dar dacă durerea e scăzută — dacă oamenii au găsit soluții suficient de bune — problema poate să nu merite rezolvată comercial. Și dacă există deja doisprezece unelte care fac ceea ce vrei tu să faci, ai nevoie de o motivă foarte specifică de ce a ta ar fi aleasă.
Cercetarea are o reputație proastă în cercurile produselor — e asociată cu consultanțe lente, rapoarte groase, și constatări pe care nimeni nu le citește. Asta e o eșec de execuție, nu a practicii. Cercetarea bună a produsului e rapidă, specifică, și schimbă ceea ce construiești.
Scopul cercetării nu e a confirma că problema e reală. Ar trebui deja să crezi asta înainte să investești greu în cercetare. Scopul e a înțelege problema profund destul pentru a ști cum arată o soluție bună: cine anume are problema, în ce context, ce au încercat deja, ce cuvinte folosesc pentru a o descrie, și cum ar arăta „rezolvat" pentru ei.
O ipoteză e o predicție specifică și falsificabilă despre ceea ce crezi că e adevărat. Forțează claritate. Dacă nu poți scrie o ipoteză clară, nu înțelegi de fapt problema suficient pentru a construi o soluție.
O ipoteză utilă de produs are trei părți:
Semnalul e cea mai importantă parte — și cea mai des omisă. Fără un semnal pre-angajat, fiecare experiment „a funcționat cumva." Echipele găsesc moduri de a interpreta date ambigui favorabil. O ipoteză fără condiție de falsificare e doar o dorință.
Faza construcției e unde petrec timpul cele mai multe echipe. Scopul nu e a construi produsul — e a construi cel mai mic lucru care îți va da semnal pe ipoteza. Acestea sunt obiective diferite și produc rezultate foarte diferite.
Pentru majoritatea ipotezelor timpurii, minimul e mult mai puțin decât cred echipele. Poți face manual ceea ce ar face software, pentru zece oameni, pentru a testa dacă valorează rezultatul? Poți cusca unelte existente și testa fluxul de lucru înainte să construiești infrastructură nouă? Poți schița un prototip și-l parcurge cu cinci utilizatori înainte de a scrie cod?
Disciplina aici e a întreba, înainte de a construi ceva: „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 asta prototip, pilot manual, sau caracteristică implementată — faza de măsurare e unde se înșală echipele cel mai comun. Întreabă utilizatorii dacă le-a plăcut. Utilizatorii zic da. Echipa marchează experimentul ca validat.
Sentimentul nu e semnal. Singurul semnal fiabil e comportament: au făcut oamenii lucrul? Au revenit? Au plătit? Au spus altcuiva?
Pentru măsurare cantitativă, instrumentează înainte de lansare. Ști care acțiuni specifice urmărești. Stabilește un prag dinainte — „vom considera asta validat dacă X% utilizatori termină Y în Z zile." Pentru măsurare calitativă, conduce interviuri de urmărire structurate, nu sondaje de satisfacție deschise.
Faza de învățare e despre actualizarea modelului tău mental al utilizatorului și problemei, nu doar deciderea ce să construiești următor. Echipele care sar acest pas colectează date dar nu acumulează înțelegere. Executează 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 e o definiție a problemei mai ascuțită, o ipoteză revizuită, sau — dacă experimentul a eșuat clar — o decizie de a urmări o direcție complet diferită. Toate aceste rezultate sunt valoroase. Cel mai rău rezultat e ambiguitate: „am învățat unele lucruri dar nu sunt sigur ce să fac următor." Asta e un semn că experimentul nu a fost specific destul.
Dezvoltarea produsului nu ajunge niciodată la o etapă unde încetezi să rulez această buclă. Întrebările se schimbă — devreme ești validând că problema e reală; mai târziu validezi dacă un element specific de soluție funcționează — dar structura e mereu aceeași. Observă, ipotezează, testează, învață.
Echipele care construiesc produste pe care oamenii le doresc nu sunt cele cu cel mai deștept insight inițial. Sunt cele care termină bucla cel mai rapid și cel mai onest. Viteза învățării, nu viteza livrării, e avantajul competitiv.