Een product roadmap maken op basis van klantfeedback
5 min lezen
Een product roadmap maken komt hierop neer: verzamel wat klanten al hebben gevraagd, groepeer het op het probleem achter elk verzoek, rangschik de groepen met een regel die je kunt uitleggen, bepaal hoe zeker je bent van elk item en publiceer het resultaat in een format dat past bij wie het leest. De volgorde telt. Teams die met een indeling beginnen en die met ideeën vullen, krijgen een document dat af lijkt en geen bewijs bevat. Teams die met verzoeken beginnen, krijgen een kortere roadmap met een reden achter elke rij.
| Stap | Wat je doet | Wat je overhoudt |
|---|---|---|
| 1. Verzamelen | Haal verzoeken, supportthema’s en gebruiksdata samen in één lijst | Een ruwe lijst met een bron bij elke regel |
| 2. Groeperen | Voeg duplicaten samen, geef het probleem achter elk cluster een naam | Tien tot twintig problemen met aantallen |
| 3. Rangschikken | Pas één scoreregel toe en schrijf hem op | Een geordende lijst die je kunt verdedigen |
| 4. Toezeggen | Label elk item toegezegd, verwacht of verkennend | Eerlijk vertrouwen bij elke rij |
| 5. Format kiezen | Kies een indeling voor de lezer | Een roadmap in Now/Next/Later, thema’s of een tijdlijn |
| 6. Reviewen | Plan een datum om elke rij opnieuw te bekijken | Een roadmap die actueel blijft |
Waar begin je als je een product roadmap maakt?
Begin met het bewijs dat je al hebt, niet met een leeg vel. Openstaande featureverzoeken, supportgesprekken met dezelfde klacht, notities van salesgesprekken en gebruiksdata uit je eigen product zijn allemaal input. Zet ze in één lijst en schrijf op waar elk item vandaan komt.
Verzoeken komen zelden in een bruikbare vorm binnen. “Voeg een Slack-integratie toe” en “waarschuw mijn team als een taak verandert” kunnen dezelfde behoefte zijn. Daarom is groeperen de volgende stap, en daarom is een tracker die duplicaten samenvoegt het waard; dubbele featureverzoeken behandelt hoe. Bedenk ook dat supporttickets en featureverzoeken verschillende soorten signaal bevatten, en dat een roadmap die uit slechts één van de twee is opgebouwd de verkeerde kant op helt.
Hoe maak je van verzoeken items op je product roadmap?
Groepeer verzoeken op het probleem, geef elke groep een naam als uitkomst en bewaar het aantal. Een groep van veertien verzoeken die allemaal beschrijven dat een filter na herladen verdwijnt, wordt één item: “Het filter van de vorige keer blijft behouden”. Het aantal komt in de bronkolom, zodat iedereen die de roadmap leest het gewicht erachter kan zien.
Schrijf de uitkomst in de woorden van de klant. “Persistentie van opgeslagen weergaven implementeren” vertelt een engineer wat hij moet bouwen en een klant niets. Die formulering dwingt ook een nuttige vraag af: als je niet kunt zeggen wat er voor de klant verandert, kijk je misschien naar een interne taak die op een andere lijst thuishoort.
Hoe bepaal je wat eerst komt?
Kies één scoreregel, schrijf hem op en pas hem op elk item toe. RICE, dat reach, impact, confidence en effort scoort, is de bekendste; het artikel van Intercom over RICE is de oorspronkelijke bron. Een eenvoudiger regel werkt even goed als je hem kunt uitleggen: het aantal verzoeken, gewogen naar of de aanvrager een actief betalend account is, gedeeld door de grove inspanning.
Het gaat erom dat de regel is vastgelegd, want de eerste klant die vraagt waarom zijn verzoek niet op de lijst staat, wil een antwoord. Als de regel en je eigen oordeel verschillen, zeg dat dan in de rij. Featureverzoeken prioriteren loopt door scoremethoden, de vraag of je op omzet weegt en wat stemmen wel en niet vertellen.
Hoe zeker ben je van elk item?
Geef elk item een vertrouwenslabel voordat je iets publiceert. Een eenvoudige schaal met drie waarden volstaat: toegezegd betekent dat het team verbaasd zou zijn als het niet in het venster uitkomt, verwacht betekent dat het het plan is tenzij er iets verandert, en verkennend betekent dat er geen belofte is.
Deze ene kolom voorkomt de meeste schade door roadmaps. Zonder haar leest een klant een verkennend item als toezegging, citeert sales het en is het een kwartaal later een klacht. Het essay van Marty Cagan over het alternatief voor roadmaps maakt het onderliggende argument: een lijst features met data is een lijst gokken die als plannen wordt gepresenteerd, en de oplossing is expliciet zijn over wat je weet.
Welk format moet de roadmap krijgen?
Kies de indeling als laatste, op basis van de lezer. Klanten die willen weten of je ze hebt gehoord, hebben een korte publieke weergave nodig. Leiding die vraagt waarom dit werk nodig is, wil thema’s of uitkomsten. Een team dat elke maand van richting verandert, is gebaat bij Now, Next en Later zonder data. Product roadmap voorbeelden toont zes formats met realistische items en hoe elk faalt, en de product roadmap template geeft de velden om te kopiëren zodra je hebt gekozen.
De meeste teams eindigen met twee documenten: een strategische roadmap voor interne lezers en een verkleinde publieke die alleen laat zien waaraan je je wilt laten houden. Publiceer je er een, dan beschrijft publieke roadmap hoe je hem aanstuurt met labels op de issues die je al bijhoudt.
Hoe voorkom je dat de roadmap veroudert?
Geef elke rij een reviewdatum en bewaar de roadmap waar het werk al is. Een roadmap die met de hand in een apart hulpmiddel wordt bijgewerkt, veroudert omdat het in niemands dagelijks werk zit. Als elke kolom aan een label op het issue gekoppeld is, verandert de roadmap mee met het label.
Sluit de loop wanneer een item is uitgebracht. De mensen die erom vroegen moeten het horen, en de changelog-entry is daarvoor de gebruikelijke plek; de feedback-loop met klanten beschrijft het hele pad. Besluit je iets niet te bouwen, zeg dat dan ook. Een duidelijk nee helpt degene die erom vroeg, en featureverzoeken afwijzen behandelt de formulering.
FAQ
Wat zijn de stappen om een product roadmap te maken? Verzamel verzoeken en data, groepeer ze op het probleem erachter, rangschik ze met een opgeschreven regel, geef elk item een label voor hoe zeker je bent, kies een format voor de lezer en plan een reviewdatum. Beginnen bij bewijs houdt de roadmap kort en verdedigbaar.
Waarop moet een product roadmap gebaseerd zijn? Op klantverzoeken, supportthema’s, gebruiksdata en je strategie, in de volgorde waarin ze het vaakst worden overgeslagen. Een roadmap zonder bron achter de rijen is een verlanglijstje.
Hoe ver moet een product roadmap vooruitkijken? Ver genoeg om nuttig te zijn en kort genoeg om geloofwaardig te blijven. Voor veel kleine teams is dat het huidige kwartaal in detail en de volgende een of twee als thema’s. Alles verder weg hoort onder “later”, zonder data.
Wie moet er betrokken zijn bij het maken van een product roadmap? De product owner beslist, engineering toetst haalbaarheid en inspanning, en support en sales leveren de verzoeken en thema’s die ze horen. Klanten zien het resultaat in een publieke versie, maar bewerken hem niet.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.