Om richting en focus te geven aan de softwareontwikkeling heb je een productdoel of productvisie nodig. In dit artikel krijg je daarvoor tips en een eenvoudig template met 5 vragen. Daarmee maak je eenvoudig een productvisie voor jouw softwareproduct.

De meeste analisten weten dat het belangrijk is om het doel van het te ontwikkelen softwareproduct helder te hebben. De software zelf is een middel om dat doel te bereiken. Dat was vroeger in het waterval tijdperk al zo en is nog steeds het geval.

Bij een agile aanpak is het nog meer van belang dan bij een traditionele aanpak. In een dynamisch en complexe omgeving heb je een richting, een stip op de horizon nodig om te weten of je nog de goede kant op gaat.

Het productdoel en de productvisie fungeren tijdens de ontwikkeling van de software als vizier, als langetermijndoelstelling waar het team over de sprints heen naar toe werkt

Bij agile requirements maak je gebruik van voortschrijdend inzicht. Je ontdekt en stelt ze gaandeweg het traject vast. Het productdoel is onderdeel van de product backlog en wordt in een productvisie eventueel uitgebreider toegelicht.

Template productvisie

Een productvisie maakt duidelijk welke toegevoegde waarde de software moet bieden, wat het systeem in essentie behelst en waarom dat belangrijk is. Dit zie je terugkomen in de vijf vragen in het template van een productvisie (zie verderop).

Onthoud echter dat het vooral gaat om het duiden van het waarom en het wat. Als dat voor iedereen in essentie helder is heb je een goede productvisie. Het template met de vijf vragen is daar een hulpmiddel bij.

A. Waarom willen we dit

Een productvisie vertelt je waarom de business de software wil laten ontwikkelen, het productdoel. Wat hoopt de business ermee te bereiken, wat gaat het ze opleveren? Hebben ze de nieuwe software bijvoorbeeld nodig om de klanttevredenheid te vergroten, aan wet- en regelgeving te voldoen of om de productiviteit te verhogen?

B. Wat willen we

De productvisie vertelt je wat de software op hoofdlijnen moet kunnen. Welke functionaliteit essentieel is. Het laat zien wie de gebruikers of klanten zijn, welke voordelen de software voor hen heeft en welke systeemeigenschappen daarbij cruciaal zijn.

Let op: Noem alleen de functionaliteit die essentieel is voor het succes van het systeem. Jim Highsmith zegt dit treffend in zijn boek Agile project management:

“Coming up with 15 or 20 product capabilities or features proves to be easy. Selecting 3 or 4 that would incent someone to buy the product is very difficult.”

Beantwoord deze vijf vragen

Het template van een productvisie bestaat uit vijf vragen. Deze vragen gebruik je als leidraad bij het scherpstellen van de productvisie:

  1. Waarom heeft dit product prioriteit en budget gekregen? Waarom is het goed voor onze organisatie?
  2. Voor wie maken we de software? Wie zijn de klanten en gebruikers?
  3. Waarom zitten zij op de software te wachten? Welke meerwaarde heeft de software voor hen?
  4. Wat zijn de Kritieke Succes Factoren? Wat moet het systeem minimaal kunnen?
  5. Hoe onderscheidt het systeem zich van de concurrenten/alternatieven? Wat zijn de Unique Selling Points?

De vijf vragen komen uit het boek Agile product management with scrum van Roman Pichler. Het idee is om ze kort en krachtig te beantwoorden en als vision bord te presenteren.

Productvisie en de rol van analisten

Het helder maken en uitdragen van het productdoel en de productvisie is een van de voornaamste taken van de product owner.

In de praktijk laten product owners hier nogal eens steken vallen. Of hebben ze hulp nodig om de productvisie helder te krijgen.

Dan kun je als analist veel toegevoegde waarde bieden. Jij beschikt namelijk over de vereiste competenties om de juiste informatie te achterhalen. Doorvragen is een van onze kerncompetenties.

Maar zelfs met de benodigde competenties is het lang niet altijd gemakkelijk om de visie op het te ontwikkelen product scherp te krijgen. Dit komt omdat de meeste business stakeholders, inclusief product owners, in oplossingen denken. In tegenstelling tot de doorsnee stakeholder zijn analisten zich hier wel van bewust.

Als je geluk hebt, kun je het productdoel overnemen uit de projectaanvraag, business case, roadmap of projectplan. Maar doorgaans zijn de daarin geformuleerde doelen niet concreet genoeg of zijn het oplossingen.

Doorvragen

We zeggen het vaker en ook hier geldt dat het belangrijk is om goed door te vragen. Doorvragen naar de reden waarom ze die bewuste oplossing willen.

Vragen die je zou kunnen stellen zijn bijvoorbeeld:

  • Wat levert het op en voor wie? Welke voordelen heeft die oplossing voor de business?
  • Waarom is de opdrachtgever bereid veel geld aan deze software-aanpassingen uit te geven?
  • Wat gaat er mis als we deze oplossing niet bouwen?

In De kunst van het doorvragen geven we eenvoudige technieken en 6 manieren om doelen uit te vragen.

Als voor iedereen helder is welke toegevoegde waarde de software moet bieden, wat het systeem in essentie behelst en waarom dat belangrijk is, is de productvisie goed.

Het kan zijn dat de visie in een paar uur helder is, maar meestal zijn daar meerdere verdiepingssessies voor nodig.

Wat zijn jouw ervaringen met doorvragen? Merk jij ook dat stakeholders het irritant vinden als je te veel waarom-vragen stelt? Vertel ons je ervaring in een reactie onder dit artikel.

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

3 reacties

  • Niels de Grooth

    Dit lijkt op een “Project Initiaton Document” die inderdaad heel handig is om voor je project de stip op de horizon te zetten.

  • Henk

    Je zou mijns inziens bij de business case mogen beginnen in deze rol.

  • Priya

    Productontwikkeling en projectmanagement zijn complementair en tegelijkertijd ook verschillend.

    Een project is een tijdelijke inspanning die wordt ondernomen om een uniek product of een unieke service te creëren. Bij een project is er een duidelijke definitie, op voorhand vastgelegd, van wat er precies op een bepaalde datum moet worden opgeleverd. Met een PID en een business case wordt vaak min of meer getracht om vooraf duidelijkheid te geven.

    Anders dan bij een project is er bij productontwikkeling, zeker als het gaat om agile productdevelopment, geen duidelijke definitie vooraf van wat er precies noch exact wanneer moet worden opgeleverd. 

    De behoeften van klanten evolueren van nature in de loop der tijd en producten evolueren om aan deze klantbehoeften te voldoen.

    In agile productdevelopment zijn er in principe geen keiharde deadlines. Een klant verwacht dat een product NU aan zijn behoeften voldoet, niet op een ver punt in de toekomst. Productontwikkeling is dus geen tijdelijke of incidentele onderneming. Het is een continu proces om nieuwe features op een empirische wijze te ontdekken, te toetsen, op te leveren en al doende/zodoende een product in de loop der tijd steeds verder te verbeteren. En precies op dit punt helpt de productvisie. Als leidraad, om niet af te dwalen en de focus te houden op klantwaarde en bedrijfsdoelen.

Geef een reactie