CB Insights publicerar varje år en sammanfattning av varför startups misslyckas. Under flera år har den främsta anledningen varit densamma: "ingen marknadsbehov." Inte dålig execution. Inte att pengarna tog slut. Inte ett dåligt team. Produkten löste helt enkelt inte ett problem som folk brydde sig tillräckligt om för att ändra sitt beteende för.
Den statistiken är häpnadsväckande med tanke på hur mycket ansträngning som läggs på att bygga produkter. Team spenderar månader — ibland år — på att designa system, skriva kod, argumentera om arkitektur och perfektionera flöden. Och den vanligaste anledningen till att de misslyckas är att ingen frågade om något av det löste ett riktigt problem.
Att bygga produkter som folk faktiskt vill ha är inte en talang. Det är en disciplin. Den har en metod, och den metoden kan läras.
Det vanligaste produktmisstaget är att bli kär i en lösning innan man förstår problemet på djupet. Detta är nästan universellt bland förstagångsgrundare och förvånansvärt vanligt bland erfarna. Mönstret är alltid detsamma: någon har en idé, de finner den övertygande och börjar bygga. Kunden är en eftertanke — någon som ska övertygas, inte förstås.
Motmedlet är inte komplicerat men kräver disciplin: tillbringa mer tid på problemet än du tror är motiverat, innan du ens överväger lösningar. Prata med folk som har problemet. Se dem arbeta. Förstå de workarounds de använder idag och varför dessa är ofullkomliga. Först då har du tillräckligt med kontext för att designa något som genuint passar.
God produktutveckling är inte en rak linje — det är en slinga. Varje varv runt slingan är en möjlighet att ersätta antaganden med bevis. De team som bygger produkter som folk vill ha är de som fullföljer denna slinga snabbt och ofta.
Slingan är inte en formalitet. Varje steg har ett specifikt resultat som blir ingångsvärde för nästa. Att hoppa över steg — vanligast är att hoppa direkt från Problem till Bygg — är vad som producerar produkter som missar målet.
Inte alla problem är värda att lösa. Ett bra produktproblem har tre egenskaper: det är frekvent (påverkar folk ofta, inte sällan), det är intensivt (folk känner det tillräckligt starkt för att vilja ha lindring) och de befintliga lösningarna är genuint otillräckliga (inte bara lite annorlunda än vad du skulle bygga).
Misstaget är att optimera för den första egenskapen och ignorera de två andra. "Folk slösar tid i möten" är frekvent. Men om smärtan är låg — om folk har hittat tillräckligt bra workarounds — kan problemet inte vara värt att lösa kommersiellt. Och om det redan finns tolv verktyg som gör vad du vill göra, behöver du en mycket specifik anledning till varför ditt skulle väljas.
Forskning har dåligt rykte i produktkretsar — det förknippas med långsamma konsultföretag, tjocka rapporter och fynd som ingen läser. Det är ett misslyckande i execution, inte i praktiken. God produktforskning är snabb, specifik och förändrar vad du bygger.
Målet med forskning är inte att bekräfta att problemet är verkligt. Det bör du redan tro innan du investerar tungt i forskning. Målet är att förstå problemet tillräckligt djupt för att veta hur en bra lösning ser ut: vem specifikt har problemet, i vilket sammanhang, vad de redan har prövat, vilka ord de använder för att beskriva det och vad "löst" skulle se ut för dem.
En hypotes är en specifik, falsifierbar förutsägelse om vad du tror är sant. Den tvingar fram tydlighet. Om du inte kan skriva en tydlig hypotes förstår du ännu inte problemet tillräckligt bra för att bygga en lösning.
En användbar produkthypotes har tre delar:
Signalen är den viktigaste delen — och den som oftast utelämnas. Utan en förutbestämd signal "fungerade" varje experiment "ganska bra." Team hittar sätt att tolka tvetydiga data gynnsamt. En hypotes utan ett falsifieringsvillkor är bara en önskan.
Byggfasen är där de flesta team spenderar för mycket tid. Målet är inte att bygga produkten — det är att bygga det minimum som ger dig signal om din hypotes. Dessa är olika mål och de producerar väldigt olika resultat.
För de flesta tidiga hypoteser är minimum mycket mindre än vad team tror. Kan du manuellt göra vad programvaran skulle göra, för tio personer, för att testa om de värdesätter utfallet? Kan du sätta ihop befintliga verktyg och testa arbetsflödet innan du bygger ny infrastruktur? Kan du skissa en prototyp och gå igenom den med fem användare innan du skriver någon kod?
Disciplinen här är att fråga, innan du bygger något: "Vad försöker jag lära mig?" och "Vad är det minimum som skulle låta mig lära mig det?" Svaret är nästan alltid mindre än vad teamet vill bygga.
Efter lansering — vare sig det är en prototyp, ett manuellt pilotprojekt eller en driftsatt funktion — är mätfasen där team oftast lurar sig själva. De frågar användarna om de gillade det. Användarna säger ja. Teamet markerar experimentet som validerat.
Sentiment är inte signal. Den enda tillförlitliga signalen är beteende: gjorde folk det? Kom de tillbaka? Betalade de? Berättade de för någon annan?
För kvantitativ mätning, instrumentera innan du lanserar. Vet vilka specifika åtgärder du spårar. Sätt ett tröskelvärde i förväg — "vi kommer att betrakta detta som validerat om X% av användarna slutför Y inom Z dagar." För kvalitativ mätning, genomför strukturerade uppföljningsintervjuer, inte öppna nöjdhetsundersökningar.
Lärfasen handlar om att uppdatera din mentala modell av användaren och problemet, inte bara att bestämma vad du ska bygga härnäst. Team som hoppar över detta steg samlar in data men ackumulerar inte förståelse. De exekverar snabbt men förbättrar inte sitt omdöme över tid.
En bra lärsession frågar: Vad förutsåg vi? Vad hände faktiskt? Vad berättar klyftan om våra antaganden? Vad är nu den viktigaste saken vi inte vet?
Resultatet av lärfasen är en skarpare problemdefinition, en reviderad hypotes eller — om experimentet tydligt misslyckades — ett beslut att följa en helt annan riktning. Alla dessa utfall är värdefulla. Det värsta utfallet är tvetydighet: "vi lärde oss vissa saker men är inte säkra på vad vi ska göra härnäst." Det är ett tecken på att experimentet inte var specifikt nog.
Produktutveckling når aldrig ett stadium där du slutar köra denna slinga. Frågorna förändras — tidigt validerar du om problemet är verkligt; senare validerar du om ett specifikt lösningselement fungerar — men strukturen är alltid densamma. Observera, hypotetisera, testa, lär.
De team som bygger produkter som folk vill ha är inte de med den smartaste initiala insikten. De är de som fullföljer slingan snabbast och mest ärligt. Inlärningshastighet, inte leveranshastighet, är konkurrensfördelarna.