Skip to main content

Productontdekking is het proces van het begrijpen van je gebruikers, het identificeren van hun pijnpunten en het bedenken van oplossingen waarvan je weet dat ze hen zullen helpen.

Afhankelijk van de kwaliteit van je ontdekkingsproces maak of breek je je bedrijf. De logica is eenvoudig. Met een goede productontdekking bouw je uiteindelijk functies waar mensen behoefte aan hebben en waarvoor ze betalen. Een slechte productontdekking gaat er daarentegen van uit dat er voortdurend nieuwe functies nodig zijn waar niemand op zit te wachten.

Dit kan erg overweldigend lijken, vooral gezien de hoeveelheid input bij productontdekking. Maar er is een goed systeem beschikbaar om deze kritieke taak aan te pakken met verschillende hulpmiddelen en raamwerken.

Want more from The CPO Club?

Sign up for a free membership to complete reading this article:

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Laten we dus begrijpen wat productontdekking is en hoe je dit goed uitvoert.

Wat is productontdekking?

Productontdekking is het proces van het begrijpen van de pijnpunten van je gebruikers en het bedenken van haalbare oplossingen om deze aan te pakken.

Dit proces verschilt meestal sterk van de manier waarop je belanghebbenden het zich voorstellen. Voor velen van hen draait het om creatief denken en één keer een lijst met interessante ideeën voor functies bedenken, om het product vervolgens op basis van die lijst te bouwen.

Deze manier van denken is op 2 belangrijke punten onjuist:

  • Ontdekking is een eindeloos en iteratief proces. Je voltooit het ontdekkingsproces niet; je voltooit een cyclus ervan en begint aan de volgende.
  • Ontdekking draait niet om het op creatieve wijze bedenken van interessante ideeën. Het gaat om het begrijpen van gebruikersbehoeften, het aandragen van oplossingen die deze kunnen verhelpen en vervolgens valideren dat deze oplossingen daadwerkelijk werken.

Een andere veelvoorkomende misvatting gaat over de relatie tussen ontdekking en oplevering. Veel belanghebbenden zien dit als twee afzonderlijke fasen die na elkaar komen. In werkelijkheid voeren effectieve productontwikkelingsteams ontdekking en oplevering parallel uit. Terwijl je team de functies oplevert die je 2 maanden geleden hebt ontdekt, voer je een ontdekkingsproces uit voor de volgende reeks functies.

Visueel:

  • Diagram met gescheiden paden voor “Ontdekking versus oplevering”. Visualiseer dit idee: teams voeren ontdekking en oplevering parallel uit. Terwijl je team de functies oplevert die je 2 maanden geleden hebt ontdekt, voer je een ontdekkingsproces uit voor de volgende reeks functies.
  • Alt: “Parallelle sporen die voortdurende ontdekking en oplevering weergeven.”
  • Bijschrift: “Productontdekking is geen eenmalige gebeurtenis — het vindt gelijktijdig met de oplevering plaats.”

Zelfs als je actief bent in een markt waar watervalontwikkeling de norm is en ontdekking vóór oplevering plaatsvindt, is het altijd belangrijk om al je aandacht aan ontdekking te besteden, omdat de kwaliteit ervan rechtstreeks van invloed is op het succes van het product.

Waarom ontdekking een concurrentievoordeel is

Het korte antwoord luidt als volgt. Met ontdekking begrijp je je persona’s en gebruikersbehoeften beter en kom je met effectieve oplossingen. Effectieve oplossingen maken je tot een sterke concurrent op de markt, omdat je snel klanten aantrekt en ze gemakkelijk behoudt.

De video bestaat niet.

Voor het lange antwoord kijken we naar Inspired van Marty Cagan. In het boek wijst Marty erop dat effectieve ontdekking je kan helpen 4 soorten risico’s te beperken:

  • Waarderisico verwijst naar de kans dat mensen je product niet gebruiken omdat het voor hen geen betekenis heeft.
  • Gebruiksvriendelijkheidsrisico verwijst naar het feit dat mensen moeite hebben om je product te gebruiken.
  • Haalbaarheidsrisico verwijst naar het feit dat je team niet in staat is het te bouwen.
  • Levensvatbaarheidsrisico verwijst naar de mate waarin het product je bedrijf helpt te overleven en te groeien.

