Hoe maak je een productroadmap? 4 basisstappen | Bedrijfsstrategieën #8

Wat is een productroadmap?

De productroadmap is een document dat informatie bevat over de visie van het opkomende product, het plan om eraan te werken, prestatie-indicatoren en alles wat het team in staat stelt te bepalen waar ze zich daadwerkelijk bevinden en of ze vooruitgang boeken. Het wordt meestal gepresenteerd in de vorm van een diagram.

Maar het presenteren van de productroadmap op deze manier is geen regel die in steen is gehouwen. Je kunt het op elke manier presenteren die je wilt. Het belangrijkste is dat het begrijpelijk en duidelijk is voor het publiek. Over dat onderwerp is het vermeldenswaard dat je meer dan één roadmap kunt hebben. Dat wil zeggen, de inhoud moet altijd hetzelfde zijn. De vorm waarin de informatie wordt gepresenteerd kan echter variëren, afhankelijk van wie de ontvanger is.

Productroadmap en zijn ontvangers

Dat komt omdat verschillende teamleden verschillende rollen spelen in de levenscyclus van een product, en om hun rollen beter te begrijpen, moeten managers hun taal spreken. Hoe past dit in de praktijk? Laten we een voorbeeld nemen en het op de roadmap zetten. Laten we het “een zakelijke hypothese verifiëren” noemen en het ons doel voor Q1 maken.

Misschien is de projectmanager duidelijk over het doel, maar wat is er met de rest van het team? Niet noodzakelijk. Voor elke afdeling kan dat doel iets anders betekenen, omdat elke afdeling verschillende taken moet uitvoeren binnen dat doel. Bijvoorbeeld, ontwikkelaars moeten een MVP (een product met minimale bruikbaarheid) bouwen, en het marketingteam moet e-mailadressen verzamelen.

En dit leidt ons tot de volgende vraag.

Wat moet een productroadmap bevatten?

Behalve jij kan niemand echt zeggen wat dat is, omdat elk product anders is. Elk product heeft verschillende specificaties en vereist een andere strategie. Dus elke keer moet je je roadmap afstemmen op de doelen en middelen die je hebt. Wat we echter kunnen doen, is gebieden identificeren die het overwegen waard zijn. Het is echter belangrijk om ze te beschouwen als potentiële kansen, niet als een set kant-en-klare elementen.

Dingen die je in een productroadmap moet opnemen:

• Productvisie – welk probleem van wie lost ons product op, en hoe doet het dat?
• Zakelijke doelstellingen – welke zakelijke doelen zullen we bereiken door het product te lanceren?
• Deadlines en mijlpalen – welke fasen moeten we doorlopen en wanneer om een product op de markt te brengen?
• Functies – welke functies moet ons product hebben om aantrekkelijk te zijn voor ons publiek? Welke daarvan zijn essentieel?
• Teams – wie is betrokken bij de implementatie van het product? Wie is verantwoordelijk voor wat?
• Feedback en iteraties – welke informatie hebben we van ons publiek verkregen die we in toekomstige productiteraties in overweging zullen nemen?
• Middelen – welke middelen, inclusief technologie, hebben we nodig om een waardevol product op de markt te brengen dat voldoet aan de verwachtingen van ons publiek en onze zakelijke doelen bereikt?
• Succesfactoren – welke indicatoren helpen ons om de voortgang van het product te bepalen?

Hoe maak je een productroadmap? Eerst een bepaalde aanname.

In contact met de markt en potentiële klanten zal het product veranderen. Dus de productroadmap kan niet “stil blijven staan.” Het moet ook veranderen en meegaan met feedback. Het is een “levend” document. Vergeet dat niet.

En hoe maak je het? De volgende vier stappen kunnen je daarbij helpen.

Stap 1. Productvisie en behoeften van het publiek

De eerste stap in het creëren van de productroadmap is het identificeren van zakelijke doelen en hypothesen, evenals de behoeften van het publiek voor een bepaald project. Wat bedoelen we daarmee?

• Zakelijke doelstellingen. De productroadmap moet twee vragen beantwoorden. Wat doen we – “Welk product gaan we bouwen?” en waarom doen we wat we doen – “Waarom willen we dit product bouwen?” En het management is verantwoordelijk voor het definiëren daarvan. Behalve dat de visie en de doelen bekend moeten zijn bij productontwikkelaars. Dus het belangrijkste in de eerste stap is de dialoog tussen de ene partij en de andere.
• Zakelijke hypothesen. Het is veiliger om te hypotheseren dan aan te nemen dat onze productvisie zeker zal voldoen aan de behoeften en problemen van ons publiek. Deze benadering verlegt de verantwoordelijkheid voor mogelijke marktfalen van het team, moedigt experimentatie aan en opent het voor veranderingen in de roadmap.
• Behoeften van de ontvangers. Het begrijpen van de behoeften van je publiek bepaalt de vorm van je toekomstige product. Daarom zijn marktanalyse, gebruikersonderzoek en het verzamelen van feedback essentieel in de vroege stadia van productontwikkeling. En onthoud dat de roadmap slechts een deel is van een groter geheel. We creëren de roadmap niet omwille van de roadmap.

