Een ondernemer stelt een vraag. “Kan dit?”

De verleiding is om meteen in oplossingen te springen: welke software bestaat ervoor, wat zou ontwikkeling kosten, wie kan dit bouwen. Allemaal vragen die op een bepaald moment relevant worden — alleen niet als eerste. Tussen een klant die iets vraagt en een product dat de moeite waard is om te bouwen of te verkopen, zitten nogal wat stappen.

Een klant beschrijft bovendien zelden een productprobleem. Hij beschrijft wat hij vandaag mist. Wie een app vraagt, is misschien vooral een proces beu dat via vijf mails en drie spreadsheets loopt. Wie een eigen platform wil, is dikwijls minder geïnteresseerd in technologie dan in marge, klantdata of controle over de klantrelatie. En wie een functie noemt die hij kent van een groot platform, bedoelt soms alleen het effect van die functie — niet de functie zelf.

Neem je de gevraagde oplossing letterlijk, dan kun je perfect bouwen wat gevraagd werd en toch het verkeerde probleem oplossen.

Daarom trek ik zo’n vraag eerst uit elkaar. Wat moet de eindklant werkelijk kunnen? Wat moet intern gebeuren om dat mogelijk te maken? Wat moet realtime zijn, en wat helemaal niet? En welke afhankelijkheid wil de ondernemer precies kwijt — en welke nieuwe koopt hij zich daarvoor in de plaats?

Pas als dat scherper staat, wordt technologie interessant. En zelfs dan vind ik “het kan” een mager antwoord. Bijna alles kan gebouwd worden als tijd en budget geen rol spelen. De zakelijke vraag is of het zinvol kan. Bestaat er al iets dat een groot deel van het probleem oplost? Kunnen twee bestaande systemen samen doen wat één nieuw systeem zou moeten doen? Wie moet het dagelijks bedienen, en wat gebeurt er wanneer iets misloopt? En blijft het voordeel groter dan de complexiteit die je ervoor toevoegt?

Daar begint opportunity validation voor mij: niet bewijzen dat het eerste idee goed was, maar proberen te ontdekken waarom het misschien géén goed idee is. Dat klinkt negatiever dan het is. Een opportuniteit die na stevige tegenvragen overeind blijft, wordt alleen maar interessanter. En een idee dat tijdens die oefening sneuvelt, kost veel minder dan een idee dat sneuvelt nadat er maanden ontwikkeling, leveranciersgesprekken en interne verwachtingen aan vasthangen.

Soms verandert de vraag onderweg volledig. Je vertrekt van de veronderstelling dat er één geïntegreerd platform nodig is en ontdekt dat twee gespecialiseerde systemen samen beter werken. Of je leest bij een leverancier een featurenaam die precies lijkt te dekken wat je zoekt, en stelt bij navraag vast dat hij iets veel beperkters bedoelt. Dat zijn geen details: als precies die eigenschap de reden was om aan het onderzoek te beginnen, valt of staat de opportuniteit ermee.

Daarom breng ik claims zo snel mogelijk terug naar wat aantoonbaar is. "De leverancier ondersteunt dit" zegt op zich weinig: wie ziet wat, op welk scherm, op basis van welke data? En dat er een API is, wordt pas interessant als die toegang geeft tot precies de data en acties die nodig zijn. Een featurelijst vertelt meestal minder dan ze lijkt.

Hetzelfde geldt voor concurrentieonderzoek. Dat er al vijf spelers bestaan, bewijst niet dat een idee dood is. En dat niemand exact hetzelfde aanbiedt, betekent nog niet dat je een gat in de markt hebt gevonden — misschien is het gat er omdat niemand het nodig heeft, of omdat het economisch niet werkt. Misschien ligt er wél ruimte. Maar dat is een conclusie, geen vertrekpunt.

Daarom is product discovery voor mij een vorm van business development. Niet omdat er meteen iets verkocht moet worden, maar omdat je commerciële mogelijkheden probeert te begrijpen vóór je middelen vastlegt. Waar zit de waarde? Wie zou ervoor betalen? Welk bestaand alternatief moet je verslaan, en wat moet daarvoor aantoonbaar beter zijn? Wat kun je inkopen, en wat moet je zelf bezitten?

De volgende stap kan dan een prototype zijn, een leveranciersgesprek, een kleine marktvalidatie of een financiële oefening. Of gewoon: stoppen. Dat laatste wordt te weinig als resultaat gezien. Ik vind het een van de nuttigste uitkomsten die er zijn. Niet elke opportuniteit verdient een roadmap; sommige verdienen een snelle, goed onderbouwde nee. Andere komen na onderzoek terug in een vorm die eenvoudiger, goedkoper of interessanter is dan het oorspronkelijke idee. En een kleine groep blijft na alle tegenvragen overeind. Daar wil ik verder mee.

Een goede productvraag begint dus niet met “hoe bouwen we dit?”, maar met: welk probleem lossen we hier werkelijk op — en wat moet waar zijn vooraleer dit een opportuniteit is?

Update — wat deze case intussen duidelijker maakte

Sinds de eerste versie van dit stuk is de onderliggende case verder gegaan. De brede vraag — moeten we hiervoor iets nieuws bouwen? — is intussen een stuk smaller geworden.

Verschillende pistes zijn afgevallen. Niet omdat het slechte systemen waren, maar omdat precies het onderdeel waarvoor het onderzoek begon niet aantoonbaar aanwezig was. Marketingtermen bleken rekbaarder dan wat er effectief achter zat.

Wat overblijft is één veel concretere vraag: kan een combinatie van bestaande systemen leveren wat gevraagd wordt, zonder dat er opnieuw maatwerk gebouwd moet worden?

Dat is een betere uitkomst dan een vroege “go”. Discovery hoeft niet te eindigen in een nieuw product. Bouwen, kopen, combineren, samenwerken of stoppen zijn allemaal geldige uitkomsten, zolang de beslissing die volgt kleiner en beter onderbouwd is dan de vraag waarmee je begon.

De vraag verschuift dan van “wat bestaat er allemaal?” naar: wat moet deze ene piste nog bewijzen vooraleer we er tijd en geld aan koppelen?