Waarom zoveel productideeën falen – gebruik bewijs als strategisch kompas

In productontwikkeling ontbreekt het zelden aan ideeën – maar wél aan succesvolle ideeën. Veel keuzes worden nog altijd gemaakt op basis van meningen, onderbuikgevoel of hiërarchie, in plaats van bewijs. Het AFTER-model biedt een praktische manier om ideeën snel en doelgericht te valideren, en zo kostbare tijd te besparen door alleen te bouwen aan wat impact maakt.

Hoe meningen producten vormen – en waarom bewijs dat beter kan

Iedereen heeft wel een idee voor het product: stakeholders, sales, support en klanten. Maar de harde waarheid is dat de overgrote meerderheid van deze ideeën niet leidt tot meetbare verbeteringen in bedrijfsresultaten of klantwaarde. Sommige ideeën hebben zelfs een negatief effect.

Daar zijn meerdere redenen voor. Een die we waarschijnlijk allemaal herkennen als product professionals, is dat we vaak al verliefd zijn op onze oplossing voordat we echt begrijpen wat het probleem van de gebruiker is. Daarnaast wint in veel organisaties nog steeds de HIPPO (Highest Paid Person’s Opinion). Niemand – ongeacht hoe senior of ervaren – kan voorspellen welke ideeën zullen werken en welke niet. Daarvoor zijn er simpelweg te veel onbekenden. Veel organisaties gebruiken onbetrouwbare aannames, meningen en verouderde besluitvormingsprocessen om in te zetten op een handvol onbewezen ideeën. Geen wonder dat onsuccesvolle ideeën snel bij productteams belanden. We investeren dan weken of maanden in oplossingen zonder aantoonbare behoefte.

Zoals Nobelprijswinnaar Linus Pauling ooit zei: “If you want to have good ideas you must have many ideas. Most of them will be wrong.” En dat klopt. De kunst is om snel en betrouwbaar te ontdekken welk idee werkt. Niet op basis van onderbuikgevoel, macht of koppigheid, maar op basis van bewijs. Productontwikkeling moet minder lijken op gokken en meer op onderzoek doen. Daarom is het essentieel om waarheidsvinding toe te passen in productontwikkeling. Alleen zo kunnen we het verschil maken tussen tijdsverspilling en echte vooruitgang.

Wie tijd en middelen wil investeren in wat écht werkt, moet stoppen met bouwen op meningen – en starten met bouwen op bewijs.

De vier vragen die bepalen of jouw idee het waard is

In productmanagementkringen is de term Product Discovery het meest synoniem geworden met evidence-guided productontwikkeling. Zo beschrijft productmanagementgoeroe Marty Cagan product discovery in zijn boek Inspired:

“Ons doel bij discovery is om onze ideeën op de snelste en goedkoopste manier mogelijk te valideren. Discovery draait om snelheid. Hierdoor kunnen we veel ideeën uitproberen, en bij veelbelovende ideeën meerdere benaderingen testen. Er zijn veel verschillende soorten ideeën, veel verschillende soorten producten, en allerlei risico’s waarmee we rekening moeten houden.”

Cagan benoemt vier belangrijke invalshoeken bij productontwikkeling die tot risico’s kunnen leiden:

Value: zullen gebruikers dit willen gebruiken of kopen?
Usability: kunnen gebruikers begrijpen hoe dit werkt?
Feasibility: kunnen we dit bouwen? (technisch en binnen redelijke tijd)
Viability: is het zakelijk verantwoord om te leveren?

Bij veel van de zaken waar we aan werken, zijn de antwoorden op deze vragen vrij duidelijk en brengen ze weinig risico met zich mee. We zijn er dan zeker van: we hebben dit eerder gedaan en weten hoe het werkt. In dat geval gaan we meestal direct door naar de deliveryfase.

