CB Insights publica cada any un desglossament de per què fracassen les startups. Durant anys, el motiu número u ha estat el mateix: «cap necessitat de mercat». No una mala execució. No quedar-se sense diners. No un mal equip. Simplement, el producte no resolia un problema que importés prou a la gent com per canviar el seu comportament.
Aquesta estadística impressiona quan es considera quin esforç es dedica a construir productes. Els equips passen mesos — de vegades anys — dissenyant sistemes, escrivint codi, discutint sobre arquitectura i perfeccionant fluxos. I el motiu més habitual del fracàs és que ningú es va preguntar si res d'això responia a un problema real.
Construir productes que la gent vol no és un do. És una disciplina. Té un mètode, i aquest mètode es pot aprendre.
L'error de producte més comú és enamorar-se d'una solució abans d'entendre a fons el problema. És gairebé universal entre els fundadors novells i sorprenentment habitual entre els experimentats. El patró és sempre el mateix: algú té una idea, la troba apassionant i es posa a construir. El client és una idea de darrera hora — algú a qui cal convèncer, no a qui cal entendre.
L'antídot no és complicat, però requereix disciplina: dedica més temps al problema del que et sembli justificat abans de plantejar-te cap solució. Parla amb gent que tingui el problema. Mira com treballa. Entén les solucions provisionals que fa servir avui i per què són imperfectes. Només llavors tindràs prou context per dissenyar alguna cosa que realment encaixi.
El bon desenvolupament de producte no és una línia recta — és un bucle. Cada volta al bucle és una oportunitat de substituir supòsits per evidències. Els equips que construeixen productes que la gent vol són els que completen aquest bucle de pressa i sovint.
El bucle no és una formalitat. Cada etapa té un resultat concret que passa a ser l'entrada de la següent. Saltar-se etapes — sobretot passar directament del problema a la construcció — és el que produeix productes que es perden.
No tots els problemes mereixen resoldre's. Un bon problema de producte té tres qualitats: és freqüent (afecta la gent sovint, no de tant en tant), és intens (la gent el sent prou com per voler alleujar-lo) i les solucions existents són realment inadequades (no només una mica diferents del que tu construiries).
L'error és optimitzar 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 solucions provisionals prou bones — potser el problema no val la pena resoldre'l comercialment. I si ja hi ha dotze eines que fan el que vols fer, necessites un motiu molt concret perquè triïn la teva.
La recerca té mala fama en els cercles de producte — s'associa amb consultories lentes, informes gruixuts i conclusions que ningú llegeix. Això és un fracàs de l'execució, no de la pràctica. La bona recerca de producte és ràpida, concreta i canvia el que construeixes.
L'objectiu de la recerca no és confirmar que el problema és real. Això ja hauries de creure-ho abans d'invertir-hi esforç. L'objectiu és entendre el problema prou a fons per saber com és una bona solució: qui exactament té el problema, en quin context, què ha provat ja, quines paraules fa servir per descriure'l i com seria «resolt» per a ell.
Una hipòtesi és una predicció concreta i falsable sobre el que creus que és cert. Obliga a ser clar. Si no pots escriure una hipòtesi clara, no entens prou bé el problema per construir-hi una solució.
Una hipòtesi útil de producte té tres parts:
El senyal és la part més important — i la que s'omet més sovint. Sense un senyal fixat per endavant, tots els experiments «van funcionar més o menys». Els equips troben maneres d'interpretar favorablement dades ambigües. Una hipòtesi sense una condició de falsació és només un desig.
La fase de construcció és on la majoria d'equips perden massa temps. L'objectiu no és construir el producte — és construir el mínim que et doni senyal sobre la teva hipòtesi. Són objectius diferents i produeixen resultats molt diferents.
Per a la majoria d'hipòtesis en fase inicial, el mínim és molt menys del que els equips pensen. Pots fer manualment el que faria el programari, per a deu persones, per comprovar si valoren el resultat? Pots enllaçar eines existents i provar el flux de treball abans de construir infraestructura nova? Pots esbossar un prototip i ensenyar-lo a cinc usuaris abans d'escriure una sola línia de codi?
La disciplina aquí és preguntar-se, abans de construir res: «Què intento aprendre?» i «Quina és la cosa mínima que em permetria aprendre-ho?» La resposta gairebé sempre és més petita del que l'equip vol construir.
Després del llançament — ja sigui un prototip, un pilot manual o una funcionalitat desplegada — la fase de mesura és on els equips s'enganyen més sovint a si mateixos. Pregunten als usuaris si els ha agradat. Els usuaris diuen que sí. L'equip marca l'experiment com a validat.
L'opinió no és un senyal. L'únic senyal fiable és el comportament: la gent ho va fer? Va tornar? Va pagar? Ho va explicar a algú més?
Per a la mesura quantitativa, instrumenta abans de llançar. Tingues clar quines accions concretes estàs seguint. Fixa un llindar per endavant — «considerarem això validat si X% dels usuaris completen Y en Z dies». Per a la mesura qualitativa, fes entrevistes de seguiment estructurades, no enquestes de satisfacció de resposta oberta.
La fase d'aprenentatge consisteix a actualitzar el teu model mental de l'usuari i del problema, no només a decidir què construir a continuació. Els equips que se salten aquest pas recullen dades però no acumulen comprensió. Executen ràpid, però no milloren el seu criteri amb el temps.
Una bona sessió d'aprenentatge pregunta: què vam predir? Què va passar realment? Què ens diu això sobre els nostres supòsits? Quina és ara la cosa més important que no sabem?
El resultat de la fase d'aprenentatge és una definició del problema més precisa, una hipòtesi revisada o — si l'experiment ha fracassat clarament — la decisió de seguir una direcció totalment diferent. Tots aquests resultats són valuosos. El pitjor resultat és l'ambigüitat: «hem après algunes coses, però no sabem què fer a continuació». Això indica que l'experiment no era prou concret.
El desenvolupament de producte mai no arriba a una etapa en què deixes de fer aquest bucle. Les preguntes canvien — a l'inici valides si el problema és real; més tard, valides si un element concret de la solució funciona — però l'estructura és sempre la mateixa. Observa, formula una hipòtesi, prova, aprèn.
Els equips que construeixen productes que la gent vol no són els que tenen la intuïció inicial més brillant. Són els que completen el bucle més de pressa i amb més honestedat. La velocitat d'aprenentatge, no la velocitat d'enviament, és l'avantatge competitiu.