Personas in productmanagement

Foto van Sohrab Salimi
Sohrab Salimi
5 min. Leestijd
Deze inhoud is vertaald met AI. Bekijk origineel

Bij productmanagement draait alles om beslissingen. Beslissingen over welke kansen je moet grijpen, welke problemen het waard zijn om op te lossen, welke features de meeste waarde opleveren, wat de beste afwegingen zijn qua time-to-market en welke klanten het belangrijkst zijn. Ook al zul je nooit 100% van de tijd de juiste beslissingen nemen, bij de meeste beslissingen moet je wel goed zitten om van je product een succes te maken.

Persona's (Gebruikersprofielen) als Tool

Een van mijn favoriete tools bij lastige beslissingen zijn Personas (ook wel User Profiles genoemd). Voor iedereen die niet weet wat Personas zijn: het is een techniek om de belangrijkste inzichten uit gebruikers- en klantinterviews vast te leggen, te identificeren en te begrijpen wie de verschillende mensen zijn die ons product gaan gebruiken. Personas beschrijven een denkbeeldige maar uiterst plausibele gebruiker en zijn kenmerken – met name zijn gedrag, zijn opvattingen en overtuigingen, en zijn doelen.

Dit tool werd voor het eerst in 1998 genoemd in een van mijn favoriete boeken, The Inmates are Running the Asylum van Alan Cooper. Als je dit boek nog niet hebt gelezen, zou je dat zeker moeten doen. Het is een klassieker voor productmanagers, designers en ontwikkelaars.

Persona's in verschillende gebieden

Het is goed mogelijk dat je designers al persona's gebruiken in hun designproces. De designcommunity lijkt deze techniek omarmd te hebben, want de meeste designteams die ik heb leren kennen, werken met deze tool. Elk team heeft zijn eigen ideeën over wat goede persona's zijn en hoe formeel je te werk moet gaan bij het opstellen ervan, maar dat is naar mijn mening ook helemaal prima.

Misschien werkt zelfs je marketingafdeling al met persona's. Het gebruik van persona's is in beide gevallen heel vergelijkbaar en ze zijn allebei zinvol, maar ook niet helemaal identiek, omdat ze voor twee heel verschillende doeleinden worden ingezet. Het marketingteam wil erachter komen hoe ze de doelgroep het beste kunnen bereiken en hun onderbewuste emoties kunnen aanspreken. Designers zijn meer geïnteresseerd in de doelen van de gebruikers en hun onlinegedrag.

Voor een productmanager kan dit bijzonder nuttig zijn.

Het juiste gebruik van Personas

Maar hoewel dit een zeer krachtig hulpmiddel is, worden persona's vaak veel te laat in het productdefinitie-/discoveryproces ingezet, want meestal zijn het de designers die dit allemaal aanjagen, maar zij worden meestal veel te laat bij het proces betrokken.

Om het echte potentieel van persona's te kunnen benutten, moeten de productmanagers sterk betrokken zijn bij het opstellen en prioriteren van de persona's en vooral ook bij de daarvoor benodigde gebruikersinterviews en het onderzoekswerk. Het opstellen van de persona's moet een samenwerking zijn tussen de productmanager en de interaction designer – en als je het geluk hebt om er een te hebben – ook met je User Research Team. Maar wat je ook doet, delegeer deze taak niet. Om dezelfde reden waarom de productmanager bij elke usability test aanwezig moet zijn, moet hij ook bij elk gebruikersinterview aanwezig zijn. De productmanager heeft namelijk een diepgaand begrip van de doelgroep nodig, en dat ontstaat pas wanneer hij met zo veel mogelijk gebruikers en klanten spreekt.

Daarom probeer ik de productmanagers ertoe te bewegen om actief deel te nemen aan het opstellen van de persona's en ervoor te zorgen dat ze hier zo vroeg mogelijk in het proces mee klaar zijn.

De designcommunity heeft al zo veel over persona's geschreven dat ik hier niet alles wil herhalen. Toch wil ik een paar specifieke punten noemen, omdat ze voor productmanagers bijzonder relevant zijn.

