Betekenis van ‘product’ in SCRUM agile

Als je in een SCRUM team werkt, weet je ongetwijfeld dat je een product backlog en product owner moet hebben. Maar wat is de betekenis van een product in agile precies? Voor sommige teams kan dit een nogal fundamentele vraag zijn. Een organisatie kan immers geen geschikte product owners, teams en rollen identificeren zonder eerst te weten wat de definitie van haar producten zijn. En als er één product backlog per product moet zijn, moeten we weten wat onze producten zijn voordat we voor elk een product backlog creëren.

Wat is de betekenis van een ‘product’?

Om dit onderwerp te kunnen beslechten start ik met mijn eigen, ietwat generieke, definitie van ‘product’:

Een product is een item (fysiek of niet) dat tot stand komt via een proces en dat wordt aangeboden om aan de behoeften en wensen van de doelgroep te voldoen.

Een e-tail organisatie als voorbeeld

Als voorbeeld neem ik een bedrijf met een webwinkel. Ik heb zelf gewerkt voor meerdere ‘traditionele’ retail organisaties die toetraden tot de wereld van online verkoop. Nadat SCRUM werd geïntroduceerd werd meestal altijd de vraag gesteld wat wij (agilers) nu eigenlijk de betekenis achten van het woord ‘product’ in onze functienamen en backlogs. Waarbij de meeste retailtijgers producten louter zien als fysieke spullen die over de toonbank gaan, zijn er uiteraard ook diensten die benaderd worden als product. Denk aan aanvullende garantiepakketten op goederen of tailor-made advies.

Marketeers en techneuten gaan graag nog een stap verder. En dat is precies de aanleiding van deze blog. Als ik teruggrijp naar een e-tail organisatie dan hebben wij vele software en hardware nodig die wellicht ook als product gezien kunnen worden. Ik neem als voorbeeld de webshop. Dit transactiemiddel kan gezien worden als service voor onze klant, aangezien deze helpt in het eenvoudig kopen van producten, het bekijken van aanbiedingen maar ook van vacatures. Is de webshop zelf dan ook een product? Ik vind van wel, aangezien deze bijdraagt aan de behoefte en wensen van onze doelgroep “de klant”.

Een ander goed voorbeeld is monitoring van klikgedrag van deze betreffende webshop. Maar hoe draagt deze dan precies bij aan de behoefte en wensen van onze doelgroep? Nou, dat heeft meer te maken met de definitie van jouw doelgroepen. Collega’s (marketeers in dit geval) zijn immers ook een doelgroep. Door middel van monitoring zijn zij in staat om te begrijpen hoe klanten zich bewegen op de webshop, waar diens interesse ligt en waar zij tegenaan lopen. Dit geeft de marketeer de mogelijkheid om klanten relevantere aanbiedingen en een prettigere journey te presenteren. In dit geval is dus zowel de webshop als diens monitoring een product.

Hoe definieer je een product binnen SCRUM agile?

Met de bovenstaande relativering in het achterhoofd wil ik graag verder inzoomen op de wijze waarop producten kunnen worden bepaald bij een SCRUM aanpak. Ik heb vaak geworsteld met het vraagstuk: hoe vorm ik mijn producten op een manier dat deze:

1. Bijdraagt aan de bedrijfsvisie;
2. Resulteert in zo goed mogelijk opererende SCRUM teams, met zo min mogelijk onderlinge overlap;
3. Meest belangrijk: zoveel mogelijk waarde brengen voor mijn doelgroep en organisatie;

Bij punt 2 moet ik een kanttekening maken, aangezien ik ook heb ervaren dat het teveel scopen van teams kan leiden tot tunnelvisie en daarmee zgn. ‘suboptimalisatie’. Hiermee wordt te veel gefocust op één aandachtsgebied (van het totaal) waarbij controle op het grote geheel verloren raakt. Hoewel organisaties al hun producten willen definiëren om het werk zo goed mogelijk te beheren, willen ze hun focus niet zozeer beperken dat ze het geheel niet zien omdat ze gefixeerd zijn op de afzonderlijke aandachtsgebieden. Als zodanig willen organisaties elk product zo breed mogelijk definiëren. Maar dan zijn we weer terug bij af.

