CB Insights udgiver hvert år en analyse af, hvorfor startups fejler. I årevis har den primære årsag været den samme: »ingen markedsbehov.« Ikke dårlig eksekvering. Ikke at pengene slap op. Ikke et dårligt team. Produktet løste simpelthen ikke et problem, som folk bekymrede sig nok om til at ændre deres adfærd for.
Den statistik er forbløffende, når man tænker på, hvor meget energi der går med at bygge produkter. Teams bruger måneder — nogle gange år — på at designe systemer, skrive kode, diskutere arkitektur og perfektionere flows. Og den mest almindelige årsag til, at de fejler, er, at ingen spurgte, om noget af det løste et rigtigt problem.
At bygge produkter, som folk faktisk vil have, er ikke et talent. Det er en disciplin. Den har en metode, og den metode kan læres.
Den mest almindelige produktfejl er at forelske sig i en løsning, inden man dybt forstår problemet. Det gælder næsten alle førstegangsgrundlæggere og er overraskende udbredt blandt erfarne. Mønstret er altid det samme: nogen har en idé, de finder den overbevisende og begynder at bygge. Kunden er en eftertanke — nogen, der skal overbevises, ikke forstås.
Modgiften er ikke kompliceret, men kræver disciplin: brug mere tid på problemet, end du synes er berettiget, inden du overhovedet overvejer løsninger. Tal med folk, der har problemet. Se dem arbejde. Forstå de workarounds, de bruger i dag, og hvorfor de er ufuldkomne. Først da har du nok kontekst til at designe noget, der passer rigtigt.
God produktudvikling er ikke en ret linje — det er en sløjfe. Hver runde i sløjfen er en mulighed for at erstatte antagelser med beviser. De teams, der bygger produkter, folk vil have, er dem, der gennemfører denne sløjfe hurtigt og ofte.
Sløjfen er ikke en formalitet. Hvert trin har et specifikt output, der bliver input til det næste. At springe trin over — oftest at springe direkte fra Problem til Byg — er det, der producerer produkter, der rammer ved siden af.
Ikke alle problemer er værd at løse. Et godt produktproblem har tre egenskaber: det er hyppigt (påvirker folk ofte, ikke sjældent), det er intenst (folk mærker det nok til at ville have lindring), og de eksisterende løsninger er reelt utilstrækkelige (ikke blot lidt anderledes end det, du ville bygge).
Fejlen er at optimere for den første egenskab og ignorere de to andre. »Folk spilder tid i møder« er hyppigt. Men hvis smerten er lav — hvis folk har fundet gode nok workarounds — er problemet måske ikke værd at løse kommercielt. Og hvis der allerede er tolv værktøjer, der gør det, du vil gøre, har du brug for en meget specifik grund til, at dit ville blive valgt.
Research har et dårligt ry i produktkredse — det forbindes med langsomme konsulentfirmaer, tykke rapporter og resultater, som ingen læser. Det er en fejl i udførelsen, ikke i selve metoden. God produktresearch er hurtig, specifik og ændrer det, du bygger.
Målet med research er ikke at bekræfte, at problemet er reelt. Det bør du allerede tro på, inden du investerer tungt i research. Målet er at forstå problemet så dybt, at du ved, hvordan en god løsning ser ud: hvem der specifikt har problemet, i hvilken kontekst, hvad de allerede har prøvet, hvilke ord de bruger til at beskrive det, og hvordan »løst« ville se ud for dem.
En hypotese er en specifik, falsificerbar forudsigelse om det, du mener er sandt. Den tvinger klarhed frem. Hvis du ikke kan skrive en klar hypotese, forstår du endnu ikke problemet godt nok til at bygge en løsning.
En nyttig produkthypotese har tre dele:
Signalet er den vigtigste del — og den, der oftest udelades. Uden et forudbestemt signal »virkede« hvert eksperiment »nogenlunde.« Teams finder måder at fortolke tvetydige data gunstigt. En hypotese uden en falsificeringsbetingelse er bare et ønske.
Byggefasen er der, hvor de fleste teams bruger for meget tid. Målet er ikke at bygge produktet — det er at bygge det minimum, der vil give dig signal om din hypotese. Det er to forskellige mål, og de giver meget forskellige resultater.
For de fleste tidlige hypoteser er minimum meget mindre, end teams tror. Kan du manuelt gøre det, softwaren ville gøre, for ti personer for at teste, om de værdsætter resultatet? Kan du sammensætte eksisterende værktøjer og teste arbejdsgangen, inden du bygger ny infrastruktur? Kan du skitsere en prototype og gennemgå den med fem brugere, inden du skriver nogen kode?
Disciplinen her er at spørge, inden du bygger noget: »Hvad forsøger jeg at lære?« og »Hvad er det minimum, der ville lade mig lære det?« Svaret er næsten altid mindre, end teamet vil bygge.
Efter lancering — hvad enten det er en prototype, et manuelt pilotprojekt eller en udrullet funktion — er målefasen der, hvor teams oftest narrer sig selv. De spørger brugerne, om de kunne lide det. Brugerne siger ja. Teamet markerer eksperimentet som valideret.
Sentiment er ikke signal. Det eneste pålidelige signal er adfærd: gjorde folk det? Kom de tilbage? Betalte de? Fortalte de nogen andre?
For kvantitativ måling: Instrumentér, før du lancerer. Vid, hvilke specifikke handlinger du sporer. Sæt en tærskel på forhånd — »vi vil betragte dette som valideret, hvis X% af brugerne gennemfører Y inden for Z dage.« For kvalitativ måling, gennemfør strukturerede opfølgningsinterviews, ikke åbne tilfredshedsundersøgelser.
Lærefasen handler om at opdatere din mentale model af brugeren og problemet, ikke blot at beslutte hvad du skal bygge næste gang. Teams, der springer dette trin over, indsamler data, men opbygger ikke forståelse. De udfører hurtigt, men forbedrer ikke deres dømmekraft over tid.
En god læresession spørger: Hvad forudsagde vi? Hvad skete der faktisk? Hvad fortæller kløften os om vores antagelser? Hvad er nu det vigtigste, vi ikke ved?
Resultatet af lærefasen er en skarpere problemdefinition, en revideret hypotese eller — hvis eksperimentet tydeligvis mislykkedes — en beslutning om at forfølge en helt anden retning. Alle disse resultater er værdifulde. Det værste resultat er tvetydighed: »vi lærte nogle ting, men er ikke sikre på, hvad vi skal gøre næste gang.« Det er et tegn på, at eksperimentet ikke var specifikt nok.
Produktudvikling når aldrig et stadie, hvor du holder op med at køre denne sløjfe. Spørgsmålene ændrer sig — tidligt validerer du, om problemet er reelt; senere validerer du, om et specifikt løsningselement virker — men strukturen er altid den samme. Observér, opstil hypoteser, test, lær.
De teams, der bygger produkter, folk vil have, er ikke dem med den klogeste indledende indsigt. De er dem, der gennemfører sløjfen hurtigst og mest ærligt. Læringshastighed, ikke leveringshastighed, er konkurrencefordelen.