Result Roadmap: in 5 stappen naar een succesvolle app

Feature creep. Featuritis. Feature fatigue. Het zijn verschillende termen voor hetzelfde probleem, één dat menig CTO of Product Owner herkent tijdens het ontwikkelen van een app: de neiging om voortdurend features toe te voegen aan je product. Dit eindigt in het onvermijdelijke: een complex en verwarrend product, mijlenver verwijderd van de basisfunctie ervan.

Boodschappenlijst met features?

De neiging tot ‘Feature Creep’ kan zich snel ontwikkelen wanneer een development team strict Feature Driven te werk gaat. Kort door de bocht: met Feature Driven Development voeg je alle ‘feature requests’ van interne en externe klanten toe aan een oneindige lijst van features. De naam zegt het al: de strategie en keuzes worden bepaald door vraagstukken op het niveau van features.

Werkt je team Feature Driven, dan ontwikkel je de app van feature naar feature. Hier zitten gevaren aan. Aan het einde van het project is de lijst met features weliswaar afgewerkt, maar een aantal van die features sluit niet langer aan op de markt. Het zijn functionaliteiten waar de eindgebruiker niet op zit te wachten, en ze leiden niet tot het realiseren van je belangrijkste KPI’s.

Een (beter) alternatief is Result Driven Development (RDD). Bij The Mobile Company zetten we deze methodiek in voor klanten als Van Oord, McCain, De Lijn en ReumaNederland. In dit artikel bespreken we wat RDD precies inhoudt en delen we handvatten om vanuit een heldere projectstrategie (de roadmap) tot de juiste keuzes te komen.

Result Driven Development: een korte uitleg

Result Driven Development is het proces waar de eindklant een gewenst eindresultaat koopt (de zogenaamde ‘Job-To-Be-Done’). Dit eindresultaat wordt altijd gemeten in meetbare kengetallen.

Niet: de eindklant wil een app vol sexy features. Wel: de eindklant wil een eindresultaat.

Bouw je een oplossing vanuit RDD, dan focust je team zich op de juiste eindresultaten (en bijbehorende kengetallen) die de app moet leveren. De onderliggende features zijn hierbij ondersteunend (niet leidend) aan deze eindresultaten*. Zo voorkom je dat het team in een productieproces van features terechtkomt, zonder dat ze enig idee hebben of, en welke, waarde de features toevoegen aan het gewenste resultaat.

*Met RDD worden features niet minder belangrijk. Het gewenste resultaat bereik je namelijk niet zonder goede features. Wat werken met RDD wél voor elkaar krijgt is dat jouw team alleen de juiste features bouwt. En, inderdaad, dat er ook minder features gebouwd worden (als je RDD goed uitvoert).

Waarom hebben we een eigen methode ontwikkeld?

1. Met de ontwikkeling van een app streef je 2 gewenste eindresultaten na: die voor de business en die voor de eindgebruiker. Beiden wil je vangen in je projectplanning. Met onze Result Mapping methode maak je bij de Goals specifiek een splitsing tussen App Goals + User Goals.
2. Ontwikkel je een app, dan heb je vaak te maken met externe en interne randvoorwaarden. Denk aan capaciteit, maar ook technologische infrastructuur of stakeholder buy-in. Andere bekende methodes als OKR en OGSM beperken zich vaak uitsluitend tot doelen. Met Result Mapping besteden we veel aandacht aan het tackelen van de essentiële randvoorwaarden van succes: de Critical Success Factors (CSF’s).

Een nieuwe mindset

Bij The Mobile Company zien we een verandering in de mindset bij elk development team wanneer we werken vanuit de principes van RDD. Bij elke keuze die gemaakt wordt stel je namelijk de simpele vraag: ‘In hoeverre draagt dit bij aan het behalen van het einddoel en onze belangrijkste kengetallen?’

Een belangrijk doel van RDD is dat het ventileren van onderbuikgevoelens, aannames en meningen minder wordt en op den duur geheel verdwijnt. Alle ideeën moeten namelijk gekoppeld zijn aan de vooraf bepaalde doelen. Bovendien: ingebrachte ideeën zijn (idealiter) altijd gebaseerd op data over de gewenste features. Dit voorkomt ongefundeerde discussies over het wel of niet toevoegen of aanpassen van een feature.

Maar let op: wees voorzichtig met feature requests gebaseerd op data. Wijst de data uit dat een feature belangrijk is voor de eindgebruiker, dan nóg heeft het geen zin om deze toe te voegen als het niet bijdraagt aan het einddoel. Zoals Des Traynor, co-founder van Intercom, zegt:

“Zelfs als de data solide is en de toename in engagement hoog is, moet je jezelf afvragen of deze feature binnen het doel van het product past. Voeg jij Tetris toe aan je app, dan zul je waarschijnlijk een boost in engagement zien, maar betekent dit dat je product beter geworden is?”