Als je ervan uitgaat dat je al deze risico’s kunt beperken en je concurrenten bij een of meer ervan tekortschieten, krijg je een sterk concurrentievoordeel en de kans om een groter deel van de markt in handen te krijgen.

Tiny Speck is een goed voorbeeld van dit idee. Het was een gameontwikkelingsbedrijf dat een online MMORPG-game bouwde die jammerlijk mislukte. Het probleem: ze bouwden een game door simpelweg ideeën van anderen te kopiëren (ook wel de Factory Trap genoemd), zonder de behoeften van de gamerdoelgroep goed te begrijpen.

Het bedrijf stopte al snel met deze game en bracht in plaats daarvan zijn interne communicatietool uit. Juist, dat was Slack.

Hetzelfde bedrijf is dus ook een goed voorbeeld van productsucces dankzij grondige ontdekking. In tegenstelling tot bij hun game voerde het Slack-team eindeloze ontdekkingsiteraties uit en had het een zeer duidelijk begrip van de behoeften van zijn gebruikers.

4 belangrijke vragen over productontdekking

Als we de essentie van productverkenning willen begrijpen zonder te verdwalen in de details, kunnen we kijken naar deze 4 vragen die het probeert te beantwoorden.

  • Is er een echt probleem? Dat klopt, soms loop je het risico een oplossing te creëren op zoek naar een probleem. Hallo, 90% van alle door ChatGPT aangedreven startups ;)
  • Kunnen we het oplossen? Soms zit het probleem in de complexiteit van de oplossing. S.T.A.L.K.E.R. is een Oekraïense videogameserie die met dit probleem te maken kreeg. Ze wilden A-life bouwen, hun AI-systeem dat de levens van NPC's en dieren in de game volledig simuleerde. Maar het probleem was simpelweg te complex om op te lossen.
  • Moeten we het oplossen? Soms is het probleem er wel, maar is het niet groot genoeg om er een product voor te ontwikkelen. Google Glass is daar een goed voorbeeld van. Ja, het was cool, maar als Google Glass niet had bestaan, zou het leven voor niemand minder gemakkelijk zijn geweest.
  • Kunnen we het effectief leveren? Deze vraag gaat meer over de operationele kant van productontwikkeling en je vermogen om op te schalen en je gebruikers te ondersteunen. YouTube stond in de beginperiode dicht bij een mislukking vanwege het onvermogen om op te schalen.

Wat je tijdens productverkenning in wezen doet, is verschillende hulpmiddelen en raamwerken gebruiken om inzichten te verkrijgen, zodat je deze vragen kunt beantwoorden.

Raamwerken om verkenning te structureren

Je zou kunnen aanvoeren dat een ervaren productmanager verkenning kan uitvoeren zonder een draaiboek of raamwerk te gebruiken. Dat klopt. Maar er is een reden waarom we raamwerken voor productverkenning hebben. Ze zorgen voor structuur en voorspelbaarheid in je verkenningsproces.

Wat de raamwerken zelf betreft, laten we naar deze 5 kijken:

Agile met twee sporen: Dit is het proces waarbij twee parallelle processen worden uitgevoerd binnen agileontwikkeling. Je hebt het verkenningsspoor, dat ideeën voor functies creëert, en het leveringsspoor, dat deze ontwerpt en bouwt.

Visuele weergave van verkenning en levering die parallel verlopen bij agileontwikkeling met twee sporen
Je rondt verkenning niet af om daarna met levering te beginnen; ze vinden parallel plaats

ProductBoard en Jira zijn meestal de hulpmiddelen die ik gebruik om dit raamwerk te beheren.

