Tien manieren om een productroadmap succesvol te presenteren

De presentatie van de productroadmap kan stressvol zijn voor ontwikkelaars en productmanagers. De ene partij heeft hard gewerkt om met een visie te komen, terwijl de andere partij wacht om het onbekende te zien dat hun werk gaat beïnvloeden.

Ik voelde deze spanning toen ik als ontwikkelaar werkte en ik merkte vaak dat ik niet tevreden was met de roadmaps die productmanagement had samengesteld. Ik aanvaardde de beslissingen niet volledig en verliet planningsvergaderingen met een gevoel van 'Nou, dit is niet logisch voor mij, maar als zij dat vinden ...' of nog erger, 'We zullen zelf dingen moeten uitzoeken en het eruit moeten laten zien alsof wat we doen past bij deze roadmap'.

Je zou kunnen redeneren dat het probleem waarschijnlijk was dat ik leed aan NIH (het 'Not Invented Here'-syndroom) en je hebt misschien gelijk. Als ontwikkelaar had ik een zeer sterke mening over wat het juiste was om te doen. Maar nu als productmanager zie ik wat de oorzaak was van deze communicatiestoornis en welke algemene kennis productmanagers uit deze stoornis kunnen putten om hun doel te bereiken met een roadmappresentatie. Immers, als het technische team het ermee eens is en het grote geheel begrijpt, worden dagelijkse ontwerp- en implementatiebeslissingen genomen met de juiste context en krijg je het product dat je voor ogen had.

Hieronder volgen mijn tien beste manieren om teams achter je te krijgen met de presentatie van een productroadmap.

Hoewel modewoorden als 'big data-analyse', 'machine learning' of 'Internet of Things-initiatief (IoT)' bij zakelijke belanghebbenden kunnen resoneren als ankerpunten op hoog niveau, zijn ze geen nuttige en bruikbare items voor technische teams. Engineering moet precies weten wat ze bouwen, hoe dit zich verhoudt tot huidige producten, hoe het moet worden geleverd en wie het uiteindelijk gaat gebruiken en voor welk doel.

Het instellen van thema's op hoog niveau is geweldig voor het structureren van de roadmap en context, maar zorg er wel voor dat je daar niet stopt en goede antwoorden hebt op wat er achter elk item op hoog niveau zit. Als je bijvoorbeeld een thema 'intelligente diensten' hebt genoemd, zorg er dan voor dat je dit thema opsplitst in belangrijke initiatieven en epics die nodig zijn om dit thema te leveren.

Technische teams hebben context nodig om te snappen waarom je iets bouwt op een roadmap. Geen enkel technisch team gaat zeggen 'Vertel me gewoon wat je wil en dan bouw ik het wel'. Integendeel, engineers hebben concreet bewijs nodig om te weten waarom je vraag naar een functie ziet. Laat gegevens voor zich spreken, maar vertel ook een krachtige verhaal vanuit het perspectief van je gebruikers. Gebruik persona's en praat over enkele alternatieven die je hebt uitgesloten en waarom je dat hebt gedaan. Om het hele team te helpen de roadmap te begrijpen, is het 'waarom' net zo belangrijk als het 'wat'.

Als een functie niet goed doordacht of onrealistisch lijkt, maar toch op de roadmap staat, zou dit een overduidelijke signaal moeten zijn. Je wilt niet dat het technische team de indruk krijgt dat ze dingen alleen moeten bouwen omdat je het aan iemand hebt beloofd. Dit kan een verbintenis zijn aan een klant of omdat 'het management dat wil'. Wees dus voorzichtig met het doen van toezeggingen. Zelfs als je een dringende functie achter je hebt die een bepaalde verandering vereist, zorg er dan voor dat je de grondgedachte begrijpt en doorgeeft aan het team, en ga er zelf ook achter staan.

Een visie is goed, maar het is nog beter als iedereen er zeker van is dat die haalbaar is. Het plan hoeft niet precies uitgedacht te zijn, maar als het eerste dat je ontwikkelingsmanager ziet bij het bekijken van een roadmap een enorm knelpunt is (bijvoorbeeld als de roadmap er zwaar ontwerpgericht en frontendgefocust uitziet, maar het team maar één ontwerper heeft en de afgelopen maanden al worstelde met frontend-onderwerpen), dan zul je hem of haar tijdens de rest van je presentatie zien worstelen met de roadmap.

Zorg ervoor dat je vooraf een realitycheck uitvoert met het team en speel met wat-als-scenario's. Je moet antwoorden, een duidelijk actieplan en een beknopte belangenoverweging hebben over 'hoe het kan worden gedaan' voordat je om ieders toewijding vraagt.

