CB Insights publiceert jaarlijks een uitsplitsing van waarom startups mislukken. Jarenlang is de nr. 1 reden hetzelfde geweest: "geen marktbehoefte." Niet slechte uitvoering. Niet zonder geld zitten. Niet een slecht team. Het product loste gewoon geen probleem op dat mensen genoeg wilden veranderen voor.
Die statistiek is verbijsterend als je bedenkt hoeveel moeite in het bouwen van producten gaat. Teams besteden maanden — soms jaren — aan het ontwerpen van systemen, het schrijven van code, het betwisten van architectuur en het perfectioneren van flows. En de meest voorkomende reden voor hun mislukking is dat niemand zich afvroeg of iets ervan een echt probleem oploste.
Het bouwen van producten die mensen werkelijk willen is geen talent. Het is een discipline. Het heeft een methode, en die methode kan worden geleerd.
De meest voorkomende productfout is verliefd worden op een oplossing voordat je het probleem diep begrijpt. Dit is bijna universeel onder first-time oprichters en verrassend veel ook onder ervaren. Het patroon is altijd hetzelfde: iemand heeft een idee, zij vinden het overtuigend, en zij beginnen te bouwen. De klant is een nagedachte — iemand om te overtuigen, niet om te begrijpen.
Het tegengif is niet ingewikkeld, maar het vereist discipline: besteed meer tijd aan het probleem dan je denkt nodig te hebben, voordat je überhaupt oplossingen in overweging neemt. Praat met mensen die het probleem hebben. Kijk hoe zij werken. Begrijp de workarounds die zij vandaag gebruiken en waarom die workarounds onvolledig zijn. Alleen dan heb je genoeg context om iets te ontwerpen dat werkelijk aansluit.
Goede productontwikkeling is geen rechte lijn — het is een lus. Elke iteratie door de lus is een kans om aannames door bewijs te vervangen. De teams die producten bouwen die mensen willen, zijn degenen die deze lus snel en vaak voltooien.
De lus is geen formaliteit. Elke fase heeft een specifieke output die de input voor de volgende wordt. Fasen overslaan — meestal direct van Probleem naar Bouwen springen — is wat producten oplevert die het niet raken.
Niet alle problemen zijn het waard om op te lossen. Een goed productprobleem heeft drie kwaliteiten: het is frequent (beïnvloedt mensen vaak, niet zelden), het is intens (mensen voelen het genoeg om verlichting te willen), en de bestaande oplossingen zijn werkelijk ontoereikend (niet alleen iets anders dan wat je zou bouwen).
De fout is optimaliseren voor de eerste kwaliteit en de andere twee negeren. "Mensen verspillen tijd in vergaderingen" is frequent. Maar als de pijn laag is — als mensen voldoende goed werkende workarounds hebben gevonden — kan het probleem kommercieel niet het waard zijn om op te lossen. En als er al twaalf tools doen wat je wilt doen, heb je een erg specifieke reden waarom de jouwe zou worden gekozen.
Onderzoek heeft een slechte naam in productcirkels — het wordt geassocieerd met langzame consultancies, dikke rapporten en bevindingen die niemand leest. Dat is een mislukking van uitvoering, niet van de praktijk. Goed productonderzoek is snel, specifiek en verandert wat je bouwt.
Het doel van onderzoek is niet om te bevestigen dat het probleem echt is. Je zou daar al in moeten geloven voordat je zwaar in onderzoek investeert. Het doel is het probleem diep genoeg begrijpen om te weten hoe een goede oplossing eruitziet: wie specifiek het probleem heeft, in welke context, wat zij al hebben geprobeerd, welke woorden zij gebruiken om het te beschrijven, en hoe "opgelost" voor hen eruit zou zien.
Een hypothese is een specifieke, vervalste voorspelling over wat je gelooft waar te zijn. Het dwingt helderheid af. Als je geen duidelijke hypothese kunt schrijven, begrijp je het probleem nog niet goed genoeg om een oplossing te bouwen.
Een bruikbare producthypothese heeft drie onderdelen:
Het signaal is het meest belangrijke onderdeel — en het meest algemeen weggelaten. Zonder een vooraf verplichte signaal, "werkte" elk experiment min of meer. Teams vinden manieren om dubbele gegevens gunstig te interpreteren. Een hypothese zonder vervalsingsconditie is gewoon een wens.
De bouwfase is waar de meeste teams te veel tijd besteden. Het doel is niet het product te bouwen — het is het minimum ding te bouwen dat je signaal op je hypothese geeft. Dit zijn verschillende doelstellingen en zij produceren erg verschillende outputs.
Voor de meeste early-stage hypothesen is het minimum veel kleiner dan teams denken. Kun je handmatig doen wat de software zou doen, voor tien mensen, om te testen of zij het resultaat waarderen? Kun je bestaande tools samenstellen en de workflow testen voordat je nieuwe infrastructuur bouwt? Kun je een prototype schetsen en het door met vijf gebruikers doorlopen voordat je code schrijft?
De discipline hier is, voor je iets bouwt, vragen: "Wat probeer ik te leren?" en "Wat is het minimum dat me zou laten leren?" Het antwoord is bijna altijd kleiner dan wat het team wil bouwen.
Na lancering — of het nu een prototype, een handmatige pilot of een ingestelde functie is — is de metenfase waar teams zichzelf het meest vergissen. Zij vragen gebruikers of zij het leuk vonden. Gebruikers zeggen ja. Het team markeert het experiment als gevalideerd.
Sentiment is geen signaal. Het enige betrouwbare signaal is gedrag: deden mensen het? Kwamen zij terug? Betaalden zij? Vertelden zij het iemand anders?
Voor kwantitatieve meting instrument voor je lanceert. Weet welke specifieke acties je volgt. Stel van tevoren een drempel in — "we beschouwen dit als gevalideerd als X% van de gebruikers Y binnen Z dagen voltooien." Voor kwalitatieve meting voert u gestructureerde vervolginterviews door, niet open tevredenheidsenquêtes.
De leerfase gaat over het bijwerken van je mentale model van de gebruiker en het probleem, niet alleen over het besluiten wat vervolgens te bouwen. Teams die deze stap overslaan verzamelen gegevens maar stapelen geen begrip op in de loop van de tijd. Zij voeren snel uit, maar verbeteren hun oordeel in de loop van de tijd niet.
Een goede leersessie vraagt: Wat voorspelden wij? Wat gebeurde werkelijk? Wat zegt het gat ons over onze aannames? Wat is nu het meest belangrijke dat we niet weten?
De output van de leerfase is een scherpere probleemdefiniëring, een herziene hypothese of — als het experiment duidelijk mislukte — een beslissing om volledig een ander richtinggin te volgen. Al deze resultaten zijn waardevol. Het slechtste resultaat is onduidelijkheid: "we leerden enkele dingen maar weten niet zeker wat we nu moeten doen." Dat is een teken dat het experiment niet specifiek genoeg was.
Productontwikkeling bereikt nooit een stadium waar je deze lus ophoudt uit te voeren. De vragen veranderen — vroeg op je valideert je of het probleem echt is; later valideert je of een specifiek oplossingselement werkt — maar de structuur is altijd hetzelfde. Observeer, hypothese, test, leren.
De teams die producten bouwen die mensen willen, zijn niet degenen met het slimmste initiële inzicht. Het zijn degenen die de lus snelst en het eerlijkst voltooien. Leerssnelheid, niet shippingsnelheid, is het concurrentiele voordeel.