CB Insights publica una desglossat anual de per què fallen els startups. Durant anys, la raó número u ha estat la mateixa: "cap necessitat de mercat." No poca execució. No quedar-se sense diners. No un mal equip. El producte simplement no va resoldre un problema que la gent es preocupava prou com per canviar el seu comportament.
Aquesta estadística és impressionant quan consideres quant esforç es posa en construir productes. Els equips gasten mesos — a vegades anys — dissenyant sistemes, escrivint codi, discutint sobre arquitectura, i perfeccionant fluxos. I la raó més comuna que fallen és que ningú va preguntar si qualsevol d'allò estava responent un problema real.
Construir productes que la gent realment vol no és un talent. És una disciplina. Té un mètode, i aquest mètode pot ser après.
L'error de producte més comú és enamorar-se d'una solució abans de comprendre profundament el problema. Això és quasi universal entre fundadors de primera vegada i sorprenentment comú entre experimentats. El patró és sempre el mateix: algú té una idea, la troben compelling, i comencen a construir. El client és un pensament tardà — algú a convèncer, no a comprendre.
L'antídot no és complicat però requereix disciplina: passa més temps en el problema del que creus que és justificat, abans de considerar solucions en absolut. Parla amb gent que té el problema. Mira'ls treballar. Entén els amaços que usen avui i per què aquests amaços són imperfectes. Només llavors tens suficient context per dissenyar quelcom que realment encaixi.
El bon desenvolupament de producte no és una línia recta — és un bucle. Cada iteració al voltant del bucle és una oportunitat de reemplaçar supòsits amb evidència. Els equips que construeixen productes que la gent vol són els que completen aquest bucle ràpidament i sovint.
El bucle no és una formalitat. Cada etapa té una sortida específica que es converteix en l'entrada per a la següent. Saltar etapes — més comunament saltant directament de Problema a Construir — és allò que produeix productes que es perden.
No tots els problemes mereixen ser resolts. Un bon problema de producte té tres qualitats: és freqüent (afecta la gent sovint, no rarament), és intens (la gent el sent prou com per voler alleugeriment), i les solucions existents són genuïnament inadequades (no només una mica diferent del que construiries).
L'error és optimitzar per a la primera qualitat i ignorar les altres dues. "La gent perd temps en reunions" és freqüent. Però si el dolor és baix — si la gent ha trobat amaços prou bons — el problema potser no mereix resoldre comercialment. I si ja hi ha dotze eines fent allò que vols fer, necessites una raó molt específica per què la teva seria trià.
La recerca té una mala reputació en cercles de producte — s'associa amb consultories lentes, informes gruixuts, i troballes que ningú llegeix. Això és una fallada de l'execució, no de la pràctica. La bona recerca de producte és ràpida, específica, i canvia allò que construeixes.
L'objectiu de la recerca no és confirmar que el problema és real. Ja hauríes de creure això abans d'invertir lonadament en recerca. L'objectiu és entendre el problema prou profundament per saber com es veu una bona solució: qui específicament té el problema, en quin context, allò que ja han provat, les paraules que usen per descriure'l, i com seria "resolt" per a ells.
Una hipòtesi és una predicció específica i falsable sobre allò que creus que és veritat. Força la claredat. Si no pots escriure una hipòtesi clara, no entens el problema prou bé com per construir una solució.
Una hipòtesi útil de producte té tres parts:
La senyalització és la part més important — i la més comunament omesa. Sense una senyalització preescrita, cada experiment "més o menys va funcionar." Els equips troben maneres d'interpretar dades ambigües favorablement. Una hipòtesi sense una condició de falsificació és només un desig.
La fase de construcció és on la majoria d'equips passen massa temps. L'objectiu no és construir el producte — és construir la cosa mínima que te donarà senyalització en la teva hipòtesi. Aquests són objectius diferents i produeixen sortides molt diferents.
Per a la majoria d'hipòtesis de fase inicial, el mínim és molt menys del que els equips pensen. Pots fer manualment allò que el programari faria, per a deu persones, per provar si valoren el resultat? Pots cosir eines existents i provar el flux de treball abans de construir nova infraestructura? Pots fer un esbós d'un prototip i passar-lo per cinc usuaris abans d'escriure qualsevol codi?
La disciplina aquí és demanar, abans de construir qualsevol cosa: "Què intento aprendre?" i "Quina és la cosa mínima que me deixaria aprendre-ho?" La resposta és quasi sempre més petita que allò que l'equip vol construir.
Després del llançament — ja sigui un prototip, un pilot manual, o una característica desplegada — la fase de mesura és on els equips més comunament es burlen a si mateixos. Demanen als usuaris si els va agradar. Els usuaris diuen sí. L'equip marca l'experiment com a validat.
El sentiment no és senyalització. La senyalització única confiable és el comportament: van fer la gent la cosa? Van tornar? Van pagar? Van dir a algú més?
Per a mesurament quantitatiu, instrumenta abans de llançar. Sap quines accions específiques estàs rastreig. Fixa un llindar per endavant — "considerarem això validat si X% d'usuaris completen Y dins Z dies." Per a mesurament qualitatiu, realitza entrevistes de seguiment estructurades, no enquestes de satisfacció de final obert.
La fase d'aprenentatge es tracta d'actualitzar el teu model mental de l'usuari i el problema, no només decidir allò que construir a continuació. Els equips que salten aquest pas recopilen dades però no acumulen comprensió. Executen ràpidament però no milloren el seu judici al llarg del temps.
Una bona sessió d'aprenentatge pregunta: Què vàrem predir? Què va passar realment? Què ens diu l'espai sobre els nostres supòsits? Quina és ara la cosa més important que no sabem?
La sortida de la fase d'aprenentatge és una definició de problema més aguda, una hipòtesi revisada, o — si l'experiment clarament va fallar — una decisió de perseguir una direcció totalment diferent. Tots aquests resultats són valuosos. El pitjor resultat és ambigüitat: "vàrem aprendre algunes coses però no estem segurs allò que fer a continuació." Això és un signe que l'experiment no era prou específic.
El desenvolupament de producte mai no assoleix una etapa on deixes de correr aquest bucle. Les preguntes canvien — en fase inicial estàs validant si el problema és real; més tard estàs validant si un element de solució específica és funcionant — però l'estructura és sempre la mateixa. Observa, hipòtesi, prova, aprèn.
Els equips que construeixen productes que la gent vol no són aquells amb la perspectiva inicial més enginyosa. Són aquells que completen el bucle més ràpid i més honestament. Velocitat d'aprenentatge, no velocitat d'enviament, és l'avantatge competitiu.