Ideeën prioriteren voor effectieve productontwikkeling
Weten hoe je effectief prioriteiten stelt is een van de belangrijkste vaardigheden van een productmanager. Effectieve prioritering is een sterk punt van succesvolle productteams. Dit stelt hen in staat om snel te handelen en zich te richten op activiteiten met de grootste impact.
Maar prioriteiten stellen is zelden duidelijk of eenvoudig. Productmanagers moeten nadenken en zorgvuldige afwegingen maken. Ze balanceren tegenstrijdige prioriteiten en overwegingen, zoals urgente zakelijke behoeften, langetermijnstrategie, klantaanvragen, concurrentie en veranderende marktomstandigheden.
Aan de andere kant, als prioriteiten niet gebaseerd zijn op inzichten en niet gekoppeld zijn aan resultaten, kan dat een groot probleem vormen. Discussies monden uit in conflicten, er is geen duidelijke manier om tot overeenstemming te komen, en keuzes worden gemaakt op basis van onderbuikgevoel of de meningen die het luidst geuit worden.
Prioriteiten stellen is zowel kunst als wetenschap
Voor de beste resultaten moet bij prioriteiten stellen gestructureerde methoden worden gecombineerd met kwalitatieve overwegingen, zodat er ruimte is voor intuïtieve besluitvorming.
Structuren zoals RICE of de impact vs. effort-matrix kunnen helpen om het gesprek te structureren. Maar je moet ook gebruikmaken van de kennis van je teams en belanghebbenden over bedrijfsdoelstellingen en klantbehoeften, bijvoorbeeld op basis van onderzoek, gebruikersinterviews en binnenkomende feedback. Prioriteiten stellen heeft een wetenschappelijk element, maar je moet er wel een beetje creatief voor zijn.
Verschillende organisaties stellen prioriteiten op verschillende manieren. De juiste aanpak hangt af van factoren zoals de bedrijfscultuur, de teamgrootte, de looptijd van een product en wie het laatste woord heeft bij de besluitvorming (zoals bij bedrijven die worden geleid door verkoop vs. bedrijven die geleid worden door producten).
Net zoals bij veel andere zaken in de productontwikkeling moeten de prioriteiten voortdurend worden verfijnd. Het gaat erom wat je prioriteert en hoe je dit doet.
Als je aan een product in een vroeg stadium werkt, is de kans groot dat je gefocust bent op de directe behoeften van de klant.
Als je eenmaal hebt vastgesteld dat het product geschikt is voor de markt, begin je na te denken over de activering, gebruikersbetrokkenheid en -behoud, het aanpakken van technische schulden en het klaarmaken van je systeem voor schaalbaarheid.
Voor producten met een langere looptijd kun je prioriteit geven aan distributie en het verkennen van nieuwe omzetstromen, zoals premiumfuncties, partnerschappen en de introductie van nieuwe producten.
Naarmate je team en bedrijf groeien, moet je misschien meer mensen betrekken bij het prioriteringsproces, zoals verkoop-, support- en klantsuccesteams.
Je vindt nooit de perfecte methode die voor altijd werkt. Om al deze redenen hebben we Jira Product Discovery ontworpen als een flexibel canvas, om de juiste gesprekken te ondersteunen over wat belangrijk is voor je bedrijf en product in de groeifase. Geen twee Jira Product Discovery-projecten zijn hetzelfde.
Wat nodig is voor een succesvolle prioritering
Hoewel elk team op een unieke manier prioriteiten stelt, zijn er toch enkele belangrijke elementen die van belang zijn voor een effectieve prioritering. Helaas lopen veel teams vast door ineffectieve prioritering, waardoor ze hun doelen niet kunnen bereiken. Dit is waar je naar moet streven (en wat je moet vermijden) bij het stellen van prioriteiten.
Streef naar | Vermijd |
|---|---|
Prioritering waarbij verschillende soorten investeringen in de loop van de tijd in evenwicht worden gehouden, zoals gebruikersaanvragen, verkoopkansen, juiste keuzes en statistiekveranderingen | Prioritering die te veel is gericht op output boven resultaten, zoals het leveren van nieuwe functies |
Gezamenlijke prioritering, met inbegrip van het hele productteam en alle belanghebbenden die inzicht hebben in de behoeften van bedrijven en klanten | Prioritering die wordt bepaald door de leiders of die enkel worden afgehandeld door de productmanager |
Voortdurende prioritering op basis van leerervaringen | Eén keer per jaar prioriteiten stellen in de vorm van één grote roadmap |
Het gebruik van gegevens en inzichten om prioriteiten te stellen op basis van kwalitatieve en kwantitatieve gegevens binnen een continue productontdekkingspraktijk | Prioritering op basis van onderbuikgevoel of op klanten en belanghebbenden die het hardst hun mening laten horen |
Prioriteit geven aan een evenwichtige combinatie van productinvesteringen
Binnen veel productteams hebben we gemerkt dat prioritering wordt gezien als 'welke functies moeten we als volgende leveren?'
Dat is vragen om problemen. Zelfs als je externe factoren en marktdruk buiten beschouwing laat, zoals concurrentieverstoringen, leidt het stellen van prioriteiten op deze manier niet tot de gewenste productresultaten.
Je kunt in het begin snel handelen door gewoon nieuwe functies toe te voegen. Maar dat is het makkelijke deel van productbeheer. Het moeilijkste is om producten te maken waar gebruikers nog vele jaren plezier van hebben.
Gewoon alles leveren waar je klanten om vragen, is niet genoeg om van je product een succes te maken. Bijvoorbeeld:
Als je je concentreert op feedback van actieve gebruikers, begrijpen beoordelaars misschien de waarde van je app niet omdat je niet hebt geïnvesteerd in een onboardingproces
Vertraagde functies kunnen ervoor zorgen dat het product moeilijk te gebruiken is, zodat vroege implementeerders anderen niet kunnen overtuigen om deze te gebruiken
Bugs en betrouwbaarheidsproblemen kunnen gebruikers ervan weerhouden belangrijke taken uit te voeren, omdat je je hebt gericht op het leveren van nieuwe functies in plaats van op het onderhouden van de functies die je hebt
Eén manier om deze valkuil te voorkomen is door je roadmap voor producten op te delen in buckets voor verschillende aspecten van het succes van je product. Misschien heb je genoeg buckets voor nieuwe functies, voor het verbeteren van bestaande functies en betrouwbaarheid en voor de focus op distributie.
Investeer proactief in elke bucket, niet als reactie op de crises die onvermijdelijk ontstaan als je ze negeert, en wijs van tevoren een budget toe aan elke bucket.
RUF: betrouwbaarheid, bruikbaarheid, nieuwe functies
We raden je aan om investeringen tussen nieuwe productfuncties in balans te brengen, de huidige ervaring te verbeteren en de technische basis voor betrouwbaarheid van het product te versterken.
Een kader dat veel teams bij Atlassian gebruiken om investeringen in evenwicht te brengen, heet RUF:
RUF = betrouwbaarheid + bruikbaarheidsverbeteringen + nieuwe functies
Zie het RUF-kader als een piramide:
betrouwbaarheid | Het eerste wat gebruikers van je app verwachten, is dat de app gewoon werkt wanneer ze deze openen. Dat wanneer ze belangrijke acties proberen uit te voeren, er geen bugs zijn die hen beletten hun werk te doen. Dat de app hun gegevens niet verliest of dat het lijkt alsof de apps hun gegevens verliest door een slechte gebruikerservaring. Gebruikers moeten geloven dat hun gegevens veilig zijn. Betrouwbaarheid betekent dat je vertrouwen moet opbouwen. Vertrouwen opbouwen duurt lang en het kan ook heel snel kapot worden gemaakt. Eén incident van gegevensverlies of een inbreuk op de beveiliging kan een ernstige bron van verloop zijn, laat staan als incidenten vaker voorkomen. Betrouwbaarheid is de basis van de piramide. Alle problemen hier zouden prioriteit moeten hebben. Je moet alles hier bijhouden en je richten op het oplossen ervan. Investeer in de infrastructuur die deze dringende onderbrekingen mogelijk maakt: processen voor incidentmanagement, systeemovertolligheid, vermindering van technische schulden en meer. |
Verbeteringen in de bruikbaarheid | Hoe langer je aan een product hebt gewerkt, hoe meer functies het waarschijnlijk heeft. De sluipmoordenaar van veel apps is het hebben van te veel functies. Doorgaans is 20% van de functies verantwoordelijk voor 80% van het gebruik. Klanten hechten doorgaans waarde aan apps die één ding doen en die dit goed doen, in plaats van zakmessen die proberen het iedereen naar de zin te maken. Een functie is zelden voor altijd 'klaar'. Deze maakt deel uit van een systeem en dat systeem moet voortdurend worden aangepast. In je roadmap is het belangrijk om budget en resources toe te wijzen om te blijven investeren in je huidige functieset: - Verbeter de gebruikerservaring van veelgebruikte functies - Maak minder vaak gebruikte functies beter vindbaar - Verwijder de functies die geen tractie hebben - Verbeter onboarding om gebruik en conversies te verbeteren |
Nieuwe functies + ideeën | Met een sterke basis kun je nieuwe functies toevoegen. Iedereen weet natuurlijk waar we het hier over hebben 😉 |
De '3 Bucket Planning Guide' voor het prioriteren van nieuwe ideeën
Zelfs als het om nieuwe productideeën gaat, moet je een evenwichtige aanpak volgen om je product tot een succes te maken.
🛑 Je kunt niet zomaar allerlei functies bouwen waar klanten om vragen, want dan loop je het risico dat je alleen maar je huidige gebruikersbestand helpt.
🛑 Je kunt je niet alleen concentreren op het verbeteren van belangrijke bedrijfsstatistieken, zoals omzetgroei, omdat je misschien belangrijke behoeften van klanten negeert.
🛑 Je kunt niet alleen nieuwe revolutionaire ideeën aandragen, anders breng je ook betrouwbaarheid en bruikbaarheid in gevaar
Adam Nash, voormalig VP Product and Growth bij Dropbox, stelde voor om naar 3 punten ('buckets') te kijken (bron: 'the 3 bucket planning guide'):
Statistiekveranderingen zijn productinitiatieven die rechtstreeks bijdragen aan bedrijfsdoelen door de belangrijkste statistieken te verbeteren: aanmeldingen, conversie, retentie, actieve gebruikers, doorverwijzingen, omzet, enz. Initiatieven voor groei vallen doorgaans in deze categorie.
Aanvragen van klanten zijn waar klanten om vragen, zowel nieuwe functies als verbeteringen aan de huidige ervaringen. Als je deze aanpakt, blijven je klanten tevreden, verminder je de belasting voor support en zorg je ervoor dat je product zijn belangrijkste functies vervult.
Blijmakers zijn waar je product innoveert. Dit zijn de functies waarvan je klanten niet wisten dat ze deze wilden, maar die hun leven kunnen verbeteren door hun manier van werken te veranderen. Blijmakers onderscheiden je van de concurrentie en bouwen een gracht rond je product.
Budget toewijzen aan investeringen
Het is belangrijk om bewust te zijn hoe je in elk van deze buckets investeert. Anders daalt je snelheid omdat je team 80% van hun tijd besteedt aan het oplossen van bugs, of omdat de groei van je product vertraagt omdat je niet strategisch nadenkt. Het leveren van zoveel mogelijk nieuwe functies lost dit waarschijnlijk niet op.
De juiste budgettoewijzing voor elke bucket hangt van veel dingen af, maar vooral van de fase waarin je product zit: vóór de PMF (Product Market Fit), na de PMF of volwassenheid.
In de praktijk zou de budgettoewijzing er als volgt uitzien:
Vóór de PMF | Na de PMF | Volwassenheid | |
|---|---|---|---|
betrouwbaarheid | 10% | 30% | 50% |
Verbeteringen in de bruikbaarheid | 20% | 20% | 20% |
Aanvragen van klanten en blijmakers | 70% | 30% | 10% |
Initiatieven voor groei | 20% | 20% |
Onthoud dat dit nooit vaststaat. Je kunt bijvoorbeeld besluiten om gedurende een paar maanden meer te investeren in nieuwe functies en dan terug te gaan en je te richten op verbeteringen aan de gebruikerservaring of het aanpakken van technische schulden.
Maar tijdens het toewijzen en het opnieuw toewijzen, is het belangrijk om rekening te houden met de verschillende aspecten die nodig zijn om je product succesvol te maken en om je investeringen in de loop van de tijd in evenwicht te houden.
Er zijn verschillende manieren om deze investeringen te beheren: je kunt teams hebben die zich toeleggen op één bucket, je kunt ervoor zorgen dat elk team per bucket één initiatief heeft of je kunt elk team op een round-robin-manier werk laten kiezen uit elk van de buckets. Elke aanpak heeft voor- en nadelen, maar het draait vooral om de planning van de levering, dus we zullen die hier niet behandelen.
Investeringen in evenwicht brengen bij Jira Product Discovery
Zo hebben we bij het Jira Product Discovery-team de toewijzing van onze investering geconfigureerd over een periode van zes maanden.
Investeringen voor alle squads
We hebben 4 hoofdthema's: prijzen en verpakking, groei, nog te verrichten werk en technische initiatieven. Elk van deze thema's krijgt een aantal kansen.
Deze kansen worden verdeeld onder de JPD-teams: 5 productteams en 1 technisch team (Sirius, Horizon, Aurora, Juno, Pulsar, X-flow).
Productteams
Elk productteam moet tijd toewijzen, met de volgende verdeling:
60% aan productinitiatieven. Hiervoor stellen ze een roadmap op die bestaat uit twee delen: een voor nieuwe functies en een voor verbeteringen aan de huidige productervaring.
20% aan RtB - Run the Business: op afroep, bugs, enz.
20% aan het oplossen van technische schulden
Hoewel we deze toewijzing niet strikt handhaven, bespreekt elk team hoe dit evenwicht behouden kan worden tijdens hun sprintplanning en maandelijkse review. Meestal blijft dit geldig in de loop van de tijd.
Voor productinitiatieven houden we de feedback die we van gebruikers krijgen in de gaten en bespreken we deze elke week met alle productmanagers. We verdelen de feedback in 'Rotsblokken', XL-investeringen; en 'Keien', grote investeringen.
We hebben een aparte lijst voor 'Kiezelstenen', kleine verbeteringen die 'papiersneetjes' in de gebruikerservaring verhelpen. Deze zijn moeilijk te prioriteren omdat je hun impact niet kunt vergelijken met XL- en grote investeringen. Maar hun impact wordt in de loop van de tijd groter. De verwachting is dat elk team op elk moment één Kiezelsteen aan het oplossen is.
Technische teams
Technische squads hebben een vergelijkbare verdeling. Maar in plaats van productinitiatieven richten ze zich op pure technische projecten om de veerkracht en schaalbaarheid van het systeem te verbeteren.
De weg vrijmaken voor productieve discussies over prioritering
Er zijn veel mensen in je bedrijf die inzicht hebben in de behoeften van bedrijven en klanten waar je product bij zou moeten helpen.
Als je deze collectieve kennis kunt benutten, kun je productbeslissingen met meer vertrouwen nemen en het risico op verkeerde kansen beperken.
Maar dit is gemakkelijker gezegd dan gedaan. Productteams worden soms overspoeld met vragen van het management en de salesteams en worden voortdurend onderbroken met aanvragen voor updates: 'wanneer wordt mijn aanvraag geleverd?'
Als je het goed aanpakt, kun je veel waarde halen uit prioritering omzetten in een teamsport. Een gezamenlijk prioriteringsproces schept duidelijkheid over de missie, de visie en het doel, waardoor teams in het hele bedrijf aan gedeelde doelen werken.
Dit zijn een paar principes die je moet volgen voor productieve, gezamenlijke prioritering.
Formuleer duidelijke verwachtingen
Verwachtingen stellen is cruciaal voor iedereen om effectief samen te werken. Mensen moeten begrijpen wat prioritering eigenlijk inhoudt en hoe ze moeten bijdragen.
Dit zijn een paar belangrijke ingrediënten:
De rollen en verantwoordelijkheden van iedereen in het gesprek
Gedeelde doelen en manieren om succes te meten
Speciale woordenschat en een speciaal kader voor het stellen van prioriteiten
Gevestigde communicatiekanalen en feedbacklussen
Rollen en verantwoordelijkheden toewijzen
Om ervoor te zorgen dat prioriteiten stellen voor iedereen een positieve ervaring is, moet je duidelijk maken hoe ze moeten bijdragen.
Om daarbij te helpen, hebben we drie rollen ontworpen voor Jira Product Discovery: makers, bijdragers en belanghebbenden.
Rol | Wie zijn ze | Verantwoordelijkheden |
|---|---|---|
makers | Het belangrijkste productteam op het gebied van product, techniek, ontwerp en onderzoek. | Het product, het prioriteringsproces en de ideeën van begin tot eind stimuleren. |
Bijdragers | Aanspreekpunten binnen de teams voor verkoop, support, klantensucces, marketing en teams voor andere velden. | Deelnemen aan het prioriteringsproces en belangrijke inzichten verstrekken: aanvragen van klanten, supportproblemen, enz. |
Belanghebbenden | De rest van het bedrijf, meestal verdeeld in twee rollen: management en de rest. | Hebben inzicht nodig in prioriteiten, voortgang en beslissingen en manieren om feedback te geven. |
Prioriteiten voortdurend herzien voor stapsgewijze verbetering
Een ineffectief maar veelgebruikte aanpak voor het stellen van prioriteiten is de 'big bang'-aanpak, waarbij je dit één of twee keer per jaar doet.
Deze aanpak werkt niet, omdat het team zich dan niet kan aanpassen aan factoren die constant veranderen. Je product moet worden afgestemd op marktomstandigheden, gesprekken met nieuwe klanten, implementaties die complexer zijn dan verwacht, enzovoort.
Ook ontstaan er belangrijke gesprekken als gevolg van prioritering aan de hand van de zogeheten big bang-aanpak, waarbij elke beslissing een zeer grote impact heeft.Dit leidt tot druk en verwachtingen die kunnen leiden tot spanningen in de discussies over prioritering. Mensen maken zich zorgen dat ze resources blijven besteden aan de verkeerde dingen, omdat ze niet maandenlang vast willen zitten aan de resultaten van die beslissing.
In plaats daarvan raden we aan regelmatig gesprekken te voeren over prioriteiten met je teams en belanghebbenden. Doe dit minstens één keer per twee weken of per maand. Idealiter doe je het iedere week en stel je de vraag: wat heb je geleerd? Verandert dat iets op basis van waar je momenteel mee bezig bent?
Configureer de productbacklog om deze discussies te organiseren
Om iedereen duidelijkheid te kunnen bieden over elkaars rollen en om beslissingen op schema te houden, raden we aan om je productbacklog op de volgende manier op te stellen:
Makers zijn onderdeel van het Jira Product Discovery-project. Zij bepalen de configuratie (velden, weergaven, enz.) en maken en beheren ideeën, visies en inzichten.
Bijdragers worden aan het project toegevoegd, maar met een beperkt aantal primitieven voor samenwerking. Ze kunnen stemmen, inzichten, opmerkingen en reacties toevoegen.
Belanghebbenden worden niet aan het project toegevoegd. In plaats daarvan publiceren makers weergaves die ze alleen kunnen lezen en die ze met hen delen.
We raden je aan om voor elke doelgroep een aparte weergave te maken:
Deze rolspecifieke weergaves zorgen ervoor dat alle groepen de informatie krijgen die ze nodig hebben op een manier die voor hen relevant is. Het is meteen duidelijk hoe het productteam prioriteiten stelt, welke ideeën worden besproken en hoe het team kan bijdragen. Als ze het daar niet mee eens zijn, zijn er kanalen om dat op een productieve manier aan te geven.
Deze aanpak helpt elke doelgroep om effectief te communiceren, waardoor de samenwerking en afstemming op alle niveaus wordt verbeterd.
Technieken voor gezamenlijke prioritering in Jira Product Discovery
Zodra voor iedereen duidelijk is wat de voorwaarden zijn, wordt het prioriteren een gedeeld en transparant proces. Daarna kun je deelnemen aan echte discussies.
Je productbacklog in Jira Product Discovery is de perfecte plek om prioritering om te zetten in een gezamenlijke oefening. In deze sectie bespreken we verschillende manieren om de productbacklog op te stellen om deze gesprekken te ondersteunen.
Veel van deze methoden maken gebruik van cijfers, zoals beoordelingen van 1 tot 5. Deze zijn van nature subjectief. Het belangrijkste is immers waarom iemand een bepaald cijfer heeft gekozen. Het is van belang is dat iedereen ze begrijpt, zodat het makkelijker is om de relatieve prioriteit van elk idee te bespreken. Zorg bijvoorbeeld dat iedereen op één lijn zit over wat als 'veel inspanning' of 'weinig impact' wordt beschouwd.
Speel de '$10 Game' om denken in beperkingen aan te moedigen
De $10 Game is een interactieve manier om mensen het belang van een idee te laten beoordelen, waarbij rekening wordt gehouden met beperkingen.
Met onbeperkte tijd en resources kan het productteam alles doen. In werkelijkheid zijn beide beperkt. Hierbij kan de $10 Game van belang zijn. Het is een oefening om te denken als een productmanager, en helpt spelers met beseffen hoe moeilijk het werk is!
De $10 Game in Jira Product Discovery.
De methode is eenvoudig: elke deelnemer krijgt een budget van $10 om 'uit te geven' aan ideeën die zij het belangrijkst vinden. Ze kunnen zoveel inzetten als ze willen op een idee, bijvoorbeeld $5 op twee ideeën of $3 op drie. Je kunt natuurlijk ook een budget gebruiken dat niet $10 is.
Vervolgens leggen de deelnemers de redenering achter hun keuzes uit. Waarom vonden ze bepaalde ideeën belangrijk of veelbelovend? Deze aanpak moedigt actieve deelname en discussies aan, waarbij wordt rekening gehouden met alle meningen.
Probeer de $10 Game te gebruiken aan het begin van een prioriteitscyclus, om inzicht te krijgen in hoe iedereen denkt. Of speel juist aan het einde om te zien of iedereen op elkaar is afgestemd.
Gebruik de impact/effort-matrix in gesprekken tussen product- en engineeringteams
De impact/effort-matrix prioriteert ideeën op basis van zowel hun mogelijke zakelijke impact als de inspanningen die nodig zijn om ze uit te voeren.
Deze matrix is een eenvoudige, maar krachtige manier om gesprekken tussen productmanagers en engineers te structureren.
Engineers worden aangemoedigd om hun mening te geven over de complexiteit van de levering. Dat helpt managers om mogelijke snelle winsten of grote kansen vast te stellen en te bepalen waarom specifieke ideeën prioriteit moeten krijgen boven andere.
Houd rekening met de mate van vertrouwen met RICE (bereik, impact, vertrouwen, inspanning)
Voor het RICE-framework wordt gebruikgemaakt van vier overwegingen om een idee te helpen prioriteren: bereik, impact, vertrouwen en inspanning. Dit is een populaire tool voor productbeheer omdat zo de belangrijke factoren op een manier worden behandeld die de meeste belanghebbenden kunnen begrijpen.
De meeste bijdragers zijn gewend om de impact, het bereik en de inspanning die nodig is om het idee te leveren te beoordelen. Maar het RICE-framework heeft het voordeel dat het ook vertrouwen schept in het gesprek.
Is het productteam ervan overtuigd dat dit idee een goede investering is? Of heeft het team voor de zekerheid verder onderzoek en een product- of technische validatie nodig?
Dat helpt het team om uit te leggen waarom een idee rond is, of waarom er misschien meer onderzoek naar nodig is.
Vraag klantgerichte teams om klanten te taggen in ideeën die aansluiten bij hun behoeften
Veel teams die Jira Product Discovery gebruiken, hebben voor deze aanpak gekozen: ze configureren een weergave met een lijst van ideeën om te delen met klantgerichte teams.
Wanneer klanten behoeften hebben die relevant zijn voor één van de ideeën, tagt de sales-/supportmedewerker deze klanten. Vervolgens kan voor elk idee een score worden gegeven op basis van het aantal klanten dat is getagd.
Als klanten verschillende belangen hebben, willen de product- en klantenteams misschien verschillende gewichten toekennen aan verschillende klanten. In het onderstaande voorbeeld worden klanten onderverdeeld in Enterprise, SMB en Startup.
Dit is een eenvoudige, maar zeer effectieve manier om productieve gesprekken tussen product- en klantgerichte teams te faciliteren.
Nog uitgebreider prioriteren kan (maar het hoeft eigenlijk niet)
Er zijn nog veel meer methodes die teams kunnen gebruiken om prioriteiten te bespreken.
Het is echt aan jou om te beslissen wat het beste bij je behoeften past, maar over het algemeen is het ons opgevallen dat hoe eenvoudiger de methode is, hoe beter de gesprekken zijn.
Sommige teams zijn geobsedeerd met het vinden van het 'goede' prioriteitsmodel. Maar het framework is slechts een middel om een doel te bereiken. Het is bedoeld om je te helpen je doelen te bereiken, niet om al je tijd en aandacht op te eisen. Vergeet niet: je beheert je product, niet je prioriteringsframework!
Gebruik de methode die voor jou het beste werkt
Uiteindelijk zijn dit allemaal maar suggesties. Geen twee Jira Product Discovery-projecten zijn hetzelfde, omdat geen enkel bedrijf of team hetzelfde is. Deze methoden zijn allemaal bedoeld om via verschillende kanalen een evenwichtig beeld op te bouwen van:
de doelen van het bedrijf
wat potentiële klanten willen
behoeften van klanten en gebruikers
hoe je de workload van het supportteam kan verlichten
hoe je gesprekken over de verkoop mogelijk maakt
en meer, afhankelijk van je bedrijf en product
Op basis van de unieke behoeften en producten van je team raden we je aan je eigen combinatie van standpunten te maken om je te helpen met prioriteren op welke manier je wilt. Op basis hiervan kan alleen jij beslissen wat je prioriteiten moeten zijn: waar je ja en nee tegen gaat zeggen.
Uit deze discussies komt je roadmap voort.
En nu?
Prioritering is de enige manier om beslissingen te koppelen aan de gewenste productresultaten. Effectieve prioritering betekent sterke roadmaps waarin resources op verantwoorde wijze worden toegewezen, waardoor productteams op schema blijven om bedrijfsdoelen te halen en te reageren op de behoeften van klanten.
Nu zijn we aangekomen bij het laatste deel van dit handboek. We zetten alles wat we geleerd hebben op een rijtje om:
roadmaps te maken waar je teams en belanghebbenden achter staan
We geven voorbeelden van hoe we dit doen in het Jira Product Discovery-team, met behulp van Jira Product Discovery en andere producten.