De echte discovery-activiteit begint wanneer deze antwoorden níet zo duidelijk zijn. Niet alle vier invalshoeken hoeven altijd gevalideerd te worden. Soms zijn haalbaarheid en levensvatbaarheid vanzelfsprekend. We beginnen meestal met het inschatten van de waarde. Dit is vaak de moeilijkste – en tegelijk de belangrijkste – vraag om te beantwoorden. Als er geen waarde is, doet de rest er weinig toe. De meeste producten falen omdat niemand ze nodig heeft – niet omdat ze technisch onmogelijk zijn.

In de praktijk blijkt dat teams vaak de fout maken en zeggen: “Waarom valideren? In die tijd hadden we het al kunnen bouwen.” Dat is duur, inefficiënt en ondermijnt het vertrouwen van stakeholders. Hoe langer we wachten met valideren, hoe moeilijker het is om bij te sturen. Het wordt ook duurder.

Er is ook veel verwarring en misvattingen over ideevalidatie. Veel mensen in de industrie denken dat het allemaal draait om experimenten uitvoeren. Er zijn andere, veel goedkopere en directere manieren om een idee te testen. Door ons blind te staren op experimenten leggen veel bedrijven de lat te hoog, missen ze eenvoudige kansen en geven ze zichzelf vaak een excuus om op de oude manier door te gaan.

Succesvolle producten ontstaan niet door alles te bouwen, maar door eerst te ontdekken wat echt waardevol is – en dat begint bij goede vragen, niet bij snelle oplossingen.

Het AFTER-model: van mening naar onderbouwing

Om te onderzoeken of onze ideeën waardevol, bruikbaar, haalbaar en levensvatbaar zijn, moeten we ze toetsen op basis van bewijs – niet op meningen. Itamar Gilad introduceert hiervoor in zijn boek Evidence-Guided het AFTER-model: vijf categorieën van validatie:

Assessment – Een snelle, globale inschatting van het potentieel en de risico’s van een idee, zonder extern onderzoek.
Fact Finding – Actief op zoek gaan naar data en feiten die het idee ondersteunen of juist ondermijnen.
Tests – Steeds verder uitgewerkte versies van het idee voorleggen aan gebruikers en hun reacties meten.
Experiments – Kwantitatieve tests uitvoeren met controle-elementen om foutieve resultaten te vermijden.
Release Results – Het product geleidelijk uitrollen naar meer gebruikers, terwijl we hun reactie monitoren.

Het AFTER-model helpt ons om van losse meningen naar systematische onderbouwing te bewegen – en dat maakt het een onmisbare routekaart voor productteams.

De onderstaande afbeelding toont enkele van de belangrijkste validatiemethoden binnen elke categorie, maar er zijn er veel meer.

A – Assessment

Assessment is de eerste stap – zonder extern onderzoek – om snel in te schatten of een idee de moeite waard is om verder te verkennen. Het levert onvoldoende bewijs om te besluiten een idee daadwerkelijk te bouwen en te lanceren (al gebeurt dat in de praktijk nog regelmatig). Toch helpt het ons om een idee objectief en gestructureerd te evalueren en een eerste indruk van de potentie te krijgen.

Veelgebruikte assessment-technieken:

Goals alignment – Helpt dit idee ons om één van onze doelen te bereiken? Zo niet, dan parkeren we het en behouden we focus.
Business modeling – Nieuwe producten en modellen moeten op papier logisch zijn. Dit kan via een eenvoudige spreadsheet of bijvoorbeeld een Business Model Canvas.
Initial ICE analysis – We schatten de potentiële Impact en Ease in op basis van ervaring of ruwe berekeningen. Confidence bepalen we altijd met behulp van de Confidence Meter.
Assumption mapping – Een waardevolle brainstormtechniek om verborgen aannames en risico’s boven water te krijgen.
Stakeholder reviews – Interne stakeholders kunnen ons wijzen op bedrijfsrisico’s (juridisch, merk, PR, veiligheid) en adviseren welk bewijs nodig is. Een variant op stakeholderreviews zijn partnerinterviews, waarbij je het idee voorlegt aan een externe partner om grotendeels dezelfde zaken te toetsen.

