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.

RUF is een structuur die veel teams bij Atlassian gebruiken om investeringen in balans te brengen:

RUF = betrouwbaarheid + verbeteringen in de bruikbaarheid + nieuwe functies

Zie de RUF-structuur als een piramide:

Reliability Usability new Features prioritization framework

Betrouwbaarheid	The first thing users expect from your app is that whenever they open it, and it just works. When they try to perform key actions, there are no bugs preventing them from getting work done. The app doesn’t lose their data, or make it seem like it did due to poor UX. Users believe their data is safe and secure. Reliability is about building trust. Trust takes a long time to build, but can be destroyed very quickly — a single event of data loss or security breach can be a serious source of churn, let alone repeat incidents. Reliability is the base of the pyramid. Any issues here should be the priority — you must everything and focus on resolving them. Invest in the infrastructure that will let these urgent interruptions happen: incident management processes, system redundancy, technical debt reduction, and more.
Usability improvements	The longer you’ve worked on a product, the more features it likely has. Feature bloat is the silent killer of many apps. Typically, 20% of features account for 80% of the usage. Customers typically value apps that do one thing, but do it well, over Swiss-army knives that try to be all things to all people. A feature is rarely “done” forever — it’s part of a system and that system needs constant tuning. In your roadmap, it is important to allocate budget and resources to keep investing in your current feature set: - Improve the user experience of highly-used features - Make lesser-used features more discoverable - Remove the features that have no traction - Improve onboarding to improve utilization and conversions
New Features + Ideas	With a strong foundation in place, you can add new features. Everyone knows what we’re talking about here 😉

The 3 Bucket Planning Guide for prioritizing new ideas

Even when it comes to new product ideas, take a balanced approach to set your product up for success.

🛑 You can’t just build whatever features customers ask for, as you risk only helping your current user base.

🛑 You can’t only focus on improving key business metrics like revenue growth, as you might ignore important customer needs.

🛑 You can’t only ship new revolutionary ideas either, or you put reliability and usability at risk

Adam Nash, former VP product and growth at Dropbox, suggested looking at 3 buckets (source: “the 3 bucket planning guide”):

A view of 3 bucket feature planning in Jira Product Discovery

Metrics Movers are product initiatives that directly contribute to business goals by improving key metrics: sign-ups, conversion, retention, active users, referrals, revenue, etc. Growth initiatives typically fall in this category.
Customer Requests are what customers ask for, both net-new features and improvements to current experiences. Addressing these helps keep customers happy, reduce support load, and ensure that your product nails its key jobs.
Delighters are where your product innovates. These are the features your customers didn’t know they wanted, but can improve their lives by changing how they work. Delighters differentiate you from competition and build a moat around your product.

Allocating budget across investments

It’s important to be intentional in how you invest in each of these buckets. Otherwise, your velocity might drop because your team spends 80% of their time fixing bugs, or the growth of your product slows down, because you’re not thinking strategically. Shipping as many new features as possible is unlikely to fix that.

The right budget allocation for each bucket depends on many things, but in particular the stage of your product: pre-PMF (Product Market Fit), post-PMF, or mature product.

In practice, budget allocation could look like this:

	Pre-PMF	Post-PMF	Mature
Betrouwbaarheid	Pre-PMF 10%	Post-PMF 30%	Mature 50%
Usability improvements	Pre-PMF 20%	Post-PMF 20%	Mature 20%
Customer requests and delighters	Pre-PMF 70%	Post-PMF 30%	Mature 10%
Growth initiatives	Pre-PMF	Post-PMF 20%	Mature 20%

Remember, this should never be set in stone. For example, you might decide to invest more in new features for a few months, then go back and focus on UX improvements or addressing technical debt.

But as you allocate and re-allocate, it’s important to keep in mind the different aspects that are required to make your product successful, and to balance your investments over time.

There are different ways to manage these investments: you can have teams dedicated to one or the other bucket, you can make sure that each team has one initiative from each bucket at each time, or you can have each team pick work from each of the buckets in a round-robin fashion. There are pros and cons to each approach but it’s a lot more about delivery planning so we won’t cover them here.

Balancing investments at Jira Product Discovery

Here’s how we configured our investment allocation on the Jira Product Discovery team over a six-month period.

Investments across all squads

Hoe tactiek leidt tot strategieën in het Jira Product Discovery-team