Boom voor kansen en oplossingen: Hier zullen we later nog wat uitgebreider over praten. Maar kort gezegd stelt dit raamwerk je in staat een boomstructuur te maken waarvan de kernuitkomst de wortel vormt. Vanuit deze wortel creëer je kansen om pijnpunten als takken op te lossen. Vervolgens creëer je voor elke kans takken met mogelijke oplossingen.

Miro heeft geweldige sjablonen voor bomen met kansen en oplossingen die je kunt gebruiken.

Verkenningssprint: Dit raamwerk is geïnspireerd op Google's geesteskind, de ontwerpsprint. Het maakt snelle iteraties op oplossingen mogelijk. Je krijgt ongeveer 2 weken om gebruikersinterviews uit te voeren, een oplossing te bedenken, het prototype te bouwen en het te testen.

Doorlopende verkenning: In tegenstelling tot de vorige drie, waarbij je iteraties met een duidelijk begin en einde hebt, kent doorlopende verkenning geen einde. Je voert eenvoudigweg eindeloze rondes interviews met je doelgroep uit, creëert voortdurend oplossingen en test deze.

Hier is een vergelijking van deze raamwerken naast elkaar.

RaamwerkOrganisatiegrootteFrequentie van verkenningRisicobereidheid
Agile met twee sporenGemiddeld tot grootDoorlopendGemiddeld
Boom voor kansen en oplossingenKlein tot gemiddeldAd hoc of cyclischLaag tot gemiddeld
VerkenningssprintStartup tot gemiddeldIn tijd afgebakende uitbarstingenHoger
Doorlopende verkenningVolwassen productteamsWekelijks/dagelijksLaag

De keuze van het raamwerk zelf hangt van jou af. Niet elk team heeft evenveel baat bij hetzelfde raamwerk. Gebruik de bovenstaande tabel om er een te kiezen dat aansluit bij de omvang en het tempo van je team, en bij de mate van onzekerheid die het kan verdragen.

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Rollen & teamsamenwerking

Er bestaat een veelvoorkomende misvatting (en een grote valkuil) dat productverkenning alleen om productteams draait.  Hoewel het voornamelijk een activiteit voor productteams is, zal bij een goed verkenningsproces ook betrokkenheid van andere teamleden en belanghebbenden nodig zijn. Zo draagt elk teamlid bij aan de verkenning:

  • Productmanagers: Zij leiden het verkenningsproces, zorgen dat teamleden op één lijn zitten en geven prioriteit aan oplossingen en inzichten.
  • User experience-ontwerp: Zij nemen deel aan gebruikersonderzoek, creëren ontwerpconcepten en klikbare prototypes en voeren bruikbaarheidstests uit.
  • Ontwikkeling: Zij beoordelen de haalbaarheid van oplossingen en wijzen op risico's bij de productlevering.
  • Belanghebbenden: Zij bieden de strategische en zakelijke context op hoofdlijnen.

Zoals we kunnen zien, is de deelname van elk teamlid belangrijk. Dus als je leidinggevenden je vragen of het scrumteam moet deelnemen aan het productverkenningsproces, is je antwoord zonder twijfel ja!

Het productontdekkingsproces

Het begrijpen van de behoeften van je klanten en het bedenken van gevalideerde oplossingen voor hen doet ons denken aan een trechter, waarvan de bovenste lagen veel groter zijn dan de onderste.

Dat is inderdaad het geval bij productontdekking. Je begint met een heleboel inzichten, klachten en opmerkingen van je doelgroep en eindigt met slechts een paar gevalideerde oplossingen waarvan je weet dat ze waarde creëren voor je gebruikers.

Zo ziet dat eruit.

Trechter die smaller wordt van klantinzicht naar gevalideerde oplossing
Een duidelijk proces helpt je om oplossingen te identificeren, te valideren en vol vertrouwen verder te gaan

Laten we het productontdekkingsproces nu wat verder uitsplitsen en de complexiteit van elk onderdeel ervan begrijpen.

Over het algemeen bestaat het productontdekkingsproces uit deze 10 stappen.

