1 Focus op doelen en voordelen
wanneer u wordt geconfronteerd met een agile, dynamische omgeving—of het nu gaat om een belangrijke verandering in uw product of dat de markt dynamisch is met nieuwe concurrenten of technologieën die verandering introduceren, moet u werken met een doelgerichte product roadmap, soms ook aangeduid als thema en resultaat-gebaseerd.
zo ‘ n roadmap richt zich op doelen, voordelen of resultaten zoals het verwerven van klanten, het vergroten van de betrokkenheid en het verwijderen van technische schulden. Functies kunnen nog steeds bestaan, maar ze moeten worden afgeleid van de doelen en zorgvuldig gebruikt. Ik raad aan om niet meer dan drie tot vijf functies per doel te gebruiken, als vuistregel.
om u te helpen uw agile product roadmap te ontwikkelen, heb ik een doelgericht roadmap-sjabloon gemaakt, de Go Product Roadmap. Het bestaat uit vijf elementen: datum, Naam, doel, functies en metrics, zoals de afbeelding hieronder laat zien. U kunt de sjabloon gratis downloaden vanaf romanpichler.com/tools, en u kunt meer informatie vinden over hoe het te gebruiken in mijn post “de Go product Roadmap”.
2 Doe het nodige Prep werk
voordat u uw roadmap maakt, capture en validate de productstrategie. Ik beschouw de strategie graag als de weg die is gekozen om uw visie te realiseren en de roadmap als een uitvoerbaar productplan dat communiceert hoe de strategie wordt uitgevoerd. Met andere woorden, Ik wil de routekaart graag afleiden uit de strategie.
een effectieve strategie moet de waardepropositie van het product, de doelmarkt, beschrijven. opvallende functies en zakelijke doelen. Zorg ervoor dat u met vertrouwen kunt stellen deze, dat u de nodige product ontdekking en validatie werk hebben gedaan. Anders riskeert u het creëren van een product roadmap die niet realistisch en uitvoerbaar is.
Ik gebruik graag mijn product Vision Board om de productstrategie te beschrijven. Het bestuur legt de visie, de doelgroep, het op te lossen probleem of het te leveren voordeel vast, de belangrijkste kenmerken van het product en de bedrijfsdoelstellingen. U kunt het product Vision Board template downloaden van romanpichler.com/tools / gratis.
3 Vertel een samenhangend verhaal
uw product roadmap moet een samenhangend verhaal vertellen over de waarschijnlijke groei van uw product. Elk doel moet voortbouwen op de vorige, vooral zolang uw product niet volwassenheid heeft bereikt.
om met het juiste stappenplan te komen, probeer de volgende twee tips: Ten eerste, breek de gebruikers -, klant-en bedrijfsdoelstellingen die in de productstrategie zijn vermeld in specifieke en meetbare subdoelen. Bestel dan de subdoelen zodat ze een samenhangend verhaal vormen. Als ik een gezond voedingsproduct wilde aanbieden, bijvoorbeeld, dat mannen van middelbare leeftijd helpt het risico op het ontwikkelen van diabetes type 2 te verminderen, zou het doel van de eerste, eerste release (MVP) kunnen zijn om een gebruikersgemeenschap op te bouwen. Het doel van de tweede release zou kunnen zijn om de betrokkenheid te verhogen, en het doel van de derde zou kunnen zijn om inkomsten te genereren.
ten tweede, weersta de verleiding om doelen en functies toe te voegen aan de product roadmap om krachtige stakeholders tevreden te stellen of een deal te sluiten. Hoewel ik een grote fan ben van collaboratieve productroadmapping, mag dit niet leiden tot zwakke productbeslissingen en compromissen, zie hieronder mijn tips “Secure Strong Buy-in” en “Have the Courage to Say No”.
4 Houd het simpel
wees voorzichtig dat u niet te veel details toevoegt aan uw product roadmap. Houd uw routekaart eenvoudig en gemakkelijk te begrijpen. Leg vast wat er echt toe doet en laat de rest weg door te focussen op de doelen. Houd de functies op uw roadmap grofkorrelig en ontlenen ze aan de doelen. Toon geen epics of gebruikersverhalen op uw product roadmap, maar bewaar ze in de product achterstand. Gebruik de product roadmap als een strategisch productplan en de product achterstand als een gedetailleerde die de uitvoering vergemakkelijkt, zoals de foto hieronder laat zien.
5 veilige Sterke Buy-In
De beste product roadmap is waardeloos als de mensen die nodig zijn om het product te ontwikkelen, op de markt te brengen en te verkopen er niet in kopen. Een geweldige manier om tot overeenstemming te komen is om samen te werken met de belangrijkste stakeholders en hen te betrekken bij het maken en updaten van de product roadmap. Dit stelt u in staat om hun ideeën en kennis te benutten, het creëert gedeeld begrip, en het maakt het waarschijnlijker dat mensen het plan zullen steunen.
het uitvoeren van een gezamenlijke roadmapping workshop is een geweldige manier om iedereen te betrekken en een gedeelde product roadmap te maken, zoals de volgende afbeelding illustreert.
zorg ervoor dat u een ervaren facilitator, bijvoorbeeld uw Scrum Master, vraagt om de workshop te faciliteren. Dit omvat het kiezen van de juiste beslissing regel, bijvoorbeeld, toestemming, en ervoor te zorgen dat iedereen wordt gehoord en niemand domineert.
6 heb de moed om nee te zeggen
terwijl u wilt dat de belangrijkste belanghebbenden de product roadmap ondersteunen, moet u niet de fout maken om ja te zeggen tegen elk idee en verzoek. Dit zou uw product te zetten in een feature soep, een willekeurige verzameling van functies. “Innovatie gaat niet over het ja zeggen op alles. Het gaat over het zeggen van nee tegen alle, maar de meest cruciale functies, ” zei Steve Jobs. Gebruik uw visie en productstrategie om de juiste beslissingen te nemen.
maar voordat u uitlegt waarom een idee of verzoek niet kan worden toegevoegd aan de product roadmap, luister goed naar het idee van de stakeholder. Neem een oprechte interesse in wat het individu te zeggen heeft en probeer haar of zijn onderliggende behoefte of motivatie te begrijpen. Dit maakt de persoon het gevoel gewaardeerd en begrepen, waardoor het waarschijnlijker dat het individu in staat is om een negatief antwoord te horen en is nog steeds bereid om de roadmap te ondersteunen.
7 weten wanneer datums getoond moeten worden
datums op productroadmaps is al een tijdje een onderwerp waar veel over gediscussieerd wordt bij sommige productmensen. Ik raad aan om data of tijdframes te gebruiken op een interne roadmap die het werk coördineert dat wordt uitgevoerd door de interne stakeholders, zoals marketing, sales en support, en het ontwikkelingsteam. Dit helpt u belangrijke afweging beslissingen tussen verzending op tijd en volledig voldoen aan een doel te maken. Bovendien biedt het duidelijkheid voor de stakeholders en ontwikkelingsteams die hen helpen hun werk te doen.
maar als u een externe roadmap gebruikt die wordt getoond aan klanten en gebruikers en vaak wordt gebruikt als een verkooptool, dan stel ik voor geen data of tijdframes te tonen, maar het rangschikken van uw releases en mogelijk gebruik te maken van een nu-volgende-later raster om ze te bestellen. Zie mijn artikel ” moeten Productroadmaps data hebben?”voor meer informatie.
8 Maak uw Roadmap meetbaar
bij het gebruik van een doelgerichte roadmap, zorg ervoor dat elk doel specifiek en meetbaar is, zodat u kunt zien of u het doel hebt bereikt of niet. Als je doel is om klanten te verwerven, bijvoorbeeld, dan vraag jezelf af hoeveel nieuwe klanten moeten worden verworven; en als je doel is om technische schuld te verminderen, bepalen hoeveel van de slechte code moet worden verwijderd of herschreven.
Als u geen doel aangeeft, zal het moeilijk zijn om te zien of u het doel hebt bereikt of niet. Zorg er wel voor dat je een realistisch doel aangeeft en dat de doelen op je roadmap realistisch zijn. Selecteer vervolgens de statistieken die u zullen helpen bepalen of een doel is bereikt en als een release het gewenste voordeel heeft opgeleverd.
9 Bepaal de kosten Top-Down
wanneer uw product een aanzienlijke hoeveelheid verandering en innovatie ervaart, adviseer ik u niet te proberen de ontwikkelingskosten bottom-up te bepalen, maar top-down. Het is vrijwel onmogelijk om de juiste heldendichten en gebruikersverhalen af te leiden uit de roadmap-functies, juiste schattingen van uw team te krijgen en nauwkeurig te anticiperen op de snelheid en de snelheid van verandering in de product achterstand. Zelfs als het je lukt om het te laten werken, zul je eindigen met een te lange en complexe product achterstand die is moeilijk aan te passen en te onderhouden. Wat meer is, het kan dagen duren—en in sommige gevallen weken—om de functies te zetten in goed gedefinieerde eisen en om te komen met gedetailleerde schattingen.
bepaal in plaats daarvan hoeveel mensen met welke vaardigheden waarschijnlijk nodig zijn om de gewenste releases op de roadmap te creëren. Maak gebruik van uw ervaring met het ontwikkelen van soortgelijke producten of eerdere versies van hetzelfde product; Overweeg of er genoeg mensen met de juiste expertise beschikbaar zijn in uw bedrijf, of dat u mensen zult moeten inhuren of contracteren. Dit moet u een indicatie geven van de waarschijnlijke arbeidskosten die nodig zijn. Voeg vervolgens de kosten toe voor faciliteiten, infrastructuur, materialen, licenties en andere relevante items. Voer deze oefening uit samen met het ontwikkelteam.
10 Controleer en pas regelmatig de routekaart
Last but not least: als de omgeving waarin u zich bevindt wendbaar is, zal er waarschijnlijk verandering optreden. Daarom moet u uw product roadmap regelmatig herzien en bijwerken—van elke vier weken tot elke drie maanden, afhankelijk van hoe jong uw product is en hoe dynamisch de markt is.
combineer uw product roadmap en product strategie beoordelingen. Dit zorgt ervoor dat de twee plannen synchroon worden gehouden, dat grotere veranderingen in de routekaart worden weerspiegeld in de strategie en vice versa.