Een adequate assessment zorgt voor een eerste schifting, waardoor we geen tijd verspillen aan ideeën zonder potentie.

F – Fact Finding

De volgende stap is het zoeken naar beschikbare feiten en data die het idee ondersteunen of juist onderuit halen. Belangrijk om daarbij te beseffen: zelfs als er ondersteunende feiten zijn, is dat zelden voldoende onderbouwing om een idee daadwerkelijk te bouwen. Fact finding helpt vooral om te bepalen of een idee het waard is om verder te testen. Als we bijvoorbeeld 4K-resolutie willen aanbieden in onze videodienst, kan het feit dat dit de meest gevraagde feature is het idee ondersteunen, terwijl het feit dat slechts 6% van onze klanten een 4K-apparaat gebruikt dat juist niet doet.

Belangrijke fact finding-technieken:

Data analysis – Analyseren van logdata, klikstromen, funnel analytics, heatmaps, sessieherhalingen, feedback, verzoeken, CRM-data, enz. Pas op met het analyseren van andermans data – dit is mogelijk niet representatief voor jouw doelgroep.
Surveys – Vragenlijsten helpen om snel en goedkoop kwantitatieve en kwalitatieve inzichten te verzamelen. Resultaten kunnen echter vertekend zijn door sampling bias, misinterpretaties en andere valkuilen.
Competitor analysis – Laat ons niet zien of een idee goed is, maar wel of concurrenten het als probleem beschouwen, hoe ze het positioneren, prijzen en wat gebruikers ervan vinden.
User interviews – Elk contact met gebruikers of klanten is een kans om te leren: wat zijn hun behoeften, wat gebruiken ze nu, en wat vinden ze van je idee? Interviews leveren rijke kwalitatieve informatie op.
Field research – Gebruikers observeren in hun natuurlijke omgeving leert ons veel over context, gedrag en de oplossing die het best aansluit bij hun leven.

Aanrader: Bouw een vast ritme in voor fact finding – interview minimaal 2 gebruikers per week, doe elk kwartaal veldonderzoek, analyseer data regelmatig, enz.

Hoe beter we de feiten kennen, hoe slimmer we kunnen bepalen welke ideeën het waard zijn om als vervolgstap te testen.

T – Tests

Een idee testen betekent een (vereenvoudigde) versie ervan voorleggen aan gebruikers en hun reactie meten. Soms testen we puur om te leren of het werkt, andere keren formuleren we vooraf succescriteria via hypothesis statements.

Populaire vormen van tests:

