Product Discovery: Iets langzamer beginnen, veel sneller leveren
We houden allemaal van een snelle lancering. Het gevaar is niet de snelheid, maar het feit dat je begint zonder een gezamenlijk beeld van waar het product uit kan groeien. Op dat moment is "we voegen het later toe" geen plan meer, maar een renovatie.
Waar platformen breken zonder product discovery
Product discovery is de stap die de meeste teams overslaan—en achteraf betreuren. Een slanke eerste versie van een platform of aangepaste webapplicatie werkt prima. Dan komt het echte leven.
Een klant vraagt om abonnementen in plaats van eenmalige betalingen.
Een partnerprogramma vereist verschillende machtigingen voor verkopers en managers.
Een goedkeuringsstap sluipt in een workflow die eerst “creëren → publiceren” was.
Beveiliging vraagt om SSO (Google/Microsoft) en multi-factor authenticatie.
Marketing wil betrouwbare analyses, niet alleen een snelle export.
Geen van deze verzoeken zijn exotisch—ze zijn de natuurlijke evolutie van de meeste SaaS-producten en digitale platforms. Het probleem is dat ze allemaal raken aan de basis: bestellingen, machtigingen, workflows, datatracking, authenticatie.
Als daar niet vanaf het begin rekening mee is gehouden, ben je niet bezig met het “toevoegen van een functie”; je bent de muren aan het openbreken.
De kosten van discovery overslaan
Elke kortere weg in het begin wordt uiteindelijk duur. Voor webbureaus en productteams komen die kosten tot uiting in gemiste deadlines, hogere ontwikkelfacturen en gefrustreerde belanghebbenden. Barry Boehm heeft dit patroon in 1981 in cijfers gevangen: een wijziging die tijdens requirements wordt opgemerkt kost ongeveer 1 eenheid; dezelfde wijziging in productie kost er 100. Veertig jaar softwareprojecten hebben die curve steeds opnieuw bevestigd.
Daarom loont een helder afgebakende opdracht al ver voor de eerste regel code — de goedkoopste tijd om van gedachten te veranderen is wanneer nog niets gebouwd is.
De rails vroeg zetten
Voordat we beginnen met ontwerpen en bouwen, staan we even stil—niet om een specificatie van 200 pagina’s te schrijven, maar om de rails te bepalen waarop het product zal draaien. Dit is hoe een product-discoveryfase er in de praktijk uitziet:
Voor wie is het product echt bedoeld en wat moet moeiteloos kunnen?
Welke records zullen nog jaren meegaan?
Welke gebeurtenissen en statistieken zullen er later toe doen?
Welke waarschijnlijke wendingen (abonnementen, partnerrollen, goedkeuringen, integraties) hebben ruimte nodig in de fundering?
Welke standaard manier gaan we gebruiken om systemen van derden te verbinden, zodat de volgende integratie soepel verloopt?
Deze stap—korte discovery en softwarearchitectuurplanning—duurt doorgaans een tot twee weken. Het betaalt zich terug bij elke functie die volgt. Wanneer een team bij ons komt voor MVP-ontwikkeling, staat de discoveryfase als eerste op het plan, niet als optionele toevoeging.
Wat een discoveryfase oplevert
Discovery is geen vergaderen; het is een korte opdracht die werkende artefacten oplevert. Aan het eind van één tot twee weken krijg je:
Architectuurschets — de technische vorm van het platform in 4–6 pagina’s: datamodel-schets, integratiegrenzen, beslissingen die we aanraden uit te stellen.
Datamodel-concept — entiteiten, relaties en de velden die stabiel moeten blijven over toekomstige functies heen.
Risicolijst — 5–10 niet voor de hand liggende risico’s voor jouw domein, elk met een mitigatie.
Bouwplan — een gefaseerde roadmap waarbij de eerste release de tweede niet blokkeert.
Eerlijke schatting — tijd- en kostenmarges voor de eerste release, onderbouwd door de architectuur erboven.
Alles is zo geschreven dat een niet-technische stakeholder het kan lezen — geen diagrammen om de diagrammen.
Hoe ziet een discovery van twee weken eruit
Discovery heeft een ritme. Twee weken is genoeg tijd om de structurele vragen te beantwoorden zonder de bouw op te houden.
| Dagen | Focus | Oplevering |
|---|---|---|
| 1–3 | Gebruikers, inkomstenstroom, harde randvoorwaarden | Gebruikersrollen, jobs-to-be-done, businessbeperkingen |
| 4–6 | Datamodel en event-model | Concept-schema, event-catalogus, bewaarregels |
| 7–9 | Integraties en architectuurbeslissingen | Integratiemap, techkeuzes, lijst uitgestelde beslissingen |
| 10 | Plan, schatting, risicoreview | Gefaseerd bouwplan, kostenmarge, top-risico’s met mitigaties |
Wat gebeurt er als de architectuur standhoudt
Toekomstige ideeën zijn geen ontsporingen meer.
Een abonnementsaanvraag wordt een nieuwe wagon op de trein, geen nieuw spoor.
Een partnerrol is slechts een configuratie, geen herschrijving.
Een goedkeuringsstap is een status in een flow, geen rommelige workaround.
Zelfs wanneer plannen veranderen (en dat zal gebeuren), blijft de kernarchitectuur van het platform behouden. Het team kan zich richten op het sneller leveren van functies in plaats van op het uitvoeren van operaties.
Met discovery vs zonder: naast elkaar
Twee teams leveren dezelfde MVP op — één met een discovery van twee weken, één zonder — en gaan snel uit elkaar zodra de echte verzoeken binnenkomen.
| Moment in het project | Zonder discovery | Met discovery |
|---|---|---|
| Klant vraagt om abonnementen | Facturatie, auth en rechten herschrijven | Vlag omzetten — schema ondersteunt het al |
| Partnerprogramma vereist rollen | Rechten achteraf door elk scherm vlechten | Rol toevoegen — rechten zijn policy-gedreven |
| SSO/MFA verplicht | Authenticatie vervangen, alle gebruikers migreren | Identity provider wisselen — sessiemodel al afgescheiden |
| Eerste analytics-vraag | Events achteraf uit logs halen, kwaliteit inboeten | Events vanaf dag één vastgelegd — geen backfill nodig |
Waarom een korte discovery tijd bespaart
Het doel is niet om de toekomst perfect te voorspellen. Het is om de softwarearchitectuur vanaf dag één te ontwerpen voor flexibiliteit. Door een week of twee te vertragen aan het begin, vermijd je maanden herwerk later—en lanceer je een product dat daadwerkelijk kan meegroeien met je bedrijf.
Wanneer we een project overnemen dat nooit een discoveryfase heeft gehad, begint de oplossing meestal met een externe projectaudit — waarbij we de huidige architectuur vergelijken met de richting die het product echt op moet. De audit alleen betaalt vaak een jaar ontwikkeling terug door de verkeerde herbouw te voorkomen.
Veelgestelde vragen over product discovery
Veelvoorkomende vragen die we krijgen wanneer we een discoveryfase voorstellen — beantwoord in de FAQ hieronder.
Hoe lang duurt een product-discoveryfase eigenlijk?
Eén tot twee weken voor de meeste SaaS- en maatwerk-webprojecten. Geen specificatie van 200 pagina's — een gerichte set antwoorden over gebruikers, datamodel, waarschijnlijke evoluties en integratiegrenzen. Duurt het langer, dan moet meestal de projectscope worden ingekort, niet de discovery worden opgerekt.
Is discovery de moeite waard voor een kleine MVP?
Ja — en hoe kleiner het team, hoe belangrijker. Een kleine MVP wordt later uitgebreid door iemand die niet bij het oorspronkelijke gesprek was; discovery zet het mentale model van de oprichter om in iets dat de volgende ontwikkelaar kan lezen. De fase kan korter zijn (3–5 dagen voor een strakke MVP), maar volledig overslaan is waar de meeste herbouwprojecten beginnen.
Wat levert een product-discoveryfase op?
Een gedeeld beeld van het product: voor wie het is, welke records en gebeurtenissen op lange termijn belangrijk zijn, welke toekomstige wendingen (abonnementen, rollen, goedkeuringen, integraties) ruimte in de fundering nodig hebben, en een standaardmanier om externe systemen te koppelen. Concreet: een korte geschreven architectuurschets, een datamodelschets en een korte lijst niet voor de hand liggende risico's — genoeg om te beginnen bouwen zonder elke beslissing opnieuw te bevragen.
Kunnen we discovery doen zonder de volledige bouw toe te zeggen?
Ja. We leveren discovery als losse opdracht — je krijgt de architectuurschets, het datamodel en de risicolijst, en je bent vrij om met ons te bouwen, met een ander team of het project te parkeren. Een apart discoverycontract beschermt beide partijen: jij betaalt niet voor een bouw die we niet hebben afgebakend, en wij verbinden ons niet aan een bouw die we niet eerlijk kunnen inschatten.
Begin met discovery
Denk je na over eenproduct
dat het lang moet uithouden?
Vertel ons wat je bouwt. We reageren binnen één werkdag met de vraag of een discoveryfase van 1–2 weken de juiste volgende stap is — of dat je al genoeg hebt om te beginnen met bouwen.