Je moet je er bewust van zijn van waar een product en de teamvaardigheden zich vandaag bevinden, tegenover waar je ze wilt hebben. Het is geweldig om door te gaan naar nieuwe terreinen, die mogelijk nieuwe vaardigheden in het team vereisen of die zich wegbewegen van bestaande technologie, maar schrijf niet alleen dromen op over waar je over een jaar zou willen zijn. Bedenk in plaats daarvan hoe je er realistisch kunt komen. Het aantrekken van talent kost tijd, het toepassen van nieuwe technologieën kost tijd en het opgeven van bestaande producten vereist duidelijke toezeggingen en een transitieplan.

Business case? Ja. Technische teams hechten belang aan business cases. Misschien niet in dezelfde mate als het senior management, maar het ontwikkelingsteam in zijn geheel wil weten waarom iets relevant is voor het bedrijf, of het echte resultaten oplevert en hoe dit wordt gemeten. Maak gebruik van de business-ervaring in je technische team. Iedereen heeft een gevestigd belang in het succes van het bedrijf als geheel, en dit kan een geweldige bron van feedback of aanvullende ideeën zijn.

Ook kan volledige duidelijkheid over de impact van het bedrijf en het zien gebeuren een belangrijke extra motivatie zijn. Het behalen van resultaten is bevredigender dan alleen het bouwen en verzenden van een functie.

Engineers willen unieke, innovatieve producten bouwen waar ze trots op kunnen zijn. Als ze telkens hetzelfde moeten doen, werkt dat demotiverend. Zorg ervoor dat je onderzoek doet om te bevestigen dat je idee net zo innovatief is als je denkt. Afgezien van gedemotiveerde ontwikkelaars is de zakelijke impact van het gebrek aan innovatie nog erger.

Desalniettemin zullen zelfs roadmaps altijd een evenwichtsoefening zijn tussen spannende nieuwe functies en technisch niet al te interessante must-haves die gewoon gedaan moeten worden. Probeer ervoor te zorgen dat zelfs het alledaagse op je roadmap motiverend is.

Het creëren van een minimaal levensvatbaar product en vervolgens een eerste versie is één ding, maar alles wat er na de lancering gebeurt, bestaat ook nog: operationele activiteiten, onderhoud, functieverzoeken van gebruikers, continue verbeteringen en nieuwe versies van andere producten en/of platforms die zijn geïntegreerd. Even kort nadenken over wat de uitdagingen en obstakels kunnen zijn na een lancering zal deze zonder veel moeite aan het licht brengen en de engineers zullen je er dankbaar voor zijn dat je deze realiteit niet hebt genegeerd. Ruwe schattingen suggereren dat de eerste inspanning om een nieuwe functie te bouwen vaak maar een derde tot de helft is van de totale inspanning die eraan wordt besteed gedurende de hele levensduur. Met andere woorden: de nasleep is duurder dan de eerste build, en door sommige 'snelle kleine dingen' lopen op de lange termijn de kosten erg op.

Schattingen zijn een goede zaak. Ze geven je een leidraad en worden op elk moment naar de beste kennis van een productmanager gemaakt. Veel aannames over schattingen blijken echter totaal fout te zijn als je eenmaal naar de implementatie gaat of een ontwerp verfijnt. Zorg ervoor dat je de roadmap voorbereidt en presenteert, zodat deze flexibel genoeg is voor wijzigingen.

Een roadmap bestaat om begeleiding te bieden. Het is geen gedetailleerd plan voor uitvoering en iedereen in een softwareteam weet dat. Het is niet nodig om het anders te verkopen dan het is. Dus als je nog niet alle details over een onderwerp hebt, wees daar dan ook open over. Deel wat je hebt, wat de bedoeling is, wat de open vragen zijn en de grootste risico's die nog moeten worden aangepakt. Wijs op gebieden die experimenteren en meer onderzoek vereisen om het 'wat' vast te leggen. Vergeet niet om in de planning rekening te houden met deze experimentatietijd.

Je team verdient een roadmap die duidelijk het grote geheel schetst, maar de realiteit niet verwaarloost. Je team verdient ook een roadmap die motiverend en opwindend is en voldoende details bevat, zodat het hele softwareteam weet wat ze de komende 1-2 sprints te doen staat met het vertrouwen dat ze geweldige resultaten zullen behalen die werkelijke impact heeft voor het bedrijf.

Heb je extra hulp nodig? Bekijk de Roadmapfuncties in Jira Software en het Sjabloon voor productroadmaps in Jira. Of probeer gratis Jira Product Discovery voor PM's.