Checklist voor productontdekking in tien stappen
Volg dit stapsgewijze proces om risico's te beperken en te bouwen wat ertoe doet

Laten we nu elke stap in detail bekijken.

1. Bekijk je strategische richting opnieuw

Goede functies lossen problemen van gebruikers op. Geweldige functies doen hetzelfde en volgen tegelijkertijd de bredere strategische richting van je product. Voordat je aan productontdekking begint, is het belangrijk om je strategiedocument opnieuw te bekijken en jezelf eraan te herinneren waar je op de lange termijn wilt uitkomen en welke richting je wilt inslaan.

Dit helpt je om je ontdekkingsinspanningen te richten op oplossingen die aansluiten bij je strategie. Anders loop je het risico je te richten op functies die je op de lange termijn nergens brengen. 

2. Noteer je aannames

Een ander belangrijk aspect van productontdekking dat je moet aanpakken voordat je met gebruikers communiceert, zijn je aannames. Het idee is dat je waarschijnlijk veel aannames doet over je markt of gebruikers. Het is belangrijk om deze vast te leggen, zodat je onderzoek niet te veel leunt op de meer gewaagde aannames die je doet.

Hiervoor kun je een aannamematrix maken.

AannameBekend/OnbekendBelang
Gebruikers zullen een AI-stem in DJ-stijl vertrouwenOnbekendHoog
Mensen gebruiken Spotify voornamelijk in passieve modus (luisteren op de achtergrond)BekendHoog
Gebruikers willen hun DJ-personages een naam gevenOnbekendLaag
Podcasts verhogen de tijd die op het platform wordt doorgebrachtBekendGemiddeld
Voorbeeld van een aannamematrix voor Spotify
Dit zijn de realistische en gewaagde aannames voor Spotify

Op deze matrix kun je vertrouwen op de aanname linksboven en moet je voorzichtig zijn met de aannames rechtsboven.

3. Praat met je gebruikers

Zonder deze stap is productontdekking slechts giswerk. Praat met je gebruikers—of loop het risico dat je uiteindelijk het verkeerde bouwt.

Er zijn veel verschillende manieren waarop je met gebruikers kunt praten:

  • Ze bezoeken (bijvoorbeeld naar een ziekenhuis gaan en artsen interviewen).
  • Ze ontmoeten op vakbeurzen (bijvoorbeeld praten met technologiejournalisten op CES).
  • Videogesprekken met hen voeren via Zoom.

Voor de laatste optie kun je verschillende methoden gebruiken, zoals platforms voor deelname aan onderzoek, contact opnemen met je gebruikersbestand of via LinkedIn contact opnemen met je doelgroep met behulp van een Recruiter-account.

4. Analyseer inzichten van gebruikers en gegevens

Bekijk naast samenvattingen van gebruikersinterviews ook je dashboard voor productanalyse en de feedback die je support- en verkoopteams hebben verzameld. Zo haal je inzichten uit meerdere bronnen. En in plaats van eindeloze samenvattingen of transcripties door te lezen, kun je een LLM alles voor je laten verwerken.

Hier is een voorbeeldprompt die je kunt gebruiken:

Je bent een senior softwareproductmanager met 10 jaar ervaring. Je bent uitstekend in het analyseren van de transcripties van je verkoopteam en het identificeren van belangrijke informatie die nuttig zal zijn voor je productonderzoek.
Hier is de transcriptie van het verkoopgesprek
{{sales_transcript}} 
Identificeer op basis van de informatie in de verkooptranscriptie de volgende informatie.
Identificeer het volgende:
1. Belangrijkste pijnpunten: verwijs naar de meest prominente pijnpunten en uitdagingen die de gebruiker ervaart met de huidige tools en processen.
2. Waarom zijn ze in jou geïnteresseerd: verwijst naar de reden waarom het bedrijf nu op zoek is naar een nieuwe tool.
3. Productfeedback: verwijst naar de feedback die het bedrijf aan het verkoopteam heeft gegeven over {{your_product_name}} en de functies ervan toen ze de demo hebben bekeken.