Stap 2. Productconcept en het selecteren van functies

Na het definiëren van de zakelijke doelen en het begrijpen van de behoeften van je publiek, is de volgende belangrijke stap om na te denken over het productconcept. Dit is de fase waarin we definiëren hoe het product eruit zal zien en welke functies het zal hebben. Het is belangrijk om je te concentreren op de waarde die het product voor de ontvanger zal bieden.

Bijvoorbeeld, als we bepalen dat de meest kritische behoefte van onze klanten “de mogelijkheid om bestanden op te slaan” is, dan kunnen we ons afvragen welke oplossing die specifieke behoefte het beste zal vervullen en of we de middelen hebben om zo’n oplossing op de markt te brengen.

Het antwoord op deze vraag zal in feite een zakelijke hypothese zijn. Totdat we het confronteren met de markt, kunnen we niet 100% zeker zijn dat het productidee daadwerkelijk aan de behoeften van potentiële klanten zal voldoen. Het is de moeite waard om te testen.

En een minimum viable product (MVP), de eenvoudigste versie van het product die een minimale set functies bevat, kan nuttig zijn voor het uitvoeren van de test.

Met een idee voor een MVP of zelfs een afgewerkt product, leren we de lijst van functies die we moeten implementeren, en zo zetten we ze op de roadmap. Maar voordat we dat doen, laten we nadenken over middelen.

Stap 3. Identificeren van middelen

De derde stap in het bouwen van de productroadmap is het identificeren van middelen. Wat hebben we echt nodig om het product te laten werken? Kapitaal, mensen, tijd, tools? Wat is het? Het is belangrijk om dit van tevoren te weten, omdat de keuze van middelen bepaalt hoe het doel zal worden bereikt, en dus invloed heeft op het plan en de productroadmap zelf.

Bijvoorbeeld, als je besluit om een MVP te bouwen in de vorm van een eenvoudige mobiele app, kunnen twee ontwikkelaars het misschien niet in twee maanden doen. Wat dan? Je kunt meer mensen aannemen, het werk uitbesteden of de deadline wijzigen. Het wijzigen van middelen beïnvloedt de weg naar je doel.

Stap 4. Verdelen in fasen en het stellen van een tijdschema

Wetende wat voor soort product we willen bouwen en hoe we van plan zijn het te doen, kunnen we verder gaan en het werk in fasen verdelen. Afhankelijk van zakelijke ervaring en marktkennis kan het definiëren van de fasen meer of minder gedetailleerd zijn. Soms is het echter moeilijk te voorspellen wat er over drie of vier maanden zal gebeuren.

Daarom is het veiliger om aan te nemen dat we weten wat we in de eerste iteratie gaan doen en vervolgens het plan aan te passen op basis van de feedback die we van de markt krijgen. In ieder geval is een onmisbaar onderdeel van het verdelen van het werk in fasen het toewijzen van deadlines voor hun voltooiing. Over het algemeen kunnen we aannemen dat hoe specifieker de deadline, hoe beter, omdat we meer controle hebben over wat er met het product gebeurt – “Waar zijn we?”

Tegelijkertijd raadt Jeff Lash, wereldwijde productmanager bij Forrester, aan om je deadlines af te stemmen op je mogelijkheden. Lijkt voor de hand liggend. Maar het vergt ervaring. Het is gemakkelijk om in de verleiding te komen om te overschatten en een groot doel in vier kwartalen op te splitsen, denkend: “Dit is wat je moet doen omdat dit is wat je doet.”

Jeff Lash hanteert een iets andere benadering. Hoe voorspelbaarder het werk aan een product is, hoe meer we het in maandelijkse mijlpalen moeten opsplitsen en specifieke KPI’s moeten toewijzen. Maar als we die zekerheid niet hebben, en het project minder voorspelbaar is, laten we dan de mijlpalen en KPI’s op een minder gedetailleerd schema zetten. Bijvoorbeeld, per kwartaal (Q1, Q2, enz.) of zelfs “nu, binnenkort, later”.

Vergeet ten slotte niet dat een roadmap geen product is. Het zal veranderen terwijl je werkt. Dus het is de moeite waard om een open geest te houden en bereid te zijn dit document bij te werken.

Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest, TikTok.