CB Insights publiceert jaarlijks een analyse van waarom startups falen. Al jaren is de belangrijkste reden dezelfde: "geen marktbehoefte". Niet slechte uitvoering. Niet geldgebrek. Niet een zwak team. Het product loste simpelweg geen probleem op waarvoor mensen hun gedrag wilden veranderen.
Die statistiek is verbijsterend als je bedenkt hoeveel moeite er in het bouwen van producten gaat zitten. Teams besteden maanden — soms jaren — aan het ontwerpen van systemen, het schrijven van code, het discussiëren over architectuur en het perfectioneren van flows. En de meest voorkomende reden dat ze falen, is dat niemand zich afvroeg of dit alles wel een echt probleem oploste.
Producten bouwen die mensen echt willen, is geen talent. Het is een vak met discipline. Het heeft een methode, en die methode is te leren.
De meest voorkomende productfout is verliefd worden op een oplossing voordat je het probleem echt begrijpt. Dit komt bijna overal voor bij oprichters die voor het eerst een bedrijf starten, en verrassend vaak ook bij ervaren oprichters. Het patroon is altijd hetzelfde: iemand heeft een idee, vindt het overtuigend en begint te bouwen. De klant is bijzaak — iemand die je moet overtuigen, niet begrijpen.
Het tegengif is niet ingewikkeld, maar vraagt discipline: besteed meer tijd aan het probleem dan je nodig lijkt, voordat je ook maar aan oplossingen denkt. Praat met mensen die het probleem hebben. Kijk hoe ze werken. Begrijp welke noodoplossingen ze nu gebruiken en waarom die tekortschieten. Pas dan heb je genoeg context om iets te ontwerpen dat echt past.
Goede productontwikkeling is geen rechte lijn — het is een cyclus. Elke ronde is een kans om aannames te vervangen door bewijs. De teams die producten bouwen die mensen willen, doorlopen deze cyclus snel en vaak.
De cyclus is geen formaliteit. Elke fase levert een specifieke output op die de input voor de volgende wordt. Fasen overslaan — meestal direct van Probleem naar Bouwen — is wat producten oplevert die de plank misslaan.
Niet elk probleem is het oplossen waard. Een goed productprobleem heeft drie eigenschappen: het komt vaak voor (het raakt mensen regelmatig, niet zelden), het is intens (mensen voelen het genoeg om verlichting te willen) en de bestaande oplossingen schieten echt tekort (ze zijn niet slechts iets anders dan wat jij zou bouwen).
De fout is optimaliseren voor de eerste eigenschap en de andere twee negeren. "Mensen verspillen tijd in vergaderingen" komt vaak voor. Maar als de pijn gering is — als mensen goed genoeg werkende noodoplossingen hebben gevonden — is het probleem commercieel misschien niet de moeite waard. En als er al twaalf tools zijn die doen wat jij wilt doen, heb je een heel specifieke reden nodig waarom mensen voor die van jou zouden kiezen.
Onderzoek heeft in productkringen een slechte reputatie — het wordt geassocieerd met trage adviesbureaus, dikke rapporten en bevindingen die niemand leest. Dat is een kwestie van slechte uitvoering, niet van het vak zelf. Goed productonderzoek is snel, specifiek en verandert wat je bouwt.
Het doel van onderzoek is niet om te bevestigen dat het probleem echt is. Daar zou je al in moeten geloven voordat je fors in onderzoek investeert. Het doel is het probleem diep genoeg te begrijpen om te weten hoe een goede oplossing eruitziet: wie precies het probleem heeft, in welke context, wat ze al hebben geprobeerd, welke woorden ze ervoor gebruiken en hoe "opgelost" er voor hen uit zou zien.
Een hypothese is een specifieke, falsifieerbare voorspelling over wat je denkt dat waar is. Ze dwingt je tot duidelijkheid. Als je geen heldere hypothese kunt formuleren, begrijp je het probleem nog niet goed genoeg om een oplossing te bouwen.
Een bruikbare producthypothese heeft drie onderdelen:
Het signaal is het belangrijkste onderdeel — en het onderdeel dat het vaakst wordt weggelaten. Zonder een vooraf vastgelegd signaal "werkte" elk experiment "een beetje". Teams vinden manieren om dubbelzinnige data gunstig uit te leggen. Een hypothese zonder falsificatiecriterium is gewoon een wens.
In de bouwfase besteden de meeste teams te veel tijd. Het doel is niet om het product te bouwen — het is om het minimale te bouwen dat je een signaal geeft over je hypothese. Dat zijn verschillende doelen en ze leveren heel verschillende resultaten op.
Voor de meeste hypothesen in een vroege fase is het minimum veel kleiner dan teams denken. Kun je handmatig doen wat de software zou doen, voor tien mensen, om te testen of ze de uitkomst waarderen? Kun je bestaande tools aan elkaar knopen en de workflow testen voordat je nieuwe infrastructuur bouwt? Kun je een prototype schetsen en met vijf gebruikers doorlopen voordat je een regel code schrijft?
De discipline is om, voordat je iets bouwt, te vragen: "Wat probeer ik te leren?" en "Wat is het minimale waarmee ik dat kan leren?" Het antwoord is bijna altijd kleiner dan wat het team wil bouwen.
Na de lancering — of dat nu een prototype, een handmatige pilot of een uitgerolde functie is — houden teams zichzelf in de meetfase het vaakst voor de gek. Ze vragen gebruikers of ze het goed 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 ze terug? Betaalden ze? Vertelden ze het aan iemand anders?
Zet voor kwantitatieve metingen je tracking op vóór de lancering. Weet welke specifieke acties je volgt. Stel vooraf een drempel vast — "we beschouwen dit als gevalideerd als X% van de gebruikers Y binnen Z dagen afrondt." Voer voor kwalitatieve metingen gestructureerde vervolginterviews uit, geen open tevredenheidsenquêtes.
In de leerfase werk je je mentale model van de gebruiker en het probleem bij, en besluit je niet alleen wat je hierna bouwt. Teams die deze stap overslaan, verzamelen data maar bouwen geen inzicht op. Ze voeren snel uit, maar hun oordeelsvermogen verbetert niet.
Een goede leersessie stelt de volgende vragen: Wat hadden we voorspeld? Wat gebeurde er echt? Wat zegt het verschil over onze aannames? Wat is nu het belangrijkste dat we niet weten?
De output van de leerfase is een scherpere probleemomschrijving, een herziene hypothese of — als het experiment duidelijk mislukte — het besluit om een heel andere kant op te gaan. Al deze uitkomsten zijn waardevol. De slechtste uitkomst is onduidelijkheid: "we hebben wat geleerd, maar weten niet wat we nu moeten doen." Dat is een teken dat het experiment niet specifiek genoeg was.
Productontwikkeling bereikt nooit een punt waarop je deze cyclus stopt. De vragen veranderen — in het begin toets je of het probleem echt is; later toets je of een specifiek element van de oplossing werkt — maar de structuur is altijd hetzelfde. Observeer, formuleer een hypothese, test, leer.
De teams die producten bouwen die mensen willen, hebben niet het slimste eerste inzicht. Zij doorlopen de cyclus het snelst en het eerlijkst. Leersnelheid, niet opleversnelheid, is het concurrentievoordeel.