We have 4 main themes: pricing and packaging, growth, jobs-to-be-done and engineering initiatives. In each of these themes, we have a number of bets.

These bets are distributed amongst the JPD teams: 5 product squads and 1 engineering squad (Sirius, Horizon, Aurora, Juno, Pulsar, X-flow).

Product squads

Roadmap for product team looking at core PM jobs to be done

Each product squad is required to allocate their time with the following split:

60% on product initiatives. For this they create a roadmap with two sections: one for new features, and one for improvements to the current product experience.
20% on RtB - Run the Business: on-call, bugs, etc.
20% on fixing tech debt

While we don’t strictly enforce this allocation, each team discusses keeping this balance during their sprint planning and monthly reviews. Typically, it does hold true over time.

For product initiatives, we keep a watch on feedback we receive from users and discuss every week with all product managers. We separate the feedback into “Boulders,” XL investments, and “Rocks,” large investments.

We have a separate list for “Pebbles,” small improvements fixing “paper cuts” in the UX. These are difficult to prioritize since you can’t compare their impact to L and XL investments. But, their impact compounds over time. The expectation is that each squad has one Pebble fix in progress at any point in time.

Engineering squads

How engineering invests across buckets in the JPD team

Each engineering squad has a similar split. But instead of product initiatives they focus on pure engineering projects to improve system resilience and scale.

Setting the stage for productive prioritization discussions

There are many people at your company who have insights into business and customer needs your product should help with.

If you can harness this collective knowledge, you can build more confidence in your product decisions and mitigate the risk of making the wrong bets.

But this is easier said than done. We’ve heard of product teams being swamped with asks from leadership and sales teams, then constantly interrupted with requests for updates: “when is my request going to ship?”

Done right, you can get a lot of value from turning prioritization into a team sport. A collaborative prioritization process creates clarity of mission, vision and purpose, getting teams across the business working towards shared goals.

Here are a few principles to follow for productive, collaborative prioritization.

Formuleer duidelijke verwachtingen

Setting expectations is crucial for everyone to collaborate effectively. People must understand what prioritization actually entails, and how they should contribute.

Here are a few key ingredients:

Everyone’s roles and responsibilities in the conversation
Shared goals and ways to measure success
Designated vocabulary and framework for prioritizing
Established communication channels and feedback loops

Rollen en verantwoordelijkheden toewijzen

For prioritization to be a positive experience for everyone, you want to make it clear how they should contribute.

To help with this, we designed Jira Product Discovery around 3 roles: creators, contributors and stakeholders.

Where creators, contributors, and stakeholders fit into the prioritization process.

Functie	Who they are	Verantwoordelijkheden
makers	Who they are The core product team across product, engineering, design, research.	Verantwoordelijkheden Drive the product, the prioritization process, and the ideas from beginning to end.
Bijdragers	Who they are Points of contact within the sales, support, customer success, marketing and other field teams.	Verantwoordelijkheden Participate in the prioritization process and provide key insights: customer requests, support problems, etc.
Belanghebbenden	Who they are The rest of the company, typically separated in 2 roles: leadership, and everyone else.	Verantwoordelijkheden Need visibility on priorities, progress and decisions and ways to provide feedback.

Review priorities continuously for incremental improvement

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:

Drie weergaves voor verschillende rollen in Jira Product Discovery.

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.De game 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 spelen aan het begin van een prioriteitscyclus, om een 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.

Impact/effort-matrix in Jira Product Discovery.

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.

Prioritering gebaseerd op klantgewichten

Gewichten gebruiken voor klantsegmenten op basis van bedrijfsdoelen.

Klantgewichten toewijzen voor prioritering

Wijs gewichten toe aan belangrijke klanten om te prioriteren.

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.

Waarschijnlijk overdreven: Weighted Shortest Job First (WSJF).

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:

Maak roadmaps 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.

Feedback en inzichten

Ontdek hoe het integreren van inzichten in je productontwikkelingsproces de besluitvorming kan verbeteren, kan worden afgestemd op de behoeften van de klant en tot succesvolle resultaten kan leiden.

Terug naar Feedback en inzichten

Roadmaps opstellen

Ontdek hoe je effectieve roadmaps voor producten kunt ontwikkelen die prioriteiten op elkaar afstemmen, de communicatie verbeteren en strategische doelen tussen teams ondersteunen.

Naar Roadmapping gaan