Nadat je de feedback hebt bekeken en deze hebt gecombineerd met inzichten uit gebruikersinterviews en analyses, zul je trends en terugkerende thema’s beginnen te zien.

5. Identificeer pijnpunten van gebruikers binnen je bevindingen

Het identificeren van pijnpunten is niet altijd zo eenvoudig. Het kan inderdaad voorkomen dat 80% van alle gebruikers je vertelt dat een bepaald onderdeel van hun werk lastig is, maar dat betekent niet per se dat het een probleem is dat de moeite waard is om op te lossen. Je moet ook de “intensiteit” van dat pijnpunt begrijpen.

Stel je voor dat 70% van de gebruikers van je socialemediaplatform zegt dat ze zich ergeren aan het aantal meldingen en aan het feit dat je ze niet allemaal als gelezen kunt markeren.

Wanneer je hun feedback combineert met analyses — waaruit blijkt dat 90% van hen gemiddeld 2-3 meldingen per dag ontvangt — kun je inschatten dat deze klacht niet “intens” genoeg is om prioriteit te krijgen in vergelijking met andere punten op je lijst.

6. Bedenk oplossingen voor deze problemen

In deze stap bedenk je mogelijke oplossingen voor de problemen die je hebt geïdentificeerd als resultaat van je klantinterviews en feedbackanalyse.

Je kunt gewoon met je ontwerp- en ontwikkelteams gaan zitten en brainstormen. Maar om ervoor te zorgen dat je oplossingen direct gekoppeld zijn aan een groter bedrijfsdoel of resultaat, kun je het framework voor kansen en oplossingen van Teresa Torres gebruiken. Zo ziet dit eruit voor het pijnpunt van Spotify-gebruikers: “Ik weet niet waar ik naar moet luisteren”.

Voorbeeld van een boom voor kansen en oplossingen voor Spotify
De boom maakt een duidelijk verband zichtbaar tussen het oplossen van het pijnpunt en het verhogen van DAU

Via het boomframework zagen we dat het wegnemen van de barrière “waar moet ik naar luisteren” het aantal dagelijks actieve gebruikers (DAU) zou kunnen verhogen, waardoor dit een probleem met een grote impact werd om op te lossen.

7. Test je oplossingen met prototypes

Het analyseren van gebruikersinzichten en deze omzetten in een lijst met mogelijke functies is slechts het beginpunt. Productontdekking is gebaseerd op de wetenschappelijke methode, wat betekent dat je ideeën moet testen en valideren voordat je ze aan je productroadmap toevoegt.

Je kunt oplossingen in verschillende fasen van hun levenscyclus valideren — van het eenvoudig beschrijven van het idee aan een gebruiker tijdens een interview en het verzamelen van feedback, tot het maken van eenvoudige mock-ups en het vragen van feedback aan focusgroepen over vroege prototypes. Je zou zelfs zover kunnen gaan dat je een minimaal levensvatbaar product (MVP) bouwt en lanceert.

Validatie in een vroege fase, zoals het bespreken van het idee in een interview, is snel en goedkoop, maar de kwaliteit van de klantfeedback kan laag zijn omdat gebruikers moeite kunnen hebben om het concept volledig te begrijpen.

Testen met een MVP levert daarentegen rijkere en nauwkeurigere feedback op, omdat gebruikers interactie kunnen hebben met de daadwerkelijke functionaliteiten van het product. Deze aanpak is echter langzamer en duurder vanwege het ontwikkelwerk dat ermee gemoeid is.

Spectrum van validatiemethoden, van snel maar van lage kwaliteit tot langzaam maar van hoge kwaliteit
Er is altijd een afweging tussen snelheid en kwaliteit

Gezien deze afweging is mijn favoriete validatiemethode het gebruik van klikbare prototypes, omdat ze relatief goedkoop te maken zijn en echte gebruikers een daadwerkelijk UX-ontwerp van je nieuwe product of functie laten zien.

Om het maken van prototypes te versnellen, kun je Figma AI of de ingebouwde AI-functies van andere UX-ontwerptools gebruiken.

