Hoe bepalen we de roadmap van Moneybird?

Update 20-11-2018: Dit artikel schreven we in 2017 en het is nu niet meer helemaal actueel. Lees ons nieuwste artikel over het bepalen van de roadmap.

Na een interessante discussie op Twitter (opent in nieuw tabblad) over het bepalen van een roadmap voor je product, leek het mij leuk een kijkje in de keuken te geven bij Moneybird.

Het beheren van de roadmap voor een product zoals Moneybird is moeilijk. Er zijn altijd duizend-en-één kansen, bedreigingen en belangen. We vinden het daarom belangrijk om een goed proces te hebben om tot beslissingen te komen. Niet bij de koffieautomaat kiezen wat we gaan doen, maar met een transparant proces waar ons hele team bij betrokken is.

Hoe ziet de roadmap er uit? #

Voordat je kunt gaan praten over wat je gaat doen, moet je eerst bepalen hoe je dat gaat doen. Bij Moneybird werken we met Big Projects: zes weken waarin een projectteam volledige vrijheid krijgt om een project uit te voeren. Het projectteam bepaalt zelf hoe ze het project uitvoeren, hoe ze het projectmanagement willen doen en wat de doelen zijn.

Er is één belangrijke regel: het hele team gunt het projectteam hun zes weken, maar daarna is de tijd om. De leden van het projectteam krijgen dan weer andere taken en moeten extra tijd voor het project verdedigen naar het team toe. Daarom ontvangt het hele bedrijf elke week een update van het projectteam over hun voortgang, zodat we allemaal mee kunnen denken bij uitdagingen en bij de planning. De deadline staat vast, maar de scope is variabel.

Wat kan er op de roadmap staan? #

Het bepalen van de roadmap bestaat dus uit het inplannen van projecten in blokken van zes weken. Iedereen binnen Moneybird kan een project pitchen in onze ticket tool Phabricator (opent in nieuw tabblad). Daarin omschrijf je wat de probleemstelling is, wat het belang voor de klanten is, wat een mogelijke oplossing is en welke capaciteit je nodig denkt te hebben. Een pitch kan allerlei soorten werk bevatten: een nieuwe feature, een verbetering van een bestaande feature, maar ook een wijziging in de backend of hosting architectuur.

Vaak ontstaat een pitch over maanden heen, op basis van feedback van klanten, informatie van partners of ontwikkelingen in de markt. Support noteert elk verzoek van een klant over een feature bij de pitch, zodat we eenvoudig kunnen tellen hoe vaak onze klanten vragen om een feature en de pitch kunnen aanscherpen met nieuwe inzichten. Voor sommige pitches zoeken we actief naar input: we sturen relevante klanten een enquete of doen interviews met klanten. Het doel is om een zo goed mogelijk beeld te hebben van hetgeen gedaan moet worden zodat we beter kunnen plannen en gelijk van start kunnen zodra het project begint.

Wie bepaalt de roadmap? #

Het is uiteindelijk de taak van het Big Project team om de pitches op de roadmap te zetten. In dit team zitten niet alleen Joost en ik als oprichters, maar ook een aantal engineers en interaction designers. Het doel van het Big Project team is de roadmap voor de komende maanden te bepalen en onze redenatie daarvoor te presenteren aan het hele Moneybird-team. Zelfs met alle informatie in de pitches, is het bepalen van een goede roadmap nog steeds een hele klus.

Dit is geen exacte wetenschap, maar we houden de pitches onder andere langs de volgende meetlatten:

1. Aantal klantverzoeken: een feature waar 100 klanten om vragen kan belangrijker zijn dan een feature waar we 2 vragen over gekregen hebben;
2. Impact op het gemak van de eindgebruiker: een feature die een klant elke dag 10 minuten tijd bespaart is waardevoller dan een feature die een klant elk kwartaal 10 minuten bespaart;
3. Ontwikkeling in de markt: soms wil je voorop lopen met innovatie, soms moet je de markt volgen als er nieuwe ontwikkelingen zijn;
4. Haalbaarheid: soms kan een saai project dat we zeker in 6 weken kunnen realiseren meer betekenen voor het product, dan een project met veel onzekerheid waarbij we misschien 6 weken verspillen. Op andere momenten moet je juist risico durven nemen;
5. Stabiliteit en veiligheid: soms moet een project dat de stabiliteit en veiligheid van ons product verbetert vóór een project dat die gave nieuwe feature introduceert;
6. Visie: sommige projecten dragen duidelijker bij aan onze visie dan anderen, zo'n project kan marketing en communicatie eenvoudiger maken;
7. Inzichten vanuit support en data-analyse: kan een project bijdragen aan een betere administratie voor onze klanten? Hoeveel klanten gebruiken een feature nu en lopen tegen problemen aan?
8. Afhankelijkheden: sommige projecten zijn afhankelijk van externe partijen en kunnen daardoor (nog) niet uitgevoerd worden.

