3 beste sjablonen voor productroadmaps & hoe je ze gebruikt
In een van mijn laatste artikelen hebben we al uiteengezet dat je, als je een succesvol product wilt ontwikkelen, beter een productontwikkelingsproces kunt gebruiken.
Het zal geen verrassing zijn dat de hoeksteen van een goed productontwikkelingsproces een goede productroadmap is. Het is een hulpmiddel dat je helpt je productontwikkelingsproces af te stemmen op je productvisie en je algemene bedrijfsdoelen. Uiteindelijk zijn het de producten zelf die dat pad bepalen!
Daarom is een productroadmapdocument een nuttig hulpmiddel voor productontwikkeling: het helpt je verschillende standpunten over je toekomstige, nieuwe product met elkaar te verzoenen, afhankelijkheden en afwegingen te herkennen en je een overzicht te geven van hoe je de functies moet structureren met betrekking tot de functionaliteiten van je product(en).
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
De 3 belangrijkste dimensies van een productroadmap: de triade ‘kwaliteit, budget, planning’
De belangrijkste maatstaven om je productontwikkelingsproces te beheersen zijn kwaliteit, budget en planning.
Je wilt dat je product een bepaalde reeks functionaliteiten vervult op het gebied van productfuncties (‘kwaliteit’), je wilt dat je product een bepaald maximumbedrag kost (‘budget’) en je wilt dat je nieuwe product op een bepaalde datum klaar is voor marktintroductie (‘planning’). Daarom is productontwikkeling tegelijkertijd altijd een oefening in projectmanagement: het voldoet aan de leerboekdefinitie van een project: ‘een eenmalige onderneming die zorgvuldig wordt gepland om een specifiek resultaat te bereiken’.
Afhankelijk van op welke van deze dimensies je je op een bepaald moment wilt (of moet) concentreren, kun je je productroadmap daarop afstemmen.
Hoe jouw standpunten je productroadmapsjablonen vormgeven
Er zijn verschillende standpunten die je tijdens het ontwikkelingsproces van een nieuw product kunt (en moet) gebruiken:
- PRODUCTONTWIKKELINGSPROCES: Hoe moeten mijn producten worden ontwikkeld?
- PRODUCTVISIE en PRODUCTDOELEN: Hoe moet mijn product eruitzien? Hoe moet het de klant helpen? Waarom?
- BEDRIJFSDOELEN: Waar moet mijn bedrijf vervolgens naartoe?
Natuurlijk kun je nog veel meer van dergelijke standpunten vinden, maar laten we het hier voorlopig bij houden, zodat we beter kunnen illustreren hoe je een productroadmap opstelt.
Verschillende soorten productroadmaps voor verschillende belanghebbenden
Hoewel de daadwerkelijke productontwikkeling altijd wordt aangestuurd door het productteam, dat wordt geleid door een vertegenwoordiger van de productmanagementafdeling van het bedrijf, zijn er andere groepen belanghebbenden die ook profiteren van een productroadmap, maar deze moet wel aan hun behoeften worden aangepast.
Ten eerste hebben we alle organisatieniveaus boven het productteam. De ‘gebruikelijke verdachten’ zijn (let op: sterk afhankelijk van de branche en bedrijfsgrootte!):
- De hoogste leiding van het bedrijf
- De afdeling productstrategie (die zich naast of onder de raad van bestuur bevindt)
- De leiding van een specifieke productlijn of productfamilie
Vervolgens hebben we:
- Organisatieniveaus onder of naast het productteam
- Externe belanghebbenden
De eerstgenoemden zijn de afdelingen die betrokken zijn bij de ontwikkeling van het product en die het productteam ondersteunen: R&D, ontwerp, financiële controle, kwaliteit, productie, inkoop enzovoort. De laatstgenoemden zijn leveranciers, externe ontwikkelaars, dienstverleners en allerlei andere opdrachtnemers enzovoort.
En elk van hen heeft het juiste t ype productroadmap nodig om mee te werken.
Ik kan me voorstellen dat je nieuwsgierig bent om eindelijk een productroadmap-sjabloon of -voorbeeld te bekijken, maar we moeten nog wat voorbereidend werk doen. Uiteindelijk zal alles op zijn plaats vallen. We moeten ook één belangrijk punt verduidelijken: verschillende belanghebbenden kunnen verschillende soorten roadmaps gebruiken voor één en hetzelfde product. Maar:
Er moet één enkele bron van waarheid zijn waaruit je alle ingrediënten voor een specifieke productroadmap haalt.
Soorten productontwikkeling
Een andere factor die bepaalt hoe onze productroadmap eruit moet zien, is het soort product dat we willen ontwikkelen:
Aan de ene kant van de schaal hebben we producten die 100% vooraf gedefinieerd zijn op het moment dat hun ontwikkeling wordt gestart. Denk aan DIN-genormeerde schroeven, uniformen voor het leger of autostoelen die de leverancier precies volgens de voorschriften in het eisenoverzicht aan de autofabrikant moet leveren.
Daarnaast hebben we de enigszins vooraf gedefinieerde producten. Een typisch voorbeeld is een auto. Wanneer de productontwikkeling begint, zijn de belangrijkste parameters van de auto al gedefinieerd (carrosserieafmetingen, aantal deuren, type en vermogen van de motor enzovoort). Andere parameters volgen geleidelijk, naarmate er steeds meer feedback van klanten binnenkomt (er worden bijvoorbeeld focusgroepen gehouden om te beslissen over de bekleding van de stoelen, het ontwerp van het dashboard en de algehele uitstraling van de auto). En wanneer de productie van de auto op de assemblagelijn op het punt staat te worden gestart, worden de laatste technische snufjes die een hogere algehele winstgevendheid beloven, in het productplan opgenomen (paraplu’s in de deurpanelen, fraaie ijskrabbers met het merklogo enzovoort).
Aan de andere kant van de schaal hebben we volledig wendbare producten. Om de autoanalogie te gebruiken: terwijl een typische autofabrikant al een redelijk goed idee heeft van het soort auto dat uiteindelijk uit het productontwikkelingsproces zal komen, zou de wendbare aanpak zijn: “Laten we een voertuig ontwerpen!”—en de eerste iteratie ervan zou een skateboard kunnen zijn (een MVP die de eerste kasstroom van klanten zou opleveren, evenals feedback en wensen van klanten), de tweede iteratie zou een e-step kunnen zijn (omdat de klanten iets gemotoriseerds wensten), en na verschillende iteraties zouden we uiteindelijk een auto zien met vier wielen, een carrosserie, een motor enzovoort.
Voorbeelden van productroadmaps voor het bouwen van een geweldig product
Ik ga een selectie van sjablonen voor productroadmaps presenteren die:
a) Verschillende belanghebbenden op verschillende “vlieghoogten” bedienen (bedrijfsleiding; een leverancier die een vooraf gedefinieerde module aan een fabrikant levert; een wendbaar team dat een applicatie ontwikkelt) en
b) Verschillende soorten producten behandelen (een volledig portfolio van bestaande producten samen met enkele ideeën voor nieuwe producten; een vooraf gedefinieerd product; een wendbaar productidee dat door middel van iteraties wordt gebouwd en verbeterd)
Je kunt ze vervolgens als inspiratie gebruiken om je eigen productroadmaps te bouwen.
Sjabloon voor productroadmap #1 - Het cyclusplan voor het productportfolio
Cyclusplannen geven een “helikopteroverzicht” van de huidige situatie van het productportfolio van een bedrijf.
Wanneer gebruik je deze roadmap?
Stel dat je werkt bij een bedrijf dat een gevarieerd assortiment producten heeft. Dit betekent dat de eerste vraag van de bedrijfsleiding met betrekking tot nieuwe producten is: Welk nieuw product moeten we wanneer en in welke markten lanceren, zodat het in ons bestaande productportfolio en dus in onze productstrategie past? Daarnaast wil de bedrijfsleiding een overzicht hebben van hoe lang bestaande producten al op de markt zijn, hoe succesvol ze waren (verkoopvolume, inkomsten per verkoop enzovoort) en of/wanneer ze uit de markt moeten worden genomen of opnieuw moeten worden uitgebracht als een nieuwe productversie. Het beantwoorden van deze vragen en het opstellen van dit plan is iets waarbij AI in productportfoliomanagement kan helpen.
Hoe bouw je het?
In een type productroadmap dat een “cyclusplan” wordt genoemd, is je leidende dimensie (“x-as”) “Planning”, oftewel een tijdlijn, omdat je je verleden onderzoekt en nadenkt over wanneer je nieuwe producten moet introduceren en oude producten moet uitfaseren.
En bijgevolg zou je y-asdimensie “Kwaliteit” zijn: je bestaande en geplande producten (die uiteindelijk niets anders zijn dan “verzamelingen van functies”).
Voor een beter overzicht zou je ze in een geschikte volgorde groeperen, bijvoorbeeld autoklassen (klein, compact, middenklasse...), typen/varianten (notchback, hatchback, sedan...), (belangrijke) markten enzovoort, en ook ruimte bieden voor nieuwe productinitiatieven.
En om alle aspecten te dekken, zou je vervolgens hun financiële KPI’s (“Budget”) opnemen op de specifieke stroken van elk product.
Sjabloon voor productroadmap #2 - De klassieke productontwikkelingsroadmap (“fasepoort”) voor vooraf gedefinieerde producten
De “klassieke”/”fase-poort”-productroutekaart is het werkpaard van de huidige maakindustrie en wordt doorgaans op operationeel niveau van productontwikkeling gebruikt. Dit betekent dat zowel het productteam als leveranciers er vaak mee werken.
Wanneer je deze productroutekaart gebruikt
Of je er nu van houdt of niet, het merendeel van de (fysieke) producten, vooral in de B2B-wereld (de typische leverancier-klantrelatie), wordt nog steeds ontwikkeld volgens een fase-poortbenadering.
Waarom? Een fase-poortbenadering legt de nadruk op kwaliteit—and kwaliteit is waar je typische B2B-klant naar op zoek is. Zij hebben betrouwbare partners nodig die in staat zijn om exact gespecificeerde onderdelen voor hun eindproduct regelmatig en in grote volumes te ontwikkelen, met alle benodigde functionaliteiten. Als een autofabrikant tienduizenden stoelen bestelt die moeten worden ontwikkeld en vervolgens aan zijn fabriek moeten worden geleverd (vaak just-in-time of zelfs just-in-sequence), moet hij erop kunnen vertrouwen dat elke stoel perfect in de carrosserie past en dat elke stoel binnen een vastgesteld tijdsbestek wordt geleverd.
Daarom moet je deze klassieke productroutekaarten als hulpmiddel paraat hebben en ook ideeën hebben over hoe je ze kunt aanpassen en uitbreiden voor jouw specifieke behoeften.
Hoe je deze opbouwt
In dit geval is je leidende dimensie eveneens tijd, omdat je klant je product op een specifieke datum nodig heeft.
Langs de tijdlijn bouw je kwaliteitspoorten in.
Op deze momenten wordt de voortgang van je productontwikkeling gecontroleerd en kritisch beoordeeld (aan de hand van een vooraf vastgestelde reeks vereisten waaraan op dat moment moet zijn voldaan)—en pas daarna ga je verder met de volgende fase van de productontwikkeling. Bij deze kwaliteitspoorten vink je ook af in hoeverre de vooraf vastgestelde functies van het nieuwe product gereed zijn.
Op de y-as schets je de logische volgorde en afhankelijkheden waarin je je vooraf vastgestelde product ontwikkelt en produceert (denk aan een “Gantt-diagram met mijlpalen”—en over het algemeen raad ik elke productontwikkelaar en productmanager aan zijn of haar kennis van projectmanagement op te frissen).
Als we stoelen als voorbeeld nemen, begin je met een analyse van hoeveel bestaande gereedschappen je voor het nieuwe product kunt gebruiken, hoeveel daarvan je moet aanpassen om het product af te krijgen en welke nieuwe gereedschappen en materialen je moet aanschaffen. Waarschijnlijk heb je al een goed uitgewerkt productieplan (“Hoe bouwen we eigenlijk stoelen op onze assemblagelijn?”) dat je zou aanpassen aan de specifieke eisen van je klant. Vervolgens moet je prototypes gaan bouwen voordat je de productie opschaalt.
Om je productroutekaart uit te breiden, kun je een tweede x-as gebruiken waarop je je budget in de tijd en per fase van de productontwikkeling bijhoudt. Dit is eenvoudig, maar bijzonder nuttig.
Met zo’n indeling van een productroutekaart houd je alle belangrijke meetwaarden van je nieuwe product, het beschikbare budget en de planning bij. Als je nieuwe product slechts gedeeltelijk vooraf is gedefinieerd, kun je ook “controlepunten” in de tijd opnemen waarop jij en je ontwikkelingsteam beslissen over het gefaseerd toevoegen van extra functies. Om dit te doen, verzamel je vooraf mogelijke functies, rangschik je ze en neem je ze vervolgens op in je nieuwe product.
Productroutekaartmodel #3 - De typische productroutekaart voor Agile productontwikkeling
Wanneer we producten op de Agile-manier bouwen, verschuiven we onze focus van tijdlijnen naar productiteraties en de functies die deze moeten bevatten. De reden hiervoor ligt in de Agile-benadering van productontwikkeling:
Wanneer je deze productroutekaart gebruikt
Agile productontwikkeling verschilt fundamenteel van de eerder genoemde fase-poortproductontwikkeling:
In plaats van één specifiek, grotendeels vooraf gedefinieerd en volledig ontwikkeld product te ontwikkelen dat we op de markt brengen en vervolgens maanden of jaren leveren zonder er al te veel aan te veranderen, beginnen we in de Agile-wereld met een algemeen productidee. Daaruit ontwikkelen we een concept en denken we na over hoe de meest basale uitwerking van dat concept eruit zou kunnen zien: het “minimaal levensvatbare product”, oftewel “MVP”. De MVP bevat alleen de meest basale functies. Door de MVP op de markt te brengen, verzamelen we feedback van echte klanten en gebruiken we die feedback om in de volgende iteratie van de productrelease aan nieuwe functies te werken.
Hoe je deze opbouwt
Ik ben me er terdege van bewust dat ik hier kort door de bocht ga, maar omdat de focus van het artikel op de productroutekaart ligt—and niet op Agile productontwikkeling—houden we het eenvoudig:
Als we het Agile-voorbeeld uit het begin van het artikel nemen (“Laten we een voertuig ontwerpen”), zouden de leden van het productteam proberen een basisset functies voor de MVP van een voertuig te bedenken, bijvoorbeeld 4 wielen en een plank. Ze zouden ook andere mogelijke functies bedenken die in een tweede iteratie kunnen worden ingebouwd (deze worden opgeslagen in de zogenaamde “productbacklog”).
Vervolgens begint de eerste sprint en resulteert deze in het MVP. Zodra het MVP wordt uitgebracht, verzamelt het productteam feedback uit de markt en vertaalt deze naar nieuwe functies. Voordat de volgende sprint begint, bepaalt het productteam de prioritering van de functies die moeten worden ingebouwd. Omdat de volgende sprint een verbeterde, door klantfeedback gestuurde versie van het MVP op de markt brengt, verwacht het productteam een grotere acceptatie door klanten. En de cyclus begint opnieuw.
De afbeelding laat zien hoe een agile productroadmap eruit kan zien. Misschien valt het je op dat ik ook graag een inschatting van de inspanning voor elke functie en een ROI-inschatting toevoeg.
Hoe nu verder?
Wil je dieper graven? Bekijk dan het volgende materiaal:
- 6 gratis sjablonen voor een productroadmap om indruk te maken op je belanghebbenden
- 10 beste softwareprogramma's voor productroadmaps
Vond je dit artikel interessant? Abonneer je op onze nieuwsbrief en ontvang zorgvuldig geselecteerde artikelen en hulpmiddelen over productmanagement rechtstreeks in je inbox.