8. Documenteer de testresultaten

Wanneer je tests zijn afgerond, bundel je alle lessen en resultaten in één document. Groepeer ze op basis van de oplossing en de hypothese die wordt getest.

Op deze manier heb je, wanneer het tijd is om een oplossing te evalueren, alles wat je nodig hebt op één plek om een weloverwogen beslissing te nemen.

9. Valideer je oplossingen of verklaar ze ongeldig

Dit is het moment waarop je alle bevindingen uit je tests bekijkt en beslist of:

  • Je de oplossing als gevalideerd beschouwt en deze toevoegt aan je bestaande productbacklog.
  • Je begrijpt dat de oplossing de goede kant op gaat, maar opnieuw moet worden uitgewerkt. Vervolgens breng je deze terug naar de ideatiefase om de oplossing op basis van de testresultaten te verbeteren.
  • Je de oplossing ongeldig verklaart omdat deze de gebruikersproblemen die ze had moeten oplossen niet oplost.

Alle drie de uitkomsten zijn te verwachten. Wanneer je een product ongeldig verklaart, zou je dat als een groot succes moeten beschouwen, omdat je zo hebt voorkomen dat je producten bouwt en tijd en middelen verspilt aan iets dat de pijnpunten van je gebruikers niet oplost.

10. Bouw de gevalideerde oplossingen en begin opnieuw

De laatste logische stap van het productontdekkingsproces is je oplossingen aan je backlog toevoegen, prioriteren en bouwen.

Het is echter echt belangrijk om te begrijpen dat je productontdekking hier niet daadwerkelijk stopt. In plaats daarvan rond je deze iteratie af en begin je onmiddellijk aan de volgende. Succesvolle producten zijn producten waarbij het ontdekkingsproces nooit eindigt.

Hier kunnen teams de juiste productbeslissingen nemen op basis van wat ze hebben geleerd uit feedback van gebruikers, gebruiksvriendelijkheidstests en A/B-tests.

Tools voor productontdekking

Hier zijn enkele tools die het verkennen waard zijn om je te helpen sneller door productontdekking heen te gaan en betere resultaten te behalen, ingedeeld naar de fase waarin je je bevindt.

  • Gebruikersonderzoek: Hotjar voor sessieopnames, UserTesting voor gebruiksvriendelijkheidstests en Figma voor het ontwerpen van gebruikerservaringen en klikbare prototypes.
  • Klantreis in kaart brengen en visueel samenwerken: Miro is hiervoor de universele tool. Je kunt ook overwegen de opkomende concurrent FigJam of andere alternatieven voor Miro te proberen.
  • Concurrentieonderzoek: Similarweb voor verkeerskanalen van concurrenten, Builtwith voor technologiestacks.
  • Productanalyse: GA4 voor kanalen en verkeer. Amplitude voor gedrag en belangrijke productstatistieken. Voor heatmapsoftware is HotJar een populaire optie.
  • Bijhouden en prioriteren: het RICE-scoringsmodel voor het eenvoudig vaststellen van prioriteiten, Aha! of ProdPad voor het maken van productroutekaarten en het opslaan van productideeën.

Dit zijn de tools die ik gebruik en aan mijn collega's aanbeveel. Voor meer opties kun je ook een kijkje nemen in onze zorgvuldig samengestelde lijst met tools voor productontdekking.

En als je het hebt gemerkt: ik heb hier geen AI-oplossingen genoemd. Dat komt doordat ik dit onderwerp apart en uitgebreider wil bespreken.

Hoe AI productontdekking verandert

Productontdekking is waarschijnlijk het gebied binnen productmanagement waaraan AI de meeste waarde heeft toegevoegd. De reden is dat LLM's uitstekend zijn in de soorten taken die je vaak binnen productontdekking tegenkomt. Concreet gaat het om transcriberen, samenvatten en inzichten extraheren.

We hebben de impact van AI op productontdekking besproken in een van de afleveringen van onze podcast. Onze gast, Craig Watson, nam ons mee door zijn eigen ervaring en deelde veel waardevolle inzichten.