Persona's als tool voor productmanagement hebben een aantal voordelen:

  •  Personas helpen je om te prioriteren wat belangrijk is. Als je er bijvoorbeeld voor hebt gekozen om "Mary" het doel te maken voor deze release, en een bepaalde feature belangrijk is voor "Mary", dan moet je die ook implementeren. Maar als de feature voor "Sam" zou zijn, dan wordt die niet geïmplementeerd. Zoals je ziet, is het niet alleen belangrijk om te beslissen voor wie deze release bedoeld is, maar ook voor wie die juist niet bedoeld is. Het is een veelgemaakte fout om met een product iedereen tevreden te willen stellen en uiteindelijk niemand tevreden te stellen. Dit proces kan helpen om precies dat te voorkomen.

  • Een van de meest voorkomende fouten van productteams is zichzelf verwarren met de klanten. Over dit onderwerp heb ik al eerder geschreven, maar wat ik echt goed vind aan personas is dat ze ons helpen om dit veelvoorkomende probleem aan te pakken.

  • De meeste producten hebben allerlei verschillende gebruikers – verschillende eindgebruikers, managers, administrators enzovoort, en al snel ga je ervan uit dat je simpelweg voor al deze personen een paar features moet implementeren, wat echter alleen maar in een enorme chaos eindigt. Deels is dit een designprobleem, maar personas kunnen je ook helpen om het belang van deze verschillende gebruikers te prioriteren en te ontdekken waar je misschien een aparte user experience nodig hebt.

  • Personas zijn echt goed geschikt om het hele productteam uit te leggen voor wie het product bedoeld is, hoe deze gebruikers het product zullen gebruiken en waarom het voor hen belangrijk is.

  • In de basis hebben personas (net als de Manifest- /productprincipes) het grote voordeel dat ze het team rond een gemeenschappelijke visie verzamelen. Er zijn letterlijk duizenden details die op weg naar de productrelease opgehelderd moeten worden. De productmanager (of designer) kan onmogelijk al die details zelf afhandelen. Wanneer alle managers, designers, ontwikkelaars, testers enzovoort de productprincipes en personas echt geïnternaliseerd hebben, kunnen ze veel beter de juiste beslissing nemen wanneer ze met een open vraag geconfronteerd worden.

Valkuilen bij persona's waar je op moet letten

  • Sommige teams maken wel persona's, maar zetten niet de volgende stap: de moeilijke beslissing nemen welke persona's prioriteit krijgen. Het heeft geen zin om te zeggen dat een product voor iedereen bedoeld is. Daarmee maak je jezelf iets wijs. Ook al is het voor de meeste productmanagers extreem lastig, ik probeer productmanagers er echt toe te bewegen om elke Release op één enkele persona te richten. Het is niet zo dat deze release niet ook voor andere mensen nuttig kan zijn, maar je focus moet liggen op goed werk leveren voor dit ene specifieke type gebruiker.

  • Soms maken teams persona's op basis van aannames en stereotypen over gebruikers, maar nemen ze niet de tijd om met echte gebruikers te praten en te verifiëren of deze theoretische gebruikers daadwerkelijk bestaan. Ik heb daarbij al vaak verrassingen meegemaakt. Zelfs zo vaak dat ik geleerd heb om mijn eerste indrukken slechts als theorie te beschouwen en me pas een echte mening te vormen als ik daadwerkelijk met de gebruikers heb gesproken.

  • Een veelgestelde vraag is of je je prototypes alleen door de belangrijkste persona's moet laten testen. Natuurlijk moet je ervoor zorgen dat je product een geweldig product is voor degenen voor wie het bedoeld is. Maar je moet ook een aantal mensen buiten de belangrijkste persona's laten testen, want je zult waarschijnlijk niet het geluk hebben dat alleen precies die mensen je product zullen gebruiken. Voor het testen van prototypes moet je dus altijd een hele reeks mogelijke gebruikers beschikbaar hebben.

Als je het nog niet hebt gedaan, denk er dan eens over na om een persona te maken die een typische gebruiker van je belangrijkste doelgroep voor je volgende release beschrijft. Overweeg vervolgens of deze tool je misschien kan helpen bij het nemen van al die lastige beslissingen.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.

Niet-functionele eisen

=> Hoe zet je niet-functionele eisen om in User Stories?

Concurrentievoordeel tijd

=> Hoe geeft Scrum je een concurrentievoordeel?

Praat met onze assistent Praat met onze assistent