Stappenplan

De productdefinitie omvat meerdere componenten, activiteiten en biedt oplossingen voor de behoeften en problemen van jouw doelgroep(en). Je kunt jouw product definiëren door de volgende twee stappen te volgen:

1) Identificeer de vereiste organisatie-elementen om het product te ontwikkelen en te onderhouden.

Je begint met de SCRUM teams die je momenteel producten noemt, de activiteiten, de mensen en de processen die je momenteel in je aandachtsgebied hebt. Vervolgens bestudeer je hoe het werk binnen dit aandachtsgebied eruit ziet, zodat je de soorten afhankelijkheden begrijpt die er zijn om je product te ontwikkelen, te onderhouden en in stand te houden. De typische stappen om dit te bereiken zijn:

• Identificeer je doelgroep(en) (de eindgebruikers) binnen het aandachtsgebied;
• Bepaal enkele regelmatige behoeften die deze eindgebruikers hebben of taken die ze moeten voltooien;
• Identificeer enkele functies voor elk van de gebruikers die ze helpen om aan hun behoeften te voldoen of hun werk uit te voeren;
• Identificeer de grenzen waarlangs de gebruikers de functies gebruiken om aan hun behoeften of uitdagingen te voldoen (bijvoorbeeld een browser, app of interface);
• Vervolgens identificeer je de organisatie elementen die nodig zijn om de functie te bouwen en de klant tevreden te stellen. Dat doe je door te bestuderen hoe elke feature door je organisatie stroomt en in de handen van je klant belandt. Je doorloopt hiermee alle componenten, systemen, mensen en processen.

2) Leg de ‘revenue streams’ bloot

Een juiste productdefinitie identificeert een aandachtsgebied dat breed genoeg is om zogenoemde ‘revenue streams’ te omvatten. Zonder dit zullen de teams binnen een aandachtsgebied waarschijnlijk losgekoppeld zijn van het bedrijfsbelang (waar de échte waarde zit) en in plaats daarvan concentreren de teams zich alleen op het deel van het hele product.

In deze stap stellen we de vraag: produceren de geïdentificeerde organisatie elementen een product dat inkomsten genereert voor de organisatie? Of ontbreken er onderdelen om dit te doen? Onze voorkeur gaat uit naar het vinden van antwoorden op de volgende vragen:

• Hoe genereren de elementen samen geld? Kan de productdefinitie bijvoorbeeld gebruikskosten in rekening brengen? Verkoop van activa? Abonnementskosten? Licentieverlening? Zo nee, wat moet er dan aan de productdefinitie worden toegevoegd?
• Heeft de productdefinitie een onafhankelijke winst en verlies? Zo nee, welke organisatorische elementen ontbreken?
• Welke zakelijke KPI’s kun je toekennen aan de productdefinitie? Kunt u het bijvoorbeeld een verhoging van het bruto inkomen toewijzen? Een toename van nieuwe klanten? Klanttevredenheid?

Als u niet op alle bovenstaande vragen een zinvol antwoord kunt geven, is jouw productdefinitie te beperkt en moet je deze uitbreiden.

Heb jij jouw producten bepaald?

Gefeliciteerd! Op dit punt heb je een reeks organisatie elementen geïdentificeerd die samen waarde creëren voor eindgebruikers en een onafhankelijke “revenue stream” hebben. Het resultaat omvat doorgaans tientallen componenten, vaardigheden, activiteiten, en er kunnen in totaal honderden mensen bij betrokken zijn. Je gaat ontdekken dat je in de toekomst moet gaan bijschaven. Het is een continu spel van analyseren, leren, bijstellen en weer analyseren.