Hij wijst er specifiek op dat AI productmanagers op de volgende gebieden veel hulp heeft geboden:

Gebruikersinterviews transcriberen en samenvatten: PM's hoeven tijdens het gesprek geen aantekeningen te maken en de opnames daarna niet te beluisteren. Het enige wat ze nodig hebben, is dat de AI-bot aan het gesprek deelneemt en het opneemt. De bot zet de opname vervolgens om in een transcriptie en samenvatting, waarbij de belangrijkste bevindingen uit dat interview worden benadrukt. Goede tools hiervoor zijn Dovetail, Krisp en GreatQuestion.

Herhaalbare patronen in kwalitatieve gegevens herkennen: Het kost veel tijd om alle interviews te beluisteren en pijnpunten of processen te vinden die zich herhalen. LLM's kunnen deze taak zeer goed uitvoeren en honderden interviews doorzoeken op zoek naar patronen. Vanuit mijn ervaring is Dovetail hierin het beste.

Feedback clusteren, tellen en scoren: Nogmaals, productteams zouden uren of zelfs dagen nodig hebben om kwalitatieve gegevens handmatig om te zetten in kwantitatieve gegevens. LLM's hebben slechts enkele seconden nodig om te tellen en te zien welke feedback het vaakst voorkomt in de gegevens. Ze kunnen ook scores toekennen met behulp van het gewogen scoringsmodel of RICE.

Ondanks alle waarde die je uit deze automatiseringen haalt, raadt Craig toch aan om bij het uitvoeren van productontdekking niet te veel op AI te vertrouwen.

“AI zal je intuïtie niet vervangen — het helpt je om sneller beslissingen te nemen die door bewijs worden ondersteund.”

Ik ben het met hem eens. Laat AI bij productontdekking het handmatige werk voor je doen. Maar vertrouw niet op de besluitvorming van AI zonder die eerst zelf te controleren.

Veelgestelde vragen

Hoe pakken wendbare teams productontdekking aan?

Wendbare teams kunnen gebruikmaken van agile met twee sporen, waarbij productontdekking parallel aan de oplevering verloopt. In dat geval sluiten wendbare teams zich af en toe aan bij het ontdekkingstraject om taken uit te voeren zoals het geven van feedback over de technische haalbaarheid van oplossingsideeën, het uitwerken van ontwerpconcepten, het bouwen van prototypes en het testen daarvan.

Moeten softwareontwikkelaars betrokken zijn bij productontdekking?

Absoluut! Softwareontwikkelaars zijn degenen die de functie uiteindelijk zullen bouwen. Daarom beschikken ze over waardevolle kennis over de haalbaarheid van het idee. Ze kunnen ook de mogelijke technische en implementatierisico’s die ermee samenhangen aan het licht brengen. Tot slot kunnen ze wijzen op de technische beperkingen waarmee het productteam rekening moet houden bij het ontwerpen van de functie.

Hoe verkort productontdekking de tijd tot marktintroductie?

De grootste waarde die bedrijven uit productontdekking halen, is de goedkope validatie van ideeën. Je loopt dus niet het risico dingen te bouwen die je gebruikers niet nodig hebben, waardoor het moment waarop je eindelijk de versie uitbrengt die mensen prettig vinden en gebruiken aanzienlijk wordt vertraagd. Je verkort ook iteratiecycli en krijgt vroegtijdig feedback. Dit alles helpt bovendien om de oplevering te versnellen.

Wat is het verschil tussen productontdekking en productstrategie?

Wanneer je productontwikkelingsstrategie bepaalt, geef je de richting van je product op hoofdlijnen en de lijst met mijlpalen op dat pad weer. Productontdekking is het proces waarbij je klantbehoeften identificeert en gevalideerde oplossingen daarvoor bedenkt. Doorgaans is productontdekking gericht op het creëren van oplossingen die aansluiten bij de productstrategie en je een stap dichter bij je mijlpalen brengen.