Een derde verandering in je team is focus. Alle belangrijke teamrollen werken én denken richting de vooraf bepaalde resultaten. Met RDD heb je één gezamenlijk belang, namelijk: het eindresultaat dat de app oplevert (voor de organisatie en voor de eindgebruiker).

Data-driven houdt in dat elke belangrijke beslissing wordt ondersteund met verklarende data. Aannames en onderbuikgevoelens worden door de data bevestigd óf verworpen. Daarbij is de rol van User Researcher onmisbaar.

De User Researcher evalueert continu (Continuous Validation) met de eindgebruikers of het product daadwerkelijk levert wat men ervan verwacht. User research en testing geeft snel antwoord op de vraag of je aannames kloppen en is mogelijk in elke fase van de ontwikkeling van je product: van concept tot feature, en van klein (button) tot groot (procesflow).

RDD en de Result Roadmap: de 5 stappen

Simpelweg een gewenst eindresultaat bepalen is niet voldoende. Wil je RDD tot een succes maken, dan kun je niet zonder een uitgewerkte roadmap richting dit resultaat: de Result Roadmap. Het is de weg die jouw team aflegt richting het resultaat dat je wenst te behalen.

 

Met een Result Roadmap maak je een scherpe prioritering per doel, waarbij je elk doel voorziet van mijlpalen. Bij The Mobile Company werken we de Result Roadmap uit volgens onze eigen versie van OKRs – de bekende methode van Objectives & Key Results waar o.a. Google en LinkedIn mee werken. Dit doen we vanuit de volgende 5 stappen:

1. Objective – het gewenste eindresultaat (kwalitatief)
2. Goals – het meetbare eindresultaat (kwantitatief)
3. CSF’s – Critical Success Factors: de randvoorwaarden voor succes
4. KPI’s – de voortgang op de Goals
5. OMTM – One Metric That Matters: je hoofdgetal voor deze periode

1. OBJECTIVE – het gewenste eindresultaat

Dit is de heilige graal van het project, de stip aan de horizon waar iedereen naartoe werkt. De Objective bepaalt alle gemaakte beslissingen tijdens het project. Het is de basis van RDD.

Let op: de Objective is niet numeriek; dit komt later bij Goals en KPI’s. De Objective voldoet aan de volgende criteria:

• Het is abstract beschreven
• Het is inspirerend
• Iedereen begrijpt het

Een goed voorbeeld: de nummer 1 navigatie-app in Europa worden.

2. GOALS – het meetbare eindresultaat

Naast een Objective heb je Goals nodig die de Objective meetbaar maken. Aan de hand van Goals bepaal je aan het einde van het project in hoeverre deze een succes was. Een goede goal is altijd tijdgebonden en meetbaar; daarom is er weinig ruimte voor verkeerde interpretaties van het resultaat. Een goed voorbeeld: aan het einde van Q3 heeft de app een marktaandeel van 25%.

3. CSF’s – de randvoorwaarden van succes

Hoe inspirerend en geweldig je Objective is: het moet haalbaar en realistisch zijn. Om dit te bepalen verzamel je in een brainstorm alle essentiële randvoorwaarden die nodig zijn voor het behalen van de Objective. Enkele voorbeelden:

• Je wilt je sales dit kwartaal verhogen. Maar als je operatie geen extra capaciteit heeft om de projecten uit te voeren, is dit zinloos.
• Je wilt een nieuw product op de markt brengen. Maar zonder draagvlak vanuit de directie, lukt het niet.
• Je wilt je salesfocus verschuiven van MKB naar corporate bedrijven. Maar als je product nog niet is afgestemd op corporates, vind je geen aansluiting op de markt.

Je bepaalt goede CSFs aan de hand van de volgende statement: ‘Om <GOAL> te bereiken is het behalen/bereiken/hebben van <A,B,C> de minimale vereiste. Of, meer concreet: ‘om aan het einde van Q3 een marktaandeel van 25% te bereiken met de app, moeten wij nieuwe gebruikers aantrekken en converteren naar klanten.’

4. KPI’s – de voortgang op de Goals

Nu je weet wat je wilt bereiken, wil je weten waar je staat wat betreft het behalen van je Goals. Dit stel je vast in een ‘Key Performance Indicator’ (KPI). Met behulp van een KPI kun je monitoren welke acties er nodig zijn om het betreffende doel te behalen. Vaak is de KPI direct gekoppeld aan je Goal. Vanuit het eerdere voorbeeld is dan de KPI: het marktaandeel uitgedrukt in procenten.

Vaak is de beslissende keuze voor de KPI: in welke eenheid je het meet. Bijvoorbeeld: X per maand, of X per jaar.