Zoals je misschien ziet, kunnen deze meetlatten per dag een verschillend resultaat hebben. Iets waar vandaag 2 klanten om vragen, kan volgende week 100 verzoeken hebben. Iets dat nu nog geen security issue is, kan morgen urgent zijn. Iets dat nu nog onhaalbaar lijkt, kan na een nachtje slapen veel eenvoudiger blijken. Het komt dus regelmatig voor dat een project dat de volgende keer écht aan de beurt is, meerdere keren naar achteren geschoven wordt omdat er belangrijkere projecten tussendoor komen.

Wat doen we met de roadmap? #

Nadat het Big Project team een keuze gemaakt heeft in de roadmap, zal deze aan het team gepresenteerd worden. Omdat iedereen zijn project dat hij gepitcht heeft graag wil uitvoeren, moeten we een goede onderbouwing hebben anders is er geen draagvlak voor de keuzes.

Zodra het eerstvolgende project kan beginnen zal het team dat het project draagt de leiding over het project nemen en zorgen voor de ontwikkeling, voortgang en presentaties.

Onze roadmap presenteren we nooit naar onze eindgebruikers, niet op onze website en ook niet op individuele basis. Door de roadmap publiek te maken, zouden we verwachtingen kweken over hoe de ontwikkeling van onze software gaat. De harde praktijk is dat het ontwikkelen van software een zeer onberekenbaar proces is: iets dat eenvoudig lijkt duurt meer dan zes weken, iets dat complex lijkt is in twee weken klaar.

Hoewel we ondertussen vele jaren ervaring hebben met productontwikkeling, is het ontwikkelen van de software niet persé eenvoudiger geworden. Een eenvoudige feature die vroeger een dag kostte, duurt nu een week omdat we het klaar moeten maken voor duizenden gebruikers, het moet voldoen aan onze hoge eisen voor stabiliteit en beveiliging en we het goed door willen testen om niet na één dag honderden vragen te hebben. Deze aanpak scheelt op de lange termijn veel tijd, maar op korte termijn duurt een project daardoor langer.

Het presenteren van onze roadmap aan onze gebruikers zou een valse verwachting scheppen dat we ons aan die roadmap kunnen houden. In de praktijk is de kortetermijnplanning onderhevig aan de uitdagingen die softwareontwikkeling met zich meebrengt. De langetermijnplanning is onderhevig aan vele invloeden die meetellen bij het bepalen van een roadmap. Daarnaast zou het onze wendbaarheid als bedrijf serieus in de weg zitten. Daarom presenteren wij alleen de features die we afgerond hebben aan onze klanten. Alle andere features op de roadmap moeten we nog bouwen, uitdenken en finetunen voordat ze klaar zijn om aan de kritische blik van onze klanten blootgesteld te worden.

Hoe kunnen klanten onze roadmap beïnvloeden? #

Een vraag die in de Twitter discussie (opent in nieuw tabblad) naar boven kwam, is hoe klanten onze roadmap dan kunnen beïnvloeden. Het antwoord daarop is tweeledig.

Enerzijds hebben al onze klanten samen veel invloed op onze roadmap. Door naar onze klanten te luisteren en feature requests actief te noteren, weten we goed wat onze klanten nodig hebben. Hierdoor kan iedereen continu invloed uitoefenen door zijn mening te laten horen. En we proberen daarbij geen onderscheid te maken tussen invloedrijke mensen en de gewone ondernemer.

Anderzijds heb je als individuele klant heel weinig invloed. Je moet vertrouwen op andere gebruikers die tegen vergelijkbare problemen aanlopen en dat aankaarten bij ons zodat het bij ons op de radar komt. De praktijk wijst uit dat de massa ervoor zorgt dat de belangrijke problemen automatisch bij ons boven komen drijven. Zelden komt een individuele klant met een baanbrekend inzicht voor een nieuwe feature dat we niet al van 10 andere klanten hoorden of zelf bedacht hadden.

Conclusie #

Hopelijk geeft het bovenstaande proces een inzicht in hoe wij keuzes maken over de ontwikkeling van Moneybird. Het geeft geen antwoord op de vraag of jouw wensen op onze roadmap staan, maar creëert hopelijk begrip over waarom wij dat niet communiceren. En je weet hoe je onze roadmap kunt beïnvloeden: blijf feedback geven en ons voeden met inzichten, zodat ons team de Big Project pitches kan schrijven en verbeteren!

Overigens is het proces dat ik hierboven omschreven heb, ook continu in ontwikkeling. Op basis van goede en foute keuzes die we maken en feedback van klanten durven we ook het proces te verbeteren. We zijn tevreden met het huidige proces, mede gesterkt door onze 9 jaar ervaring met het ontwikkelen van Moneybird.

Dan gaan wij nu verder met mooie dingen bouwen!