Smoke tests – Ook wel Fake Door tests genoemd. Ze helpen bij het testen van de vraag naar een (nog niet bestaand) product of feature. Denk aan advertenties, landingspagina’s, call-to-actions in het product, pop-up winkels, crowdfundingcampagnes, enz. Conversieratio’s geven inzicht in hoe aantrekkelijk het idee is. Bij interesse informeren we de gebruiker dat het product nog niet klaar is en bieden we bijvoorbeeld de mogelijkheid tot aanmelden op een wachtlijst – wat zelf ook weer een test is.
Wizard of Oz – Een snelle manier om een productidee te simuleren is door mensen het werk te laten doen dat de software uiteindelijk zou automatiseren. De gebruiker lijkt met een werkende interface te werken, terwijl er achter de schermen een mens het werk uitvoert.
Concierge Test – Teamleden voeren handmatig een dienst uit namens de klant, vaak met medeweten van die klant. Het doel is om te leren wat klanten echt waardevol vinden, nog voordat er software wordt gebouwd. Een bekend voorbeeld is Groupon: de oprichters startten met het aanbieden van flitsaanbiedingen via hun blog. Ze maakten de kortingsbonnen handmatig en verstuurden deze per e-mail naar klanten. Op deze manier konden ze de waardepropositie testen en inzicht krijgen in klantgedrag, zonder eerst een volledig product te ontwikkelen.
Usability tests – We vragen gebruikers om het product te gebruiken onder begeleiding van een tester. We kunnen interactieve mockups, een code prototype of een werkend product gebruiken. De interface moet er realistisch uitzien, maar in vroege tests is de functionaliteit vaak beperkt en maken we gebruik van testdata.
Early-adopters – Geselecteerde klanten krijgen vroege toegang in ruil voor eerlijke feedback en direct contact met het productteam. Deze gebruikers zijn bereid om met een incompleet product te werken om als eerste toegang te krijgen en invloed te hebben op de vorm ervan.
Dogfood – Een product eerst intern testen (“eating your own dogfood”) is gebruikelijk bij grote techbedrijven. Bij Gmail deden we eerst een fishfood test met enkel het team of aanverwante teams, voordat het breder werd getest. Kanttekening: collega’s zijn niet representatief voor de doelgroep, gebruiken het gratis en zijn toleranter voor bugs, maar leveren wel waardevolle vroege feedback op waarde, gebruiksvriendelijkheid en kritieke fouten.
Longitudinal user study – Bij gebruikerstests over een langere periode gebruiken deelnemers een product gedurende meerdere weken of maanden. Ze moeten het minstens één keer proberen, maar mogen daarna zelf kiezen of ze doorgaan. Betalen gebeurt altijd voor de volledige test, ongeacht het gebruik. Tijdens de test meten we gebruik, retentie, tevredenheid en verzamelen we feedback. Zo ontdekken we of het product langdurige waarde biedt. Een sterke indicatie is wanneer deelnemers balen dat ze het niet meer kunnen gebruiken.
Labs – Optionele functies in een product die gebruikers zelf kunnen inschakelen, met de waarschuwing dat de functie nog niet af is, mogelijk niet altijd goed werkt en op elk moment kan worden verwijderd. Gmail testte jarenlang functies via Labs; sommige groeiden uit tot vaste onderdelen, andere verdwenen weer. Labs bieden ontwikkelaars een veilige experimenteerruimte om vroeg feedback en gebruiksdata te verzamelen. Gebruikers krijgen zo vroege toegang en kunnen meedenken over de richting. Omdat gebruikers zichzelf aanmelden voor labs, zijn de resultaten waardevol maar niet altijd representatief, en is het belangrijk om een duidelijke einddatum vast te stellen.

We testen om vooraf te leren of onze oplossing waardevol is – niet pas na lancering.

Als tests eerste signalen van waarde opleveren, is het tijd om met experimenten robuustere bewijsvoering op te bouwen.

E – Experiments

Experimenten zijn tests met een controlegroep, bedoeld om toevallige invloeden uit te sluiten. Een A/B-test is dus een experiment, terwijl een usability-test dat niet is. Hoewel de termen vaak door elkaar gebruikt worden, is deze wetenschappelijke benadering belangrijk om verschillen correct te interpreteren.

Veelgebruikte experimenten:

A/B tests – Vergelijken de respons op twee versies van een product die verschillen in één variabele. Versie A is meestal de bestaande versie, ook wel controleversie genoemd. Versie B bevat de variant die we willen testen – bijvoorbeeld andere knoptekst of een nieuw ontwerp. Door twee willekeurig gekozen groepen gebruikers bloot te stellen aan versie A en B van het product, kunnen we gedragsverschillen meten, zoals de klikfrequentie op een knop. Statistische significantie toont aan of het verschil waarschijnlijk door de verandering komt en niet door toeval (bijv. 95% zekerheid betekent 5% kans op toeval).
A/B/n tests – Zoals A/B tests, maar dan met meerdere varianten B, C, D… die wel of niet dezelfde variabele testen.
Multivariate tests – Testen meerdere variabelen tegelijk – bijvoorbeeld de vorm, kleur en tekst op een knop. Door alle of een selectie van combinaties te testen, kan worden vastgesteld welke het beste resultaat oplevert. Deze methode vereist veel data en maakt het moeilijker om statistische significantie te bereiken.

