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 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 forelsker sig i en løsning inden man dybt forstår problemet. Dette er næsten universelt blandt førstegangsgründere og overraskende almindeligt 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 overvejer løsninger overhovedet. Tal med folk der har problemet. Se dem arbejde. Forstå de workarounds de bruger i dag og hvorfor disse er ufuldkomne. Først da har du nok kontekst til at designe noget der genuint passer.
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 genuint utilstrækkelige (ikke blot lidt anderledes end hvad 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 hvad 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 eksekvering, ikke i praksis. God produktresearch er hurtig, specifik og ændrer hvad du bygger.
Målet med research er ikke at bekræfte at problemet er reelt. Det bør du allerede tro inden du investerer tungt i research. Målet er at forstå problemet dybt nok til at vide hvad en god løsning ser ud som: hvem specifikt har problemet, i hvilken kontekst, hvad de allerede har prøvet, hvilke ord de bruger til at beskrive det og hvad "løst" ville se ud som for dem.
En hypotese er en specifik, falsificerbar forudsigelse om hvad 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 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. Disse er forskellige mål og de producerer meget forskellige outputs.
For de fleste tidlige hypoteser er minimum meget mindre end teams tror. Kan du manuelt gøre hvad 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 hvad teamet vil bygge.
Efter lancering — hvad enten det er en prototype, et manuelt pilotprojekt eller en deployeret funktion — er målefasen 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 inden 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 akkumulerer ikke forståelse. De eksekverer 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, hypotisér, 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.