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 gjennomføring. 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, diskutere arkitektur og finpusse brukerflyter. 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.
Motgiften er ikke komplisert, men den krever disiplin: bruk mer tid på problemet enn du synes er nødvendig, før du i det hele tatt vurderer løsninger. Snakk med folk som har problemet. Se dem jobbe. Forstå nødløsningene de bruker i dag, og hvorfor disse er ufullkomne. Først da har du nok kontekst til å designe noe som virkelig 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 konkret resultat som blir innspill til det neste. Å hoppe over trinn — oftest å hoppe direkte fra Problem til Bygg — er det som gir 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 virkelig 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.
Undersøkelser har et dårlig rykte i produktkretser — det forbindes med langsomme konsulentfirmaer, tykke rapporter og funn som ingen leser. Det er en svikt i gjennomføringen, ikke i selve fagfeltet. Gode produktundersøkelser er raske, spesifikke og endrer hva du bygger.
Målet med undersøkelser er ikke å bekrefte at problemet er reelt. Det bør du allerede tro før du investerer tungt i undersøkelser. Målet er å forstå problemet dypt nok til å vite hvordan en god løsning ser ut: hvem som har problemet, i hvilken kontekst, hva de allerede har prøvd, hvilke ord de bruker for å beskrive det, og hvordan «løst» ville se ut 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 gir svært ulike 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 utrullet 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.
Meninger 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 bør du sette opp sporing før du lanserer. Ha klart for deg hvilke spesifikke handlinger du sporer. Sett en terskel på forhånd — «vi anser dette som validert hvis X % av brukerne fullfører Y innen Z dager». For kvalitativ måling bør du gjennomføre strukturerte oppfølgingsintervjuer, ikke åpne tilfredshetsundersøkelser.
Læringsfasen 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 bygger ikke opp forståelse. De gjennomfører raskt, men forbedrer ikke dømmekraften sin over tid.
En god læringsøkt 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æringsfasen 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, formuler hypoteser, test, lær.
Teamene som bygger produkter folk vil ha, er ikke de med den smarteste første innsikten. De er de som gjennomfører sløyfen raskest og mest ærlig. Læringshastighet, ikke leveringshastighet, er konkurransefortrinnet.