Het bouwen van nieuwe features is niet alleen tijdrovend, maar ook erg duur. Zeker als je er na het implementeren pas achter komt dat de aanname die je maakte over de werking ervan een foutieve aanname bleek te zijn. De feature wordt niet gebruikt of het zorgt zelfs voor een daling in omzet. Deze ‘Delivery focus’ komt nog erg vaak voor bij bedrijven die agile werken. In dit artikel leg ik uit hoe je dit soort scenario’s in de toekomst kunt voorkomen door je proces anders in te richten.
Delivery focus
Een voorbeeld van een bedrijfsstrategie die we vaak voorbij zien komen is als volgt:
Er wordt een 5 jarenplan geschreven op basis van bedrijfsprestaties, trends, concurrentieanalyses en marktonderzoek. Vervolgens wordt dit 5 jarenplan opgeknipt in jaar- en kwartaalplannen en wordt gekeken welke features gebouwd kunnen worden om de doelstellingen te behalen. Deze aanpak is erg gefocust op de output (Delivery focus): zo veel mogelijk creëren, bouwen, opleveren en sprintpunten halen. We zien dat beslissingen met deze aanpak nog te vaak genomen op basis van onderbuikgevoel en meningen en niet of nauwelijks gebaseerd op data en validaties. Dit standaard proces waarin prioriteiten voor development teams worden gesteld ziet er als volgt uit:
© Dottie Schrok, Productboard, 2022
Product discovery fase
Wat als voorafgaand aan de Delivery fase, waarin features worden uitgewerkt en opgeleverd, een Product discovery fase zit? Hierin worden (pre)validaties gedaan en relevante inzichten vergaard, gebundeld en geprioriteerd om zo de Delivery fase te voeden. Dan zou het proces er als volgt uit zien:
© Dottie Schrok, Productboard, 2022
Product management = risk management
Zo’n Product Discovery fase is zo belangrijk, omdat je hiermee feitelijk risico’s op voorhand verkleint. Er zijn 4 soorten risiconiveaus:
- Waarde risico: of klanten de oplossing zullen kopen of ervoor kiezen het te gebruiken
- Usability risico: of klanten snappen hoe de oplossing te gebruiken
- Haalbaarheid risico: of het haalbaar is voor development om te bouwen
- Bedrijfsrisico: of de oplossing binnen de bedrijfsstrategieën past
Vanuit data en validatie kunnen we vooral de eerste twee risico’s goed beperken in de Product Discovery fase.
Learning backlog opstellen
De Discovery fase draait niet om het opleveren van features, maar om het opleveren van learnings. Feitelijk creëer je in deze fase een learning backlog.
Maar hoe zorg je er voor dat de product discovery fase ook daadwerkelijk de delivery fase gaat voeden, zodat beslissingen en strategieën datagedreven worden genomen? Hier is natuurlijk een grote verandering voor nodig in cultuur en organisatie. Hierover lees je meer in dit artikel over organisatiecultuur van mijn collega Ruben. Waar ik me in dit artikel vooral op zal focussen is het leggen van de basis voor de product discovery fase: het documenteren van alle learnings op een gestructureerde manier en het opstellen van een learning backlog. Hiervoor doorlopen we een aantal stappen:
Stap 1: learnings verzamelen
Organisaties weten vaak meer dan ze denken. Er is heel veel kennis beschikbaar en het is belangrijk om deze te bundelen. Zo zie je duidelijk welke informatie je al hebt en waar nog aanvullend onderzoek naar moet worden gedaan. Om learnings te bundelen gebruiken we bij Online Dialogue het 6V model. Aan de hand van dit model verzamelen we zo veel mogelijk data over de klant, het product, de organisatie en de markt. De 6 V’s zijn:
Vul zo veel mogelijk V’s in als mogelijk en kijk waar je nog informatie mist en nog aanvullend onderzoek wil doen. Beschrijf de learnings uit de verschillende analyses, onderzoeken etc. zo bondig mogelijk en maak er korte statements van.
Bijvoorbeeld:
“Uit gebruikersonderzoek (1) blijkt dat bezoekers moeite hebben met het invullen van het postcode veld in het formulier (2). Dit komt doordat uitleg mist en men direct een foutmelding (3) krijgt.”
“Uit A/B test 302 (1) blijkt dat het verwijderen van het informatie icoon bij verzendkosten (2) zorgt voor een significante uplift in conversie van +2%. Dit komt doordat afleiding weg is gehaald (3).”
(1): Databron
(2): Locatie probleem / situatie
(3): Probleem / situatie omschrijving
Stap 2: customer journey uitschrijven
Start met het definiëren van de verschillende fasen in de customer journey. Deze noteer je van links naar rechts. Het kan helpen om hier ook meteen de verschillende pagina’s op je website en de verschillende marketingkanalen aan te hangen. Hieronder vind je daar een voorbeeld van
Stap 3: behoeften en randvoorwaarden uitschrijven
Vervolgens breng je verschillende behoeftes en randvoorwaarden waar je in je strategie rekening mee moet houden in kaart. Denk hierbij aan:
- Klantbehoeften: deze moet er altijd in staan. Een tip is ook om deze bovenaan te zetten, zodat je jezelf nagenoeg dwingt om hier als eerst bij stil te staan. Wat zijn de vereisten en doelen van klanten? Pak hier inzichten bij uit bijvoorbeeld interviews, eerdere A/B tests, data analyses en klantenservice.
- Bedrijfsbehoeften: wat zijn de behoeften van het bedrijf? Wat zijn de doelen? Het is handig om in deze kolom in ieder geval de missie, visie, KPI en metrics te verwerken.
- Derde partijen: zijn er derde partijen die invloed hebben op de customer journey. Dan is het belangrijk om ook hier rekening mee te houden met de strategie. Denk bijvoorbeeld aan verkopende partijen als je een marktplaats platform hebt.
- Randvoorwaarden: zijn er bijvoorbeeld technische beperkingen, regels om rekening mee te houden vanuit legal of must have features om de strategie te realiseren? Zet deze dan in deze kolom. Deze behoeften en randvoorwaarden noteer je van boven naar onder. Zo krijg je een tabel als deze:
Stap 4: learnings plotten
Ten slotte plot je de learnings en statements uit stap 1 in deze tabel. in welke fase van de customer journey bevindt de learning zich? Sluit het aan op een van de behoeften/randvoorwaarden? Dit ziet er dan als volgt uit:
… Even tussendoor: we sturen elke drie weken een nieuwsbrief met daarin de laatste blogs, teamupdates en natuurlijk nieuws over het aanbod in onze academy. Klik hier om je in te schrijven.
Conclusie
Het is erg belangrijk om een discovery fase toe te voegen aan je bestaande agile processen. Hiermee beperk je namelijk het risico dat geld en middelen worden besteed aan foutieve aannames. Begin hiervoor altijd met het verzamelen van learnings over de doelgroep om zo een learning backlog op te bouwen. Vervolgens kun je al deze verzamelde learnings prioriteren en overgaan naar de validatie fase.
Nu je de know-how hebt om met learning backlogs aan de slag te gaan, kun je al vervolgstappen maken in het opzetten en finetunen van je discovery sprint. Toch blijft het een moeilijk proces waar veel haken en ogen aan zitten. Wil jij meer weten over andere (herkenbare) challenges in het ontwikkelen van discovery sprints? Mijn collega Desiree zal hier binnenkort een vervolgartikel over publiceren. En op 6 april organiseren we weer een Dialogue Donderdag met als thema: Discovery sprints – discover the unknown. Meld je hier aan> DiDo #41
Heb jij meer hulp nodig bij Product Discovery? Wij helpen je hier graag bij! Meld je aan voor ons Product Discovery training.
