Afgelopen dinsdag 6 juni vond de meest recente editie plaats van de conversie managers meetup. Hierin zijn we met een klein, select clubje de discussie aangegaan over alles wat te maken heeft met product discovery. We delen graag onze inzichten met je.
8 stellingen zijn aan bod gekomen:
- Onder product discovery verstaan we…
- Het verschil tussen design sprints en discovery sprints is…
- We kunnen niet meer om product discovery heen omdat…
- Welke team members / skills zijn onmisbaar in product discovery?
- Wie moet het initiatief en de leiding nemen over product discovery?
- Hoeveel tijd per week/maand besteed je aan product discovery en hoeveel tijd zou je hieraan willen besteden?
- Hoe overtuig je stakeholders / management van het belang van product discovery?
- Hoe prioriteren we insights en ideeën uit verschillende databronnen tbv product discovery?
1. Onder product discovery verstaan we…
Product discovery is een versneld groei proces. Een gelaagd ontdekkingsproces dat uit meerdere fases bestaat die je eigenlijk van tevoren nog niet precies weet. In product discovery doe je snel en goed onderzoek om te bepalen wat je gaat oppakken. Het is een verschil met je CRO proces, waarbij je gaat optimaliseren wat er al bestaat.
Maar het is moeilijk te realiseren. Er zijn idioot veel stakeholders en eilandjes en je maakt het snel te groot. Om dat te voorkomen begin je eerst met het uitwerken van de double diamond, in plaats van meteen met de triple diamond aan de slag te gaan. Maak daarna een lijst met een stuk of 15 experimenten (in de breedste zin) die je kunt doen. Denk bijvoorbeeld aan een smoke tests die gekoppeld is aan een survey of mailing.
Er wordt al vaak iets gedaan met design sprints. Bijvoorbeeld UX-onderzoek en desk research. Maar als je uiteindelijk wilt gaan valideren, loop je vast op hoeveel het je gaat opleveren. Iedereen is tijdens zo’n sprint enthousiast, maar vergeet de north star metric. Je bent een nieuwe lift aan het bouwen terwijl je de wachttijd gevoelsmatig ook met een spiegel kunt verkorten. Of het wordt zo verdraaid dat het onderzoek uitwijst dat een nieuwe lift de oplossing is.
En dat maakt het net zo moeilijk om meer bewijskracht voor je product discovery traject te ronselen. Want veel ideeën en experimenten waarmee je aan de slag gaat, zullen sneuvelen.
2. Het verschil tussen design sprints en discovery sprints is…
Een design sprint is meer een middel om te ‘discoveren’. Een discovery traject houdt ook niet op na 1 design sprint. Het gaat juist om continu valideren of we nog steeds de juiste kant opgaan met z’n allen of dat we moeten bijsturen.
Een design sprint en discovery sprint hebben dan ook veel overeenkomsten. Beide hebben als doel snel ideeën genereren en valideren. Maar toch zijn er wel degelijk verschillen. Bij een design sprint weet je van te voren al wat de stappen gaan zijn. Daarentegen is het bij Product Discovery juist van belang dat je alle aannames laat gaan en gaandeweg de stappen die genomen moeten worden, achterhaald.
3. We kunnen niet meer om product discovery heen omdat…
Het CRO vakgebied wordt volwassener en heeft ons laten zien dat we niet op onze intuïtie kunnen vertrouwen. Steeds meer organisaties werken datagedreven, doen klantonderzoek en voeren experimenten uit op basis van de bevindingen. Ditzelfde proces van een continue feedback loop kunnen we ook gebruiken voor productontwikkeling.
Er is momenteel veel te kiezen en bedrijven innoveren continu. Daarbij komt kijken dat de aandacht van de consument korter wordt en het vasthouden van hun aandacht dus moeilijker. Door continu nieuwe services en oplossingen te onderzoeken en te toetsen kom je sneller tot oplossingen die de meeste waarde leveren voor je klant, en blijf je zo je concurrentie voor.
4. Welke team members / skills zijn onmisbaar in product discovery?
Wat centraal staat in Product Discovery is het achterhalen wat waarde levert voor je klant. Het is goed om een team van mensen te hebben die allemaal vanuit een ander perspectief naar de klantervaring kijken.
- De UX researcher vanwege de grote rol van gebruikersonderzoek binnen organisaties
- Product owners vanwege de centrale rol van de eindgebruiker, stakeholdermanagement, lijntjes in de organisatie en het prioriteren van de activiteiten.
- De CRO specialist voor de toetsing van concepten (validatie)
- De UX designer zorgt voor de visuele uitwerking van de concepten
- De developer zorgt voor de technische haalbaarheid
Het heeft behoorlijk wat gelijkenissen met een product delivery team! De uitdaging in het opzetten van een goed product discovery team zit ‘m in het feit dat er veel verschillende vaardigheden nodig zijn om Product Discovery goed neer te kunnen zetten binnen een organisatie. Daarom is het belangrijk om een multidisciplinair team te hebben waarin het overgrote deel van deze vaardigheden aanwezig is.
Meer weten over product discovery?
Loop je vast in je product discovery traject of wil je gewoon eens gratis een uurtje sparren met een conversie manager? Neem contact op met Desiree!
5. Wie moet het initiatief en de leiding nemen over product discovery?
Om Product Discovery goed uit te voeren wil je iemand die uitgebreide kennis heeft van het proces, korte lijntjes heeft met IT en het gehele proces kan overzien. Een lead product owner. De uitdaging hierin is dat mensen met de juiste ervaring schaars zijn. Uit onderzoek weten we dat het overgrote deel van product owners in Nederland minder dan 2 jaar werkervaring heeft.
Een andere optie is het verdelen van de verantwoordelijkheid over teams heen, als een soort center of excellence, maar dan voor product discovery. Elk team is altijd te druk, maar als je er zelf mee aan de slag gaat, willen ze er vaak graag over mee praten. Door de verantwoordelijkheid te verdelen, heb je ook het mandaat om uren van verschillende mensen te vragen en kan iedereen zijn eigen stakeholders betrekken. Anders moeten discovery trajecten naast de lopende zaken worden opgepakt en komt er vervolgens niks van. Uiteindelijk maakt het niet uit wie de kar trekt, zolang er maar nauwe samenwerking is tussen de verschillende disciplines.
6. Hoeveel tijd per week/maand besteed je aan product discovery en hoeveel tijd zou je hieraan willen besteden?
Product discovery, net als vernieuwende innovatieve ideeën, is nu nog vaak als “bijproduct” voor vele disciplines. En als je al een los product discovery team hebt, staat deze vaak los van de gebruikelijke product teams, wat weer voor een afstand tot elkaar zorgt. Dit zorgt ervoor dat het moeilijk is om er voldoende tijd voor te creëren.
Om tijd vrij te maken voor product discovery is het belangrijk dat er eerst aandacht voor komt vanuit het management. Het moet voor mensen in hun takenpakket komen, voordat ze er goed mee aan de slag kunnen gaan. Het moeilijke is namelijk dat de backlog vaak al propvol zit en product discovery dan wordt gezien als extra workload. Maar dit zou juist het tegenovergestelde effect moeten hebben. Als je product discovery goed uitvoert, weet je als product owner namelijk beter waar je je aandacht en capaciteit aan moet besteden, en wat je juist links kunt laten liggen. Dit zou er vervolgens voor moeten zorgen dat er minder ruis op de backlog komt. Het moet een eis worden; het komt pas op de backlog nadat er product discovery naar is gedaan. Vanuit die business case kan er dan capaciteit worden vrijgemaakt om de hypotheses daadwerkelijk uit te gaan werken.
7. Hoe overtuig je stakeholders / management van het belang van product discovery?
Momenteel is het voor veel mensen nog niet duidelijk wat product discovery precies inhoudt en vindt een management team het vaak ook nog spannend. Het kost tijd en geld en het aantonen van de lange termijn waarde is moeilijk. Hierdoor is het lastig om een goede businesscase te maken. Je weet namelijk nog niet wat je gaat ontwikkelen, dus hoe kan je hier de waarde van berekenen?
Een goed startpunt kan daarom zijn om te leren van het bestaande CRO proces. Met CRO hebben we al laten zien dat valideren werkt. A/B testen uitvoeren is vaak makkelijker, kost minder development en heeft minder stakeholders, maar volgt dezelfde principes. Namelijk hypotheses schrijven op basis van klantonderzoek en deze snel testen en valideren. Als je al een CRO programma hebt draaien, is de stap naar product discovery kleiner dan als je helemaal van nul moet komen.
Een andere manier om product discovery intern op de kaart te krijgen, is het overtuigen door te laten ervaren. Neem het management en andere stakeholders mee in het proces. Laat ze bijvoorbeeld filmpjes zien van klantinterviews, of zet een test ideeëncompetitie op. Op die manier wordt de stem van de klant sterker en de betrokkenheid van de organisatie groter. Hiermee kun je bewustzijn creëren voor de werkwijze binnen de organisatie en kun je je stakeholders gaandeweg de mindset aanleren.
Een derde manier is het maken van een negatieve business case van voorgaande projecten. Dit is misschien wat sluwer, maar hiermee kun je wel laten zien dat het ontzettend belangrijk is dat bepaalde projecten beter van tevoren gevalideerd waren. Achterhaal welke projecten er zijn gedaan en wat die hebben opgeleverd. Hoeveel capaciteit is daarin gestoken? Hoeveel kosten zijn er gemaakt om het op de markt te brengen? Door hier een overzicht van te maken, creëer je een zichtbaar (en eventueel pijnlijk) effect van het gebrek aan product discovery.
… 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.
8. Hoe prioriteren we insights en ideeën uit verschillende databronnen t.b.v. product discovery?
Om de verschillende inzichten en ideeën te prioriteren voor product discovery moet je antwoord geven op enkele vragen, zoals: Op hoeveel klanten heeft het betrekking? Hoeveel impact verwachten we potentieel? Welke KPI’s verwachten we hiermee te beïnvloeden? Hoeveel tijd en geld gaat het ons kosten?
Vanuit de CRO werkwijze weten we al dat er verschillende methodes bestaan om snel en efficiënt te kunnen prioriteren. Denk bijvoorbeeld aan het RICE framework (Reach, Impact, Confidence en Effort), het ICE score model (Impact, Ease en Confidence) of de MoSCoW techniek (must-have, should-have, could-have en won’t-have).
In plaats van te kijken naar de verwachte uitkomst, kun je ook nog prioriteren op basis van het type onderzoek dat je inzet. Gebruik hiervoor bijvoorbeeld de Hierarchy of Evidence om het risico van de opgedane inzichten in te schatten. Idealiter maak je combinaties van de verschillende onderzoeksbronnen om de uitkomsten sterker te kunnen onderbouwen.
Tijdens onze Dialogue Donderdag (DiDo) van 6 april gingen we dieper in op Product Discovery Sprints. Hier kwamen sprekers van o.a. FonQ, Vattenfall en Maxeda vertellen over hoe zij dit uitdagende proces aanpakken. Lees de gehele samenvatting hier.
Wil je er de volgende keer nou ook bij zijn? Dat kan! Op donderdag 29 juni organiseren we DiDo#42: The role of the Product Owner in Experimentation. Inschrijven kan hier. Hopelijk zien we je daar!
