Functieverzoeken prioriteer je zo: groepeer ze op het probleem erachter, geef elk probleem een score op bereik, pijn, fit en moeite, en praat met een paar mensen die erom vroegen voordat je je vastlegt. Die laatste stap slaan de meeste teams over, terwijl je daar het goedkoopst een slechte gok opvangt. Het verkeerde bouwen gebeurt vaak: het feature adoption report van Pendo uit 2019, gebaseerd op drie maanden gebruiksdata van 615 klantabonnementen van Pendo, liet zien dat 80 procent van de functies in een gemiddeld softwareproduct zelden of nooit wordt gebruikt.
De belangrijkste punten
- Een functieverzoek is de gok van een klant naar een oplossing. Prioriteer het probleem erachter.
- Het aantal stemmen laat zien wie zich liet horen, niet hoeveel pijn het probleem doet.
- Kies een simpel framework, maar voed het met wat je leert in gesprekken met de aanvragers.
- Neem een besluit en vertel mensen wat je besloot, ook als het nee is.
Waarom het aantal stemmen misleidt
De meeste teams houden verzoeken ergens bij: een board, een spreadsheet, een Slack-kanaal. Daarna bouwen ze wat de meeste stemmen heeft. Dat voelt eerlijk, maar het is riskant.
- Luide klanten worden geteld. Stille niet. De mensen die verzoeken plaatsen, zijn niet altijd de mensen die je het liefst wilt houden.
- Verzoeken zijn oplossingen, geen problemen. “Voeg een CSV-export toe” kan eigenlijk betekenen “mijn manager wil een wekelijks rapport”. Een geplande samenvattingsmail lost dat misschien beter op.
- Dubbele verzoeken versplinteren de stemmen. Vijf verzoeken op vijf manieren verwoord lijken op vijf kleine problemen in plaats van één groot.
- Stemmen hebben geen gewicht. Een verzoek dat een grote klant zou behouden, telt even zwaar als iets wat leuk is om te hebben.
- Stemmen verlopen niet. Oude verzoeken blijven bovenaan staan, lang nadat de behoefte verdwenen is.
Een stem is een signaal om te gaan vragen. Het is niet het antwoord.
De prioriteringsframeworks in het kort
In elke gids zie je dezelfde handvol frameworks. Hier lees je waar elk goed voor is.
| Framework | Hoe het werkt | Het best voor | Let op |
|---|---|---|---|
| Aantal stemmen | Rangschik op aantal verzoeken | Een eerste signaal | Luide klanten, versplinterde dubbele verzoeken |
| RICE | Reach × Impact × Confidence ÷ Effort | Veel ideeën vergelijken | Confidence is vaak een gok |
| ICE | Impact × Confidence × Ease | Snel triëren | Erg subjectief |
| MoSCoW | Must, Should, Could, Won’t | Een vaste deadline of release | Geen volgorde binnen elke groep |
| Impact vs moeite | Een simpel 2×2-raster | Snelle successen vinden | Negeert hoeveel mensen het raakt |
| Kano | Basis-, prestatie- en wow-functies | Verwachtingen begrijpen | Vraagt een enquête om het goed te doen |
| Weging op omzet | Weeg elke stem naar de waarde van het account | B2B met een paar grote klanten | Kan een paar grote klanten te veel bedienen |
RICE, voor het eerst beschreven door Sean McBride bij Intercom, is voor de meeste productteams een verstandige standaardkeuze. Maar elk framework heeft dezelfde zwakke plek: reach, impact en confidence hangen allemaal af van hoe goed je het probleem begrijpt. De stappen hieronder gaan erover dat deel goed te krijgen.
Stap 1: Verzamel elk verzoek op één plek
Verzoeken komen uit supporttickets, salesgesprekken, berichten in de app, e-mails en reviews. Zet ze in één lijst, zodat je ze naast elkaar ziet.
Leg voor elk verzoek vast:
| Veld | Voorbeeld |
|---|---|
| Verzoek | Rapporten exporteren als CSV |
| Wie vroeg erom | Operations lead bij een middelgrote klant |
| Hun exacte woorden | “Ik kopieer elke maandag cijfers naar een spreadsheet voor mijn baas.” |
| Abonnement of segment | Business-abonnement, 40 gebruikers |
| Bron en datum | Supportticket, 3 maart |
Hun exacte woorden tellen het zwaarst. Die laten het probleem vaak duidelijker zien dan het verzoek zelf.
Vergeet de stille bronnen niet. Aantekeningen van verloren salesdeals en antwoorden van klanten die hebben opgezegd, bevatten vaak verzoeken die nooit op je board terechtkomen.
Stap 2: Vind het probleem achter elk verzoek
Herschrijf elk verzoek als probleem, in één simpele zin:
Wie wil doel, maar obstakel.
Voor het CSV-voorbeeld: “Teamleiders willen wekelijkse cijfers delen met hun manager, maar moeten ze met de hand overnemen.”
Groepeer nu verzoeken die hetzelfde probleem delen. Vijf verschillende verzoeken (CSV-export, geplande e-mails, een openbare link naar het dashboard, een PDF-knop en een API-endpoint) kunnen allemaal hetzelfde probleem zijn. Samen is het veel groter dan elk los verzoek leek.
Dit is het kernidee achter jobs to be done: mensen willen niet de functie zelf. Ze willen de vooruitgang die die functie hen geeft.
Stap 3: Praat met de mensen die erom vroegen
Praat met een paar mensen achter je grootste groepen voordat je iets een score geeft. Een kort gesprek vertelt je meer dan een stapel stemmen.
Vraag naar hun echte situatie, niet naar jouw idee:
- “Wat probeerde je te doen toen je hierom vroeg?”
- “Hoe los je het nu op?”
- “Hoe vaak komt dit voor?”
- “Wat gebeurt er als het niet gedaan wordt?”
- “Wie heeft er nog meer last van?”
Vermijd “Zou je dit gebruiken als we het bouwen?” Bijna iedereen zegt ja, dus het vertelt je niets. Onze gids over sturende vragen heeft meer voorbeelden om te vermijden.
Zo klinkt een goed gesprek
Jij: Wat probeerde je te doen toen je om een CSV-export vroeg?
Klant: Onze cijfers in het maandagrapport krijgen.
Jij: Wie leest dat rapport?
Klant: Mijn manager. Ze wil alleen drie cijfers en de trend. Ik kopieer ze elke week naar slides.
Jij: Hoe lang duurt dat?
Klant: Bijna een uur, elke maandag.
Het verzoek was “CSV-export”. De behoefte is “mijn manager elke week drie cijfers laten zien zonder gedoe”. Een geplande samenvattingsmail lost het misschien op in een fractie van de bouwtijd, en zou elke klant met hetzelfde maandagritueel helpen.
Sterk vs zwak bewijs
| Zwak signaal | Sterk signaal |
|---|---|
| “Het zou leuk zijn om te hebben.” | “Ik ben hier elke maandag een uur mee bezig.” |
| “Tuurlijk, ik zou het gebruiken.” | “We betalen voor een andere tool alleen om dit te doen.” |
| Eén upvote | Een omweg die ze zelf hebben gebouwd |
| “Iedereen wil dit.” | Namen, datums en wat het hen kostte |
Hoeveel gesprekken zijn genoeg
Blijf praten tot je kunt voorspellen wat de volgende persoon gaat zeggen. Herhalen de verhalen zich, dan begrijp je het probleem goed genoeg om het een score te geven.
Blijven de verhalen veranderen, dan is dat ook een bevinding. Eén verzoek kan meerdere problemen omvatten, en dan moet je de groep splitsen. Meer vragen om te stellen vind je in onze vragen voor klantinterviews.
Stap 4: Geef elk probleem een score
Geef nu de problemen een score, niet de verzoeken. Houd het simpel. Een score die je team echt bijwerkt, is beter dan een perfecte score waar niemand aankomt.
Beoordeel elk probleem van 1 tot 3 op vier punten:
- Bereik: hoeveel van de klanten om wie het je gaat dit probleem hebben.
- Pijn: hoeveel last ze ervan hebben, op basis van wat je hoorde.
- Fit: hoe goed het oplossen ervan past bij waar je product naartoe gaat.
- Moeite: hoeveel werk het kost. Hoger betekent meer werk.
Reken dan uit: Bereik × Pijn × Fit ÷ Moeite.
| Probleem | Bereik | Pijn | Fit | Moeite | Score |
|---|---|---|---|---|---|
| Wekelijkse cijfers delen met managers | 3 | 2 | 3 | 2 | 9 |
| Single sign-on voor grotere teams | 1 | 3 | 3 | 3 | 3 |
| Donkere modus | 2 | 1 | 1 | 2 | 1 |
Het deelprobleem wint, ook al had de donkere modus op zichzelf meer stemmen. De verzoeken over delen waren verspreid over vijf verschillende functie-ideeën, dus geen van allen leek groot.
Weeg op omzet, maar voorzichtig
In B2B is het redelijk om meer gewicht te geven aan problemen van je grootste of snelst groeiende klanten. Laat weging op omzet alleen niet de roadmap bepalen. Een paar grote klanten kunnen je naar functies trekken die verder niemand nodig heeft, en nieuwe segmenten die je wilt winnen leveren nog geen omzet op.
Als één grote klant iets vraagt
Soms wil een grote klant iets waar verder niemand om heeft gevraagd. Het is verleidelijk om meteen ja te zeggen.
Zoek eerst het probleem erachter, net als bij elk ander verzoek. Vraag je dan af of kleinere, vergelijkbare klanten tegen hetzelfde probleem aanlopen als ze groeien. Zo ja, dan hoort het misschien op de roadmap. Past het alleen bij die ene klant, behandel het dan als maatwerk met een duidelijke prijs en planning.
Laat ruimte voor je eigen gokken
Verzoeken van klanten laten je de problemen van vandaag zien. Ze laten zelden zien waar de markt naartoe gaat. Bepaal vooraf hoeveel tijd van je team naar klantproblemen gaat, naar je eigen strategische gokken en naar fixes en onderhoud. Prioriteer verzoeken daarna binnen hun eigen deel, zodat een vol board niet ongemerkt de hele roadmap overneemt.
Stap 5: Neem een besluit en maak de cirkel rond
Kies het belangrijkste probleem, kies een oplossing en vertel het de mensen die erom vroegen. Klanten die iets terughoren, blijven je vertellen wat ze nodig hebben. Onze gids over de klantfeedbackcyclus laat zien hoe je hier een gewoonte van maakt.
Nee zeggen hoort bij het werk. Twee templates die je kunt aanpassen:
Niet nu
Hoi naam,
Bedankt voor je vraag over functie. We bouwen het dit kwartaal niet.
We richten ons eerst op ander probleem, omdat meer van onze klanten daartegen aanlopen.
Je zei dat je hun doel wilt bereiken. Ondertussen lossen sommige klanten
het zo op: omweg of helpartikel.
Ik heb je bericht met je exacte woorden bewaard, en ik laat het je weten als dit verandert.
Niet gepland
Hoi naam,
Bedankt voor je idee over functie. Ik wil eerlijk tegen je zijn:
het past niet bij de richting die we met product op gaan, dus we zijn niet van plan het te bouwen.
Voor hun doel past andere tool of omweg misschien beter.
Als je behoeften veranderen, hoor ik het nog steeds graag.
Een simpel ritme dat de lijst eerlijk houdt
Eén keer prioriteren helpt niet veel. Een lichte routine wel.
| Hoe vaak | Wat je doet |
|---|---|
| Wekelijks | Voeg nieuwe verzoeken toe met exacte woorden, voeg dubbele samen, koppel elk verzoek aan een probleem |
| Maandelijks | Praat met drie tot vijf mensen achter je grootste probleemgroepen |
| Per kwartaal | Geef de lijst opnieuw een score, kies wat er nu komt en vertel aanvragers wat je besloot |
Twintig minuten per week is genoeg voor de meeste teams. De maandelijkse gesprekken zorgen dat je scores aan echte klanten gekoppeld blijven, en niet aan wie het laatst iets plaatste.
Fouten om te vermijden bij het prioriteren van functieverzoeken
- Bouwen voor de luidste klant. Check eerst of anderen hetzelfde probleem hebben.
- Functies een score geven in plaats van problemen. Dan splits je één groot probleem op in kleine verzoeken die allemaal onbelangrijk lijken.
- Vragen of mensen het zouden gebruiken. Vraag hoe ze nu met het probleem omgaan.
- Nooit terugkijken. Geef je lijst elk kwartaal opnieuw een score. Behoeften veranderen, en je product ook.
Hoe Diaform helpt
Praten met iedereen achter een verzoek kost tijd, en de meesten plannen geen gesprek in. Met Diaform stuur je in plaats daarvan één link. Een AI-agent stelt je vragen via spraak of tekst, vraagt door als iemand zegt “het zou leuk zijn om te hebben” en vat elk gesprek samen zodra het klaar is.
Stuur de link per e-mail of toon hem in je app. Vanaf het Pro-abonnement kunnen links op uitnodiging het e-mailadres of gebruikers-ID van elke persoon meenemen, zodat je weet welk account wat zei. Exporteer de antwoorden naar CSV en zet ze in je scoringsblad. Zie hoe Diaform omgaat met productfeedback, of start een gratis proefperiode van 14 dagen.
