Zo structureer je een productdiscoveryfase die bouwrisico echt vermindert

De meeste digitale producten mislukken niet in de bouw. Ze mislukken in de week voor de bouw begint, als aannames als feiten worden behandeld en scope wordt vastgesteld zonder dat iemand echt heeft getoetst of de richting klopt.

Een discoveryfase lost dat op, maar alleen als hij goed is ingericht. Bij Livewall zien we regelmatig dat teams de discovery overslaan omdat die 'te lang duurt', en vervolgens drie maanden later opnieuw beginnen met een product dat niet aansluit. Vier weken goed discovery-werk betaalt zich altijd terug.

Wat een discoveryfase eigenlijk moet opleveren

Discovery is geen onderzoeksproject. Het is een besluitvormingsproces. Aan het einde wil je drie dingen weten: wat het werkelijke probleem is dat je oplost, voor wie je het oplost, en wat de eenvoudigste oplossing is die je kunt bouwen om dat te valideren.

Als je discovery eindigt met een stapel inzichten maar geen heldere richting, heeft de fase zijn werk niet gedaan. De output moet zijn: een afgebakende scope, een rapid prototyping-plan en een lijst aannames die je in de eerste bouwsprint wilt weerleggen.

Week 1: begrijp het probleem, niet de oplossing

De eerste week gaat over het scherp krijgen van het echte probleem. Dat klinkt voor de hand liggend, maar in de praktijk start het gesprek bijna altijd bij een oplossing. 'We willen een app bouwen die X doet.' Die aanname meteen loslaten is de eerste taak van de discoveryfase.

Concreet: voer minimaal vijf gesprekken met echte eindgebruikers. Geen surveys, geen focusgroepen, gewoon gesprekken. Vraag wat ze nu doen als ze het probleem tegenkomen, hoe ze dat oplossen, en wat ze daarin frustrerend vinden. Schrijf letterlijk op wat ze zeggen, niet jouw interpretatie.

Tegel dat met een stakeholderanalyse. Wie heeft er belang bij dit product? Wat zijn hun succescriteria? Waar zitten de conflicten? Veel producten stranden later op interne meningsverschillen die in week één al zichtbaar waren, maar niet zijn geadresseerd.

Aan het eind van week één wil je één heldere probleemstelling op papier. Eén zin. Als je team het niet eens is over die zin, is dat precies de informatie die je nodig had.

Week 2: verken de oplossingsruimte snel

Met een scherpe probleemstelling kun je nu oplossingsrichtingen verkennen. Niet één richting, maar drie tot vijf. Het doel is niet om ze allemaal even serieus te nemen, maar om snel onderscheid te maken.

Laat ontwerpers en developers samen schetsen. Niet in tools, op papier. Bespreek de technische haalbaarheid van elke richting in maximaal dertig minuten per optie. Schrap alles wat langer dan twaalf weken bouwwerk vereist voordat je iets kunt valideren.

Dit is ook het moment voor een snelle UX/UI-designsessie. Niet om visuals te maken, maar om te ontdekken waar de complexiteit zit. Welke schermen zijn eigenlijk lastig? Welke gebruikersflow heeft de meeste afhankelijkheden? Die antwoorden veranderen je scopekeuze.

Aan het eind van week twee kies je één richting. Niet de beste richting, maar de richting die je het snelst kunt testen.

Week 3: bouw een prototype, geen product

Week drie is waar veel teams de fout in gaan. Ze beginnen te bouwen. Echte code, echte infrastructuur, echte databases. Dat is te vroeg.

Wat je nodig hebt is een prototype dat goed genoeg is om van echte gebruikers een echte reactie te krijgen. Dat kan een klikbaar Figma-prototype zijn. Het kan een eenvoudige HTML-pagina zijn zonder backend. Het kan een video walkthrough zijn. Het criterium is niet 'werkt het technisch', maar 'kan ik hiermee een aanname testen'.

Bij Livewall passen we rapid prototyping toe om in twee tot drie dagen een testbaar prototype neer te zetten. De waarde is niet het prototype zelf, maar de gesprekken die het uitlokt. Gebruikers reageren anders op iets wat ze kunnen zien en aanraken dan op een beschrijving in een document.

Prototype met je riskantste aanname. Wat is de ene gedachte waarvan je hoopt dat die klopt, maar die je eigenlijk nog niet weet? Bouw het prototype daar omheen.

Week 4: test, documenteer, besluit

De laatste week is voor gebruikerstesten en het vastleggen van beslissingen. Zet minimaal vijf testgesprekken op, gebruik het prototype uit week drie en observeer. Stel geen leidende vragen. Kijk waar mensen vastlopen, wat ze verkeerd begrijpen en wat ze verrassend goed oppakken.

De uitkomst is niet een rapport. De uitkomst is een set beslissingen: wat zit er in scope voor de eerste bouwfase, wat parkeren we voor later, welke aannames zijn weerlegd en welke zijn bevestigd.

Schrijf ook de belangrijkste principes op die je hebt geleerd. Niet als academische bevindingen, maar als richtlijnen voor het bouwteam. 'Gebruikers verwachten dat X direct beschikbaar is, niet achter een registratiescherm.' Dat soort zinnen voorkomen honderden kleine verkeerde beslissingen later in het project.

Een goed voorbeeld van dit soort grondige voorbereiding is het Sportvisunie-platform, een community platform voor sportvissers. De discoveryfase legde de basis voor een platform dat aansloot op hoe sportvissers daadwerkelijk kennis delen, niet hoe de opdrachtgever veronderstelde dat ze dat deden.

De meest gemaakte fout in discovery

De grootste valkuil is discovery behandelen als een validatiefase voor beslissingen die al genomen zijn. Je gaat gebruikers pas spreken nadat de oplossingsrichting al vaststaat. Je bouwt een prototype van wat je toch al wilde bouwen.

Discovery werkt alleen als er een echte bereidheid is om van richting te veranderen. Als de uitkomst van week vier identiek is aan het voorstel van vóór week één, is er iets misgegaan.

Bij Livewall bouwen we digitale producten waarbij de discoveryfase altijd onderdeel is van het proces. Niet als formaliteit, maar als het moment waarop de kans op een goed product het grootst is. Hoe korter de bouwfase, hoe belangrijker het is dat discovery goed wordt uitgevoerd.