Feature requests prioriteren: wat bouw je eerst?

Er is altijd een lijst. In een spreadsheet, in een ticketsysteem of in iemands hoofd. Wensen van klanten, ideeën van collega's, dingen die de concurrent wel heeft. De lijst is langer dan je ooit kunt bouwen. Feature requests prioriteren is daarom geen bijzaak, maar de kern van goede doorontwikkeling. In dit artikel lees je hoe je bepaalt wat eerst komt.

Waarom gaat feature requests prioriteren zo vaak mis?

Feature requests prioriteren gaat vaak mis omdat de luidste stem en het nieuwste idee de meeste aandacht krijgen. Nieuwe functies voelen als vooruitgang. Er is iets tastbaars om naar uit te kijken. En wie het hardst aandringt, krijgt vaak zijn zin.

Maar de luidste stem is niet altijd de belangrijkste, en het nieuwste idee niet altijd het beste. Zonder vaste aanpak bouw je dingen in de verkeerde volgorde. Je steekt tijd in iets dat weinig wordt gebruikt, terwijl iets anders al maanden urgent is. Je maakt één persoon blij en vergeet de stille meerderheid.

Hoe weeg je waarde af tegen inspanning?

De eenvoudigste manier om te prioriteren is elke wens te plaatsen op twee assen: hoeveel waarde levert het op en hoeveel inspanning kost het.

Hoge waarde, lage inspanning. Dit doe je eerst. Veel resultaat voor weinig werk.

Hoge waarde, hoge inspanning. Dit plan je bewust. Het is de moeite waard, maar je maakt er tijd en budget voor vrij.

Lage waarde, lage inspanning. Misschien, als je toch in dat deel van de site bezig bent. Geen prioriteit.

Lage waarde, hoge inspanning. Dit doe je niet, hoe aantrekkelijk het idee ook klinkt.

Het lastige is natuurlijk hoe je waarde bepaalt en inspanning inschat. Daar gaan de volgende twee secties over.

Hoe bepaal je de waarde van een feature?

De waarde van een feature bepaal je met vier vragen, niet met een formule.

Hoeveel mensen raakt het? Iets wat elke gebruiker dagelijks nodig heeft, is waardevoller dan iets wat een handvol mensen af en toe gebruikt.

Hoe groot is de impact? Lost het een echt probleem op, bespaart het merkbaar tijd of maakt het iets mogelijk wat nu niet kan?

Wat is het alternatief? Als er een omweg is die goed genoeg werkt, is de urgentie lager dan wanneer mensen vastlopen.

Wat gebeurt er als je het niet bouwt? Verlies je klanten, mis je omzet of raak je achter op de markt?

Praat met gebruikers, en niet alleen met de mensen die klagen. Kijk naar data als die er is: hoe vaak wordt vergelijkbare functionaliteit gebruikt en hoeveel supportvragen gaan over dit onderwerp?

Hoe schat je de inspanning in?

De inspanning schat je in door het te vragen aan de mensen die het moeten bouwen. Niet in uren, maar in maten: klein, middel, groot of extra groot. Dat is snel en voor prioriteren nauwkeurig genoeg.

Let op verborgen complexiteit. Sommige wensen lijken klein, maar raken aan veel bestaande functionaliteit, zoals rechten, data of koppelingen. Andere lijken groot, maar zijn eigenlijk los te bouwen. Denk ook aan onderhoud. Bouwen gebeurt één keer, onderhouden blijft. Een functie die veel onderhoud vraagt, kost meer dan de bouw doet vermoeden.

Hoe weeg je verzoeken van klanten?

Verzoeken van klanten weeg je door te zoeken naar het probleem achter de vraag. Klanten vragen vaak om een specifieke oplossing. Kunnen jullie een export naar Excel maken? Misschien. Maar waarom willen ze die export? Misschien willen ze gegevens delen met hun boekhouding, en is een directe koppeling een beter antwoord.

Tel ook hoe vaak iets gevraagd wordt en door wie. Een wens die veel klanten noemen, weegt zwaarder dan een wens van één klant, tenzij die ene klant een groot deel van je omzet vertegenwoordigt. En let op wat klanten niet vragen. Soms weten ze niet dat iets kan, of zijn ze gewend geraakt aan een omslachtige werkwijze. Kijk daarom ook naar waar het schuurt, niet alleen naar wat er gevraagd wordt.

Wie betrek je bij de keuze?

Bij de keuze betrek je iedereen die een deel van het beeld heeft, maar één persoon hakt de knoop door. Support weet welke vragen steeds terugkomen. Sales weet welke functies een deal maken of breken. Development weet wat makkelijker of lastiger is dan het lijkt. Management weet welke strategische richting voorrang heeft.

Breng die inzichten samen in een gestructureerde afweging, niet in eindeloze vergaderingen. Hangt prioriteren samen met grotere keuzes over de koers van je bedrijf, dan hoort het thuis in een digitale roadmap.

Waarom is nee zeggen onderdeel van prioriteren?

Nee zeggen is onderdeel van prioriteren omdat kiezen voor het een altijd betekent dat je iets anders niet doet. Dat is lastig, zeker als iemand enthousiast is of een belangrijke klant iets vraagt. Maar een lange lijst waar niets van afkomt, is erger dan een korte lijst die je echt uitvoert.

Nee hoeft ook niet voor altijd te zijn. Niet nu is een volwaardig antwoord. De wens blijft op de lijst en komt terug bij de volgende herziening.

Hoe ziet een werkbare aanpak eruit?

Een werkbare aanpak bestaat uit zes stappen die je elk kwartaal kunt herhalen.

Verzamel alles. Elke wens, elk idee en elke klacht die eigenlijk een verzoek is, op één lijst.

Schoon op. Haal dubbelingen weg, schrap wat niet meer relevant is en maak vage wensen concreet.

Scoor. Geef elke wens een grove score voor waarde en inspanning.

Maak het zichtbaar. Zet alles op een matrix of bord. Dan zie je in één oogopslag wat snelle winst is en wat grote projecten zijn.

Kies een handvol. Niet meer dan je team in de komende periode echt kan afronden.

Communiceer en herzie. Leg uit waarom je deze keuzes maakt, en bekijk de lijst periodiek opnieuw. Prioriteiten veranderen.

Hoe helpen wij bij doorontwikkeling?

Wij helpen door prioriteren en bouwen in één ritme te combineren. Bij doorontwikkeling houden we samen met je de lijst bij, schatten we de inspanning in en bouwen we in overzichtelijke stappen. Gaat het om de bredere koers, dan starten we met strategie en advies. En staat er een grotere uitbreiding op de lijst, zoals een portaal of koppeling, lees dan ook ons artikel over je website uitbreiden met functionaliteit.