CB Insights publiserer hvert år en analyse av hvorfor startups feiler. I årevis har den fremste årsaken vært den samme: "ingen markedsbehov." Ikke dårlig eksekvering. Ikke at pengene tok slutt. Ikke et dårlig team. Produktet løste rett og slett ikke et problem folk brydde seg nok om til å endre atferden sin for.
Den statistikken er forbløffende når man tenker på hvor mye innsats som går med til å bygge produkter. Team bruker måneder — noen ganger år — på å designe systemer, skrive kode, argumentere om arkitektur og perfeksjonere flyt. Og den vanligste årsaken til at de feiler er at ingen spurte om noe av det løste et reelt problem.
Å bygge produkter folk faktisk vil ha er ikke et talent. Det er en disiplin. Den har en metode, og den metoden kan læres.
Den vanligste produktfeilen er å bli forelsket i en løsning før man forstår problemet i dybden. Dette er nesten universelt blant førstegangsgründere og overraskende vanlig blant erfarne. Mønsteret er alltid det samme: noen har en idé, de finner den overbevisende og begynner å bygge. Kunden er en ettertanke — noen som skal overbevises, ikke forstås.
Motgiftet er ikke komplisert, men krever disiplin: bruk mer tid på problemet enn du synes er berettiget, før du i det hele tatt vurderer løsninger. Snakk med folk som har problemet. Se dem jobbe. Forstå de midlertidige løsningene de bruker i dag og hvorfor disse er ufullkomne. Først da har du nok kontekst til å designe noe som genuint passer.
God produktutvikling er ikke en rett linje — det er en sløyfe. Hver runde i sløyfen er en mulighet til å erstatte antagelser med bevis. Teamene som bygger produkter folk vil ha er de som gjennomfører denne sløyfen raskt og ofte.
Sløyfen er ikke en formalitet. Hvert trinn har et spesifikt resultat som blir inndata for det neste. Å hoppe over trinn — oftest å hoppe direkte fra Problem til Bygg — er det som produserer produkter som bommer.
Ikke alle problemer er verdt å løse. Et godt produktproblem har tre egenskaper: det er hyppig (påvirker folk ofte, ikke sjelden), det er intenst (folk kjenner det nok til å ville ha lindring) og de eksisterende løsningene er genuint utilstrekkelige (ikke bare litt annerledes enn det du ville bygge).
Feilen er å optimere for den første egenskapen og ignorere de to andre. "Folk kaster bort tid i møter" er hyppig. Men hvis smerten er lav — hvis folk har funnet gode nok midlertidige løsninger — er problemet kanskje ikke verdt å løse kommersielt. Og hvis det allerede finnes tolv verktøy som gjør det du vil gjøre, trenger du en veldig spesifikk grunn til at ditt ville bli valgt.
Research har et dårlig rykte i produktkretser — det forbindes med langsomme konsulentfirmaer, tykke rapporter og funn som ingen leser. Det er en feil i eksekvering, ikke i praksis. God produktresearch er rask, spesifikk og endrer hva du bygger.
Målet med research er ikke å bekrefte at problemet er reelt. Det bør du allerede tro før du investerer tungt i research. Målet er å forstå problemet dypt nok til å vite hva en god løsning ser ut som: hvem spesifikt har problemet, i hvilken kontekst, hva de allerede har prøvd, hvilke ord de bruker til å beskrive det og hva "løst" ville se ut som for dem.
En hypotese er en spesifikk, falsifiserbar spådom om hva du tror er sant. Den tvinger frem klarhet. Hvis du ikke kan skrive en klar hypotese forstår du ennå ikke problemet godt nok til å bygge en løsning.
En nyttig produkthypotese har tre deler:
Signalet er den viktigste delen — og den som oftest utelates. Uten et forhåndsbestemt signal "virket" hvert eksperiment "ganske bra." Team finner måter å tolke tvetydige data gunstig på. En hypotese uten en falsifiseringsbetingelse er bare et ønske.
Byggefasen er der de fleste team bruker for mye tid. Målet er ikke å bygge produktet — det er å bygge det minimum som vil gi deg signal om hypotesen din. Dette er forskjellige mål og de produserer svært forskjellige resultater.
For de fleste tidlige hypoteser er minimum mye mindre enn team tror. Kan du manuelt gjøre det programvaren ville gjøre, for ti personer, for å teste om de verdsetter utfallet? Kan du sette sammen eksisterende verktøy og teste arbeidsflyten før du bygger ny infrastruktur? Kan du skissere en prototype og gå gjennom den med fem brukere før du skriver noen kode?
Disiplinen her er å spørre før du bygger noe: "Hva prøver jeg å lære?" og "Hva er det minimum som ville la meg lære det?" Svaret er nesten alltid mindre enn det teamet vil bygge.
Etter lansering — enten det er en prototype, et manuelt pilotprosjekt eller en deployert funksjon — er målefasen der team oftest lurer seg selv. De spør brukerne om de likte det. Brukerne sier ja. Teamet markerer eksperimentet som validert.
Sentiment er ikke signal. Det eneste pålitelige signalet er atferd: gjorde folk det? Kom de tilbake? Betalte de? Fortalte de noen andre?
For kvantitativ måling, instrumenter før du lanserer. Vit hvilke spesifikke handlinger du sporer. Sett en terskel på forhånd — "vi vil anse dette som validert hvis X% av brukerne fullfører Y innen Z dager." For kvalitativ måling, gjennomfør strukturerte oppfølgingsintervjuer, ikke åpne tilfredshetsundersøkelser.
Lærefasen handler om å oppdatere den mentale modellen din av brukeren og problemet, ikke bare å bestemme hva du skal bygge neste gang. Team som hopper over dette trinnet samler inn data men akkumulerer ikke forståelse. De eksekverer raskt men forbedrer ikke dømmekraften sin over tid.
En god læresesjon spør: Hva forutsa vi? Hva skjedde faktisk? Hva forteller gapet oss om antagelsene våre? Hva er nå det viktigste vi ikke vet?
Resultatet av lærefasen er en skarpere problemdefinisjon, en revidert hypotese eller — hvis eksperimentet tydelig mislyktes — en beslutning om å følge en helt annen retning. Alle disse utfallene er verdifulle. Det verste utfallet er tvetydighet: "vi lærte noen ting men er ikke sikre på hva vi skal gjøre neste gang." Det er et tegn på at eksperimentet ikke var spesifikt nok.
Produktutvikling når aldri et stadium der du slutter å kjøre denne sløyfen. Spørsmålene endrer seg — tidlig validerer du om problemet er reelt; senere validerer du om et spesifikt løsningselement fungerer — men strukturen er alltid den samme. Observer, hypotiser, test, lær.
Teamene som bygger produkter folk vil ha er ikke de med den smarteste innledende innsikten. De er de som gjennomfører sløyfen raskest og mest ærlig. Læringshastighet, ikke leveringshastighet, er konkurransefortrinnet.