5. OMTM – je hoofdgetal voor deze periode

Veel teams kiezen meerdere Goals en KPI’s. Echter, idealiter wil je naar één hoofddoel per periode werken. Dit is je OMTM: je One Metric That Matters.

Goals zijn vaak gericht op lange termijn doelen. Daarentegen is een OMTM periode-specifiek. Met de OMTM focust je team zich op doelen die binnen ‘zichtbare’ tijd haalbaar zijn. Dit creëert een gevoel van haalbaarheid en motivatie. Bovendien is je OMTM altijd een ‘snel cijfer’ – idealiter verandert dit getal dagelijks.

Een goede OMTM heeft 3 eigenschappen:

1.  Het is overkoepelend. Hiermee bedoelen we dat de OMTM invloed heeft op meerdere belangrijke KPI’s. Het is geen losse, op zichzelf staande KPI. Als je deze OMTM in beweging brengt, heb je zekerheid dat de app op meerdere vlakken succesvol wordt.
2.  Het is snel én vergelijkbaar. Het is snel te beïnvloeden, en tevens per periode vergelijkbaar. Voorkom dat het een totaalcijfer wordt dat je niet met een voorgaande periode kunt vergelijken. Een totaal aantal gebruikers zegt niet veel, behalve als je deze KPI per periode vergelijkt.
3.  Het zet aan tot actie. De OMTM moet dusdanig belangrijk en overkoepelend zijn, dat wanneer het niet stijgt, het team zenuwachtig wordt. Het tegenovergestelde moet ook waar zijn: dat het verhogen van dit cijfer jouw team inspireert tot actie.

Samenvattend

• Met strikte Feature Driven Development loop je een risico op het bouwen van (te veel) onnodige of overbodige features – features die onvoldoende of niets bijdragen aan het eindresultaat. De juiste features bouw je met Result Driven Development, omdat je hier alle beslissingen maakt vanuit het gewenste eindresultaat.
• Het gewenste eindresultaat bepaal je op basis van de eindgebruiker van de app én jouw organisatie.
• Wil je Result Driven Development laten slagen in jouw team? Dan is een verandering van mindset cruciaal. Het belangrijkste is dat alle aannames en ideeën gestoeld moeten zijn op data, en meer exact: op data gelinkt met je gewenste eindresultaat.
• Start je met Result Driven Development? Zorg dan voor een juiste en volledige Result Roadmap, waar je jouw strategie uitwerkt van het kwalitatieve hoofddoel (Objective) naar de tussentijdse deliverables.
• Zorg ervoor dat je elke periode één hoofd KPI hebt (One Metric That Matters). Dit zorgt voor focus en alignment in je team.

Onze 7 tips voor een succesvolle Result Roadmap

1. Blijf niet hangen. In het vinden van de juiste woorden. Of bij het kiezen van de perfecte KPI’s. Het is beter om snel een bijna juiste versie van je roadmap uit te werken, dan heel lang op zoek te gaan naar een ideale versie (zie ook punt 7).
2. Delegeer. In het kader van punt 1: kies 1-2 personen om de uitgewerkte doelen goed te beschrijven. Doe dit snel: het liefst de dag na de sessie.
3. Delegeer (2). Delegeer vooral de facilitatie. Waarom? Omdat het niet werkt wanneer de facilitator óók inhoudelijk mee discussieert. En: kies je voor facilitatie, dan kan ons team jou adviseren en begeleiden.
4. Haak de juiste mensen aan. Stel voor de Result Mapping sessie een team samen bestaande uit de senior/middle management en de Product Owner. Indien nodig haak je specifieke experts aan, bijvoorbeeld voor customer service of HR.
5. Zorg voor een interne roadshow. Zorg na de sessie voor een visuele weergave van je plan en communiceer deze intern. Doe dat in een online presentatie of een fysieke sessie. Neem de rest van de organisatie mee. Vraag feedback, creëer een open gesprek!
6. Vraag niet té veel meningen. Herkenbaar: te veel meningen geeft onnodig veel vertraging. Je loopt het risico op ‘analysis paralysis’, waarbij je alle meningen analyseert en uiteindelijk niet tot actie komt.
7. Wees flexibel. Blijkt halverwege het project dat een specifieke Goal niet juist is gekozen? Verwijder deze, of pas het aan.

Dit artikel is onderdeel van de blogserie ‘App Development met Hybride Teams: 4 Praktijklessen van The Mobile Company’. 

Wil je direct aan de slag?

Heb je een aankomend project en wil je een strakke Result Roadmap neerzetten? Of heb je al een app en ben je op zoek naar strategische aanscherping? Neem dan vandaag nog vrijblijvend contact met ons op.