Experimenteer om zeker te weten dat een effect echt door ons idee komt – en niet door toeval of externe factoren.

R – Release

Zelfs na uitgebreide tests en experimenten blijft het cruciaal om te blijven leren tijdens én na de release. De ‘R’ in AFTER benadrukt dat de lancering – het moment waarop een product live gaat – geen eindpunt is, maar het begin van een nieuwe validatiefase.

Veelgebruikte release tests:

% Launch – Bij geleidelijke uitrol van een productwijziging naar alle gebruikers kan ervoor worden gekozen om bij een bepaald uitrolpercentage – bijvoorbeeld 25% – tijdelijk te stoppen en een grootschalige A/B-test uit te voeren om eerdere resultaten te bevestigen.
Holdback – Wanneer de volledige uitrol bijna is voltooid, kunnen we ervoor kiezen om een kleine groep gebruikers de oude versie te laten gebruiken, zodat we de effecten van de verandering in de loop van de tijd kunnen blijven monitoren.
Post launch – Als de validatie goed is uitgevoerd, komen we na de lancering zelden voor verrassingen te staan – al blijft er altijd een kleine kans dat er toch iets belangrijks over het hoofd is gezien. Het is daarom verstandig om de resultaten van de lancering gedurende meerdere maanden te blijven volgen: gebruik, koopbereidheid, bugmeldingen, gebruikersfeedback, enzovoort.

Zelfs na volledige uitrol is het belangrijk om te blijven monitoren:

Wordt het gebruikt zoals verwacht?
Blijven gebruikers terugkomen?
Wat zegt support of feedback?

Soms is het nodig een release deels of volledig terug te draaien als blijkt dat het negatieve effecten heeft.

De release laat ons zien of het echt werkt – pas als gebruikers het gebruiken.

Hoe passen we het AFTER-model slim en efficiënt toe?

We zullen niet alle vijf soorten onderzoek toepassen op elk idee – dat zou veel te tijdrovend zijn. Het AFTER-model functioneert als een trechter met drempels, waarin ideeën stapsgewijs worden getoetst. Niet elk idee komt door de volledige trechter heen – en dat is precies de bedoeling.

De eerste twee fasen, Assessment en Fact Finding, zijn snel, goedkoop en laagdrempelig. Ze kunnen eenvoudig worden toegepast op meerdere ideeën tegelijk. In deze vroege fase merken we vaak dat de meeste ideeën niet de verwachte potentie hebben. Dergelijke ideeën wijzen we af of parkeren we voor later, om ze eventueel op een ander moment opnieuw te evalueren.

Een kleiner deel van de ideeën doorstaat deze eerste toetsing en gaat door naar de volgende laag in de trechter: testen en experimenteren, bijvoorbeeld met prototypes of MVP’s. Hier toetsen we hoe gebruikers reageren op een concretere invulling van het idee.

Alleen de ideeën die sterke, onderbouwde signalen van waarde en haalbaarheid laten zien, bereiken de laatste fase van AFTER: Release. In deze fase ronden we de ontwikkeling van de productwijziging af zodat deze klaar is voor productie, waarna we beginnen met een geleidelijke uitrol en de resultaten observeren. We beschouwen de lancering – het live zetten van het product – als een testmoment, waarna we via een uitrol in fases verder leren en bijsturen. In sommige gevallen kiezen we er zelfs voor om een gedeeltelijk of volledig uitgerold idee terug te draaien vanwege negatieve resultaten – vaak om het te verbeteren en later opnieuw te lanceren.

Goedkope, laagrisico-ideeën kunnen relatief snel door het proces heen. Dure, risicovolle ideeën vragen meer validatie, maar dat betekent niet per se dat ze trager tot uitvoering komen. Terwijl we ideeën valideren, ontwikkelen we ze namelijk ook – en vaak ontdekken we in dat proces hoe we de scope kunnen verkleinen of versimpelen, waardoor we ze juist sneller kunnen uitrollen.

AFTER helpt ons om focus aan te brengen, keuzes te onderbouwen en continu te blijven leren – over onze gebruikers, de markt en wat in de praktijk werkt. Dankzij het model prioriteren we slimmer en nemen we beter onderbouwde beslissingen, zonder méér werk.

Niet alles wat meetbaar is, is overtuigend bewijs?

Niet elk bewijs weegt even zwaar. Toch overschatten teams vaak hoe overtuigend hun testresultaten zijn. Itamar Gilad adviseert daarom om drie vragen te stellen zodra je resultaten binnen zijn:

Zijn de resultaten betrouwbaar? – Zijn er bugs, een gebrekkige testopzet of andere factoren die de data vertekenen – zoals seizoensinvloeden of een marketingcampagne? Dan is het beter om de test te herhalen.
Zijn de resultaten positief, negatief of neutraal? – Een stijging van 1% in conversie klinkt misschien goed, maar is dat ook zo? En wat betekent het als slechts 17% van de gebruikers positief reageert op een nieuwe functie? De interpretatie is zelden zwart-wit – daarom is het slim om resultaten in context te plaatsen en te vergelijken met alternatieven.
Hoe sterk is het bewijs? – Enkele enthousiaste reacties leveren nog geen harde onderbouwing op. Pas als gebruikers de feature herhaaldelijk gebruiken, er geld voor willen betalen of massaal terugkomen, spreken we van sterke signalen. Gilad introduceert hiervoor de Confidence Meter: een schaal van 0 tot 10 waarmee je de kracht van je bewijs inschat.

Hoe sterker het bewijs, hoe meer vertrouwen je mag hebben om door te bouwen of te lanceren. Twijfel je? Verzamel beter bewijs – of heroverweeg het idee.

Slot – Van delivery-focus naar evidence-focus

De afgelopen jaren hebben veel organisaties een transformatie doorgemaakt naar een andere manier van werken – vaak in de vorm van agile. Ze hebben nieuwe samenwerkingsvormen en frameworks omarmd, en primair hun delivery-processen verbeterd. In veel organisaties wordt succes nog te vaak gezien als voorspelbaar sturen op output, in plaats van werken vanuit doelstellingen: de gewenste klantuitkomsten en meetbare impact voor de organisatie. Er is een opmerkelijke disconnect tussen de strategische doelen van een organisatie en de dagelijkse operatie. Juist daarom is de noodzaak voor evidence-guided productontwikkeling urgenter dan ooit.

Organisaties die wél impact maken, kiezen bewust voor een andere benadering: ze werken vanuit heldere doelen, stellen scherpere vragen en bouwen gericht aan oplossingen waarvan ze wéten dat die het verschil maken. Ze vertrouwen minder op meningen en dwingende leiders, en juist meer op bewijs. Zo maken ze productontwikkeling opnieuw tot een strategisch vak – een vak waarin we systematisch leren wat werkt, en wat niet.

Wil je als productteam echt impact maken? Zet dan niet in op wat je dénkt dat werkt, maar op wat je zéker weet – met bewijs als je kompas.

Bronvermelding

Gilad, I. (2023). Evidence-Guided: Creating High-Impact Products in the Face of Uncertainty. Independently published.
Cagan, M. (2018). Inspired: How to Create Tech Products Customers Love (2nd ed.). Wiley.

Heb je een vraag of zoek je hulp bij het toepassen van deze aanpak in de praktijk? Neem dan gerust contact op!