Productresultaten realiseren met ideeën, van het begin tot de levering
In Jira Product Discovery is 'Ideeën' het belangrijkste object waarmee je werkt in je productbacklog. Om een proces van continue validatie en leren te ondersteunen, gebruiken we ideeën als objecten met een lange levensduur. Een idee laat wel een backlog achter wanneer de ontwikkeling begint, maar blijft bestaan tijdens iteraties van ontdekking en uitvoering, totdat het de vereiste impact heeft.
Succesvolle productteams hebben een experimentele mentaliteit: ze blijven het idee in de loop van de tijd herhalen door meer context, gebruikersfeedback, specificaties en ontwerp toe te voegen. In elke fase van de levenscyclus van een idee beoordelen ze wat wel of niet werkte, beantwoorden ze belangrijke vragen en valideren ze hun veronderstellingen om ervoor te zorgen dat hun investeringen overeenkomen met de feedback en validatie die ze krijgen.
Ideeën, van groot tot klein
Hoewel de naam van het object dat je in Jira Product Discovery gebruikt 'ideeën' is, kunnen ze staan voor productideeën, kansen, problemen, oplossingen en meer. Er kan een productbacklog worden ontworpen om ideeën van verschillende vormen en niveaus van granulariteit te bevatten.
Het is belangrijk om deze categorieën te definiëren en ervoor te zorgen dat iedereen die deelneemt aan het proces het erover eens is. Zo wordt voorkomen dat de productbacklog een allegaartje wordt van items, van supergroot tot superklein, zonder kader om ze te classificeren en te vergelijken.
Rotsblokken, keien en kiezelstenen: één manier om ideeën te classificeren
In het Jira Product Discovery-team delen we ideeën in drie niveaus in: rotsblokken, keien en kiezelstenen.
Rotsblokken, keien en kiezelstenen.
- Rotsblokken: een grote investering met potentieel grote opbrengsten, maar ook grote onzekerheid
- Voorbeeld: een grote nieuwe weddenschap, een nieuwe productpijler, een groot technisch project.
- Keien: middelgrote investeringen met minder risico's
- Voorbeeld: nieuwe functies, nieuwe onboarding-experimenten, herontwerpen op basis van feedback
- Kiezelstenen: kleine, doorgaans eenvoudige investering
- Voorbeeld: kleine verbeteringen in de gebruikerservaring, kleine oplossingen
- Voorbeeld: kleine verbeteringen in de gebruikerservaring, kleine oplossingen
Ons team maakt gebruik van verschillende visies om deze verschillende categorieën ideeën te bespreken:
Visie op rotsblokken in Jira Product Discovery.
Visie op keien in Jira Product Discovery.
Visie op kiezelstenen in Jira Product Discovery.
Attributen van een idee
In Jira Product Discovery is elk idee compleet met een samenvatting in één regel, een gedetailleerde beschrijving, inzichten zoals feedback van klanten en links naar Jira-tickets voor de levering van het idee.
Ideeën in Jira Product Discovery.
Leveringspanel over een idee in Jira Product Discovery.
Om zo nuttig en uitvoerbaar mogelijk te zijn, moet elk idee in de productbacklog compleet zijn met de volgende attributen:
Attribuut | Wat is het? |
|---|---|
| Samenvatting | Wat is het? Een oneliner over het idee. |
| Beschrijving | Wat is het? Een meer gedetailleerde beschrijving van de mogelijkheid, het probleem en de oplossing. |
| Velden | Wat is het? De verschillende facetten van het idee: aan welk doel het bijdraagt, het stadium, welk deel van het product het betreft, informatie om prioriteiten te stellen, zoals impact of inspanning, links naar specificaties of ontwerpen. |
| Inzichten | Wat is het? Inzichten die via alle kanalen zijn vastgelegd zodra ze binnenkomen: belangrijke lessen uit feedback van gebruikers, snippets uit gesprekken met klanten en onderzoeksrapporten, of productanalyses die duidelijk aangeven waarom dit idee belangrijk is. |
| Levering | Wat is het? Links naar leveringstickets in Jira (epics of initiatieven) voor het leveringswerk om het productidee daadwerkelijk te verzenden. |
Het kan even duren om al deze informatie te verzamelen voor elk idee. In eerste instantie kan het idee in je backlog terechtkomen met een samenvatting in één regel, zoals een inzicht dat is verkregen in een gesprek met een klant. Na verloop van tijd zul je er meer inzichten over verzamelen op basis van interviews met gebruikers, feedback van de verkoop of ondersteuning, of veranderingen in de bedrijfsstrategie.
Een oneliner met wat feedback van gebruikers.
Met feedback van gebruikers en analyse van mogelijke gevolgen.
Met een gevalideerde oplossing en levering die in volle gang is.
Er zijn twee manieren om ideeën te beschrijven: rechtstreeks in Jira Product Discovery, of door Confluence te koppelen aan het Jira Product Discovery-project van je team.
Schrijf in Jira Product Discovery een samenvatting of definitie in het beschrijvingsveld van het idee. Gebruik een van de bijgeleverde sjablonen, of maak je eigen sjabloon, om een consistente formule te geven voor het beschrijven van problemen, oplossingen, hypothesen en meer gerelateerd aan het idee.
Als je team ook Confluence gebruikt, kun je het idee koppelen aan Confluence-pagina's: in de beschrijving van het idee, of door aangepaste hyperlinkvelden te gebruiken. Het voordeel van deze aanpak is dat je alle samenwerkingsfuncties van Confluence kunt gebruiken, zoals inline-opmerkingen.
De inhoud van de beschrijving zelf hangt af van het soort idee en de fase waarin het zich bevindt.
De levenscyclus van het idee
Even belangrijk voor de inhoud van een idee is hoe het zich in de loop van de tijd ontwikkelt. Daarom is het belangrijk om duidelijke fases vast te stellen voor elk idee die tijdens de levenscyclus moeten worden doorlopen. Als je een gemeenschappelijke vocabulaire hebt om de fasen van de levenscyclus van een idee te beschrijven, wordt elk gesprek productiever, zowel binnen het team als met belanghebbenden.
Bij Atlassian gebruiken we vier fasen: afvragen, ontdekken, maken en impact maken. Bij Atlassian weet iedereen wat elk van deze fasen betekent. Voor elke fase weten we met wat voor soort werk het team bezig is, welke vragen we moeten stellen en wat voor soort hulp het team nodig heeft. Deze consistentie geldt voor discussies binnen het team, met andere teams of met senior managers.
Bij de ontwikkeling van Jira Product Discovery heeft ons team deze aanpak gebruikt om onze ideeën te ontwikkelen, te valideren en uit te voeren. Voor elke fase van de levenscyclus leggen we uit hoe ons team dit in de praktijk heeft gebracht.
Afvragen, ontdekken, maken, impact maken
Voordat we aan deze levenscyclus beginnen, begint elk idee op de parkeerplaats. In dit stadium zijn het meestal gewoon samenvattingen in één regel, met de inzichten die tot hun ontstaan hebben geleid. Die inzichten kunnen afkomstig zijn van een workshop, een onderzoeksrapport, een gesprek met een klant, of gedeeld zijn door een verkoop- of ondersteuningsmedewerker.
Zodra actief aan het idee is begonnen, worden de vier stadiums doorlopen:
- Afvragen: bespreek de problemen of kansen die met het idee kunnen worden aangepakt, op wie ze invloed kunnen hebben en hoe belangrijk ze zijn.
- Ontdekken: bedenk mogelijke oplossingen tot je er een vindt die gevalideerd wordt op basis van feedback van klanten.
- Maken: ontwikkel de oplossing en blijf deze uitproberen totdat de oplossing voldoet aan de behoeften van voldoende klanten.
- Impact maken: lanceer de oplossing, meet de resultaten en blijf verbeteren tot deze het gewenste resultaat oplevert.
Ideeënfasen voor het Sirius-team in Jira Product Discovery.
Een bordweergave van de ideeën in het Jira Product Discovery-team per ideeënfase.
Dit is geen watervalmodel — deze fasen zijn niet noodzakelijk lineair. Het komt bijvoorbeeld heel vaak voor dat een idee in Verkennen teruggaat naar Afvragen, omdat het testen van oplossingen ons meer over het probleem vertelt. Er wordt ook verwacht dat je van sommige ideeën afziet als je na een paar pogingen geen passende oplossing vindt.
In de volgende secties illustreren we elke fase door te laten zien hoe ons team ze heeft gevolgd toen we bezig waren met de ontwikkeling van Jira Product Discovery.
Als je benieuwd bent naar dat proces, bekijk dan deze lezing voor nog meer informatie:
Afvragen
De fase Afvragen gaat over het valideren van een probleem of kans.
In deze fase hang je meestal af van kwalitatieve gesprekken met klanten. Met dit onderzoek wordt het voor je team duidelijk welke voordelen en resultaten het idee beoogt te behalen, gemeten in waarde voor klanten en het bedrijf. Ze stellen ook een hypothese op om succes te meten.
Voor ideeën in deze fase kun je de sjabloon 'Probleemdefinitie' van Jira Product Discovery gebruiken, of je eigen sjabloon maken.
Sjabloon 'Probleemdefinitie' in Jira Product Discovery.
Leg tijdens de fasen Afvragen, Ontdekken, Maken en Impact maken de leerervaringen uit onderzoek en gesprekken met klanten vast in de sectie Inzichten van het idee:
Het veld Inzichten voor een idee in Jira Product Discovery.
'Afvragen' in actie
Zo zag de fase Afvragen eruit toen we Jira Product Discovery aan het ontwikkelen waren. Het oorspronkelijke idee voor dit product kwam van:
Interviews met productmanagers die Jira gebruiken voor de levering van software
Analyse van onderzoek van het eigen onderzoeks- en inzichtenteam van Atlassian en analistenbureaus zoals Gartner en Forrester
Voorbeelden van best practices op het gebied van productontwikkeling, zoals de blogs van Marty Cagan en het boek van Teresa Torres.
Met deze inzichten kregen we het gevoel dat:
- Projectmanagers met veel dingen moeite hadden, van effectief prioriteren tot iedereen overtuigen van hun roadmaps
- Projectmanagers op zoek waren naar Jira om deze pijnpunten op te lossen, maar weinig succes hadden omdat Jira niet voor dat doeleinde was ontworpen
- Projectmanagers vastzaten bij de levering, gefocust op resultaten, zoals verzendfuncties, terwijl ze ook eerst konden ontdekken en vervolgens resultaten boeken
- Productbeheer werd een sleutelfunctie, zelfs buiten de technologiebedrijven. We waren dus van mening dat dit een grote kans was en dat er een grote vraag zou zijn naar een oplossing.
Onze landingspagina voor Jira Product Discovery.
We waren vooral gefocust op het valideren van onze hypothese over de vraag, omdat dit onze meest riskante veronderstelling was. Als we het mis hadden, zouden we een product maken dat maar een paar bedrijven zouden kopen.
Dus voordat we een enkele regel code schreven, hebben we een webpagina gemaakt waarop reclame werd gemaakt voor het product.
De resultaten bevestigden onze hypothese: in twee weken tijd kwamen er 3000 mensen op de wachtlijst.
Ontdekken
In de fase Ontdekken bedenken, testen en valideren we oplossingen voor de problemen of kansen die in de fase Afvragen zijn geïdentificeerd.
We weten dat veel productideeën mislukken, maar dit hoort bij het proces! Om deze minder veelbelovende ideeën sneller te identificeren en plaats te maken voor de goede, stelt Marty Cagan voor dat productmanagers vier belangrijke risico's aanpakken. Gebruik deze bij het evalueren van mogelijke oplossingen voor de problemen en kansen die je hebt geïdentificeerd.
- Is de oplossing waardevol voor klanten? Als dat niet zo, doordat ze bijvoorbeeld toegang hebben tot betere alternatieven, loop je het risico dat mensen de oplossing die je hebt ontwikkeld niet gebruiken.
- Is de oplossing bruikbaar en intuïtief? Voor gebruikers om waarde te halen uit de oplossen, moet deze eenvoudig om te openen en te gebruiken zijn. Als er een hoge drempel is om waarde eruit te halen, loop je het risico een functie te lanceren die weinig wordt gebruikt.
- Is deze oplossing technisch haalbaar? Hoe veelbelovend een idee ook is, je engineers moeten over de vaardigheden en technologie beschikken die nodig zijn om het te laten werken — anders loop je het risico onnodig middelen uit te putten.
- Is de oplossing haalbaar met de middelen en beperkingen van het bedrijf? Het zal waarschijnlijk een paar verschillende iteraties vergen om de juiste oplossing te vinden. Je wilt er zeker van zijn dat het bedrijf bereid is om te investeren, anders loop je het risico tijd te besteden aan een idee dat wordt opgegeven.
Het doel van je team is om de risico's zo efficiënt mogelijk te beperken en te voorkomen dat je te veel investeert op basis van onderbuikgevoel of verliefd worden op een oplossing. Dit gebeurt meestal door een functie te leveren en deze vervolgens te itereren of te bestuderen hoe deze werkt. Gebruik in plaats daarvan technieken met minder risico, zoals prototypes maken in Figma en ze aan klanten laten zien, zodat je in een vroeg stadium feedback krijgt voordat je begint met het schrijven van code.
Als je besluit om een functie te leveren, probeer dan een live prototype te bouwen met veel beperkingen, het te testen met een kleine groep 'early adopters' en snel te itereren. Op deze manier hoef je niet over alle randgevallen na te denken. Als het idee voor hen niet werkt, zul je veel sneller leren waarom, en blijf je itereren tot het zover is — of gooi je het idee weg als het niet goed wordt ontvangen.
Als je grote onzekerheden hebt, voer dan een technische piek uit als onderdeel van de fase Verkennen. Dit type implementatie is bedoeld om je te helpen begrijpen wat de eigen beperkingen van je team zijn; wat technisch haalbaar is en waar de technische complexiteitsgebieden liggen.
Voor ideeën in deze fase kun je de sjabloon 'Definitie van de oplossing' van Jira Product Discovery gebruiken, of je eigen sjabloon aanmaken.
Sjabloon 'Definitie van de oplossing' in Jira Product Discovery.
Koppel in je productbacklog alle documenten, specificaties en ontwerpen met betrekking tot elk idee, zodat je ze binnen handbereik hebt om het idee met je team en belanghebbenden te bespreken. We raden aan om op elk idee 'hyperlink'-velden aan te maken om elk item bij te houden (one-pager, ontwerp).
Hier is een demo over hoe je dat moet doen:
Verkennen in actie
Toen we Jira Product Discovery oprichtten, gebruikten we de volgende technieken om onze oplossingen bij klanten te valideren:
Eerst lieten we dia's van de PM's zien met verschillende mogelijke oplossingen, om te begrijpen welke oplossing het beste aansloeg. Door deze gesprekken hebben we veel geleerd over de problemen van onze klanten en wat ze waardeerden. Zo werd 'prioritering' de eerste pijler van Jira Product Discovery.
💡 Dia's zijn geweldig voor deze fase van validatie: ze zijn eenvoudig aan te maken, te testen en te wijzigen.
Vervolgens hebben we prototypes gemaakt in Figma, die aan gebruikers getoond en gevraagd hoe de oplossingen hen zouden helpen. Het eerste prototype waarmee we dit hebben geprobeerd, was een oplossing die bedoeld was om PM's te helpen de feedback van belanghebbenden te gebruiken om prioriteiten te stellen.
Hoewel er zeker interesse was, vonden de PM's dat er te veel moeite was gedaan om het op te zetten voordat ze er waarde uit konden halen. Dus hebben we het idee opzijgelegd.
Na meerdere rondes van dergelijke feedback te hebben verzameld, hebben we de oplossing onderzocht die zou worden wat Jira Product Discovery vandaag is: een samenwerkingsspace om productideeën te bespreken.
In deze fase zijn de gesprekken met gebruikers drastisch veranderd. Velen vroegen wanneer ze toegang konden krijgen, omdat de tool hen enorm zou helpen. Toen wisten we dat we op de goede weg waren.
Na meerdere rondes van dergelijke feedback te hebben verzameld, hebben we de oplossing onderzocht die zou worden wat Jira Product Discovery vandaag is: een samenwerkingsspace om productideeën te bespreken.
In deze fase zijn de gesprekken met gebruikers drastisch veranderd. Velen vroegen wanneer ze toegang konden krijgen, omdat de tool hen enorm zou helpen. Toen wisten we dat we op de goede weg waren.
Maken
In de fase Aanmaken bouwen en valideren teams de oplossingen die ze in Verkennen hebben gekozen. Dit is het moment waarop het grootste deel van het ontwikkelingswerk plaatsvindt.
Het resultaat van deze fase is werkende software — ofwel een nieuw product of een nieuwe functie, of verbeteringen in een bestaande ervaring — die heeft bewezen dat het de verwachte resultaten kan waarmaken, die door voldoende klanten is gebruikt om de waarde ervan te bewijzen en die klaar is voor gebruik door alle klanten.
Wanneer de levering begint, in deze fase of tijdens Verkennen, koppel je het idee aan leveringstickets in Jira (we raden het niveau Epic of hoger aan). Volg de voortgang van de levering vanuit Jira Product Discovery en krijg een overzicht van de voortgang van alle productinitiatieven en teams.
De relatie tussen een idee en een leveringsopdracht in Jira.
Als meerdere teams betrokken zijn bij de uitvoering van een idee, en ze werken in verschillende Jira-projecten, kun je al hun leveringstickets koppelen aan het idee in je productbacklog.
Een idee, geleverd door drie verschillende teams van Jira.
Vervolgens kun je vanuit JPD de voortgang van de levering volgen en een overzicht krijgen van de voortgang van alle productinitiatieven en teams.
Dashboard met productwerk in uitvoering.
Voor meer informatie kun je ons webinar bekijken over 'Ontdekking en levering koppelen in Jira in de sectie Middelen.
Onthoud dat het zeer onwaarschijnlijk is dat de oplossing onmiddellijk de verwachte resultaten zal opleveren. Lever de oplossing in plaats daarvan vroeg en vaak aan klanten en blijf itereren tot het goed genoeg is. Blijf inzichten uit klantgesprekken aan het idee toevoegen op basis van wat je leert. De manier waarop je succes meet, hangt af van het soort idee: nieuwe functie, groei-initiatief, enz. Zorg ervoor dat iedereen dit weet en dat je plannen iteraties mogelijk maken.
Aanmaken in actie
Bij het aanmaken van Jira Product Discovery en bij het toevoegen van belangrijke nieuwe functies aan het product, hebben we deze getest en gevalideerd bij steeds grotere groepen klanten. In sommige gevallen duurde dit proces enkele weken, in andere gevallen enkele maanden.
| 0 → 10 klanten | Tijdens de fase Ontdekken hebben we dit herhaald met een klein aantal vooraf geselecteerde klanten. We hebben heel nauw met deze klanten samengewerkt om samen de oplossing vorm te geven. We bleven dit itereren tot we van hen de bevestiging kregen dat de oplossing het probleem waarmee ze werden geconfronteerd, had opgelost. |
| 10 → 100 klanten | Vervolgens hebben we geleidelijk toegang gegeven aan meer klanten. Dit hielp ons verschillende scenario's te identificeren die we in eerste instantie misschien niet hadden overwogen. We bleven dit itereren tot er 100 actieve klanten waren die de oplossing gebruikten. |
| 100 → 1.000 klanten | Vervolgens hebben we toegang gegeven aan meer klanten, tot we er 1.000 bereikten. Daarna keken we naar de gebruikscijfers op basis van productanalyses, supporttickets en binnenkomende feedback. Op basis van onze bevindingen hebben we de UX verbeterd of bugs opgelost. Als de gebruikscijfers te laag waren om bruikbaar te zijn, zouden we kijken naar de vindbaarheid van de functie. |
| Algemene beschikbaarheid | Tot slot hebben we support, verkoopondersteuning, operationele dashboards en verbeteringen op het gebied van prestaties en schaalbaarheid klaar gemaakt voor gebruik. |
Als we aan dit soort oplossingen werken, geven we die meestal vorm op een aparte Confluence-pagina die we een 'Flexibel functiedocument' noemen. Dit is een zeer lichte pagina die we elke keer openen als we elkaar als team ontmoeten, om de scope van de huidige versie te bespreken. We werken dit document regelmatig bij, naarmate we meer te weten komen over wat gemakkelijk of moeilijk te leveren is. Het is niet gericht op individuele taken, maar op de productervaring — en dat is de informatie waarvan we willen dat iedereen, van product tot ontwerp tot engineering, op één lijn zit.
Flexibel functiedocument in Jira Product Discovery.
Impact
In het productmodel begint en eindigt alles met de resultaten. Teams geven prioriteit aan ideeën zodat ze tot een resultaat kunnen komen, en nadat ze zijn opgeleverd, blijven ze de voortgang in de richting van deze resultaten volgen. Dit geeft informatie over updates over je doelen en strategieën, en hoe je prioriteiten stelt voor je volgende stappen.
Zelfs nadat een oplossing is geleverd, is die nooit echt 'klaar': zodra je een functie introduceert, maakt die nu deel uit van je product. Je moet het blijven verbeteren om ervoor te zorgen dat het waardevol is voor gebruikers en dat mensen het niet verwarrend of moeilijk te gebruiken vinden. Zorg ervoor dat je bijhoudt waar klanten om vragen, wat ze zeggen over nieuwe functies en hoe vaak ze in supporttickets worden genoemd.
Impact in de praktijk
In het Jira Product Discovery-team doen we dit met maandelijkse en driemaandelijkse beoordelingen, waarin we de impact die we hebben bereikt vergelijken met wat we van plan waren te doen. Soms zijn we tevreden met de resultaten en veranderen we heel weinig, soms stellen we de roadmap opnieuw in om iets anders te proberen.
Een van de technieken die we gebruiken: nadat we een oplossing hebben geleverd, maken we een bijbehorend idee voor verbetering waarbij we inzichten verzamelen, waaronder:
- Binnenkomende feedback van gebruikers
- Signalen uit feedback, enquêtes en interviews dat de functie wel of niet de problemen oplost waarvoor deze is ontwikkeld
- Gebruiksgegevens uit productanalyses om te zien of de oplossing daadwerkelijk wordt gebruikt. Als dat niet het geval is, is de oplossing misschien moeilijk te vinden of is er gewoon minder interesse in de functie dan we hadden verwacht.
Weergave voor het bijhouden van feedback van klanten over eerder geleverde ideeën in Jira Product Discovery.
We bekijken deze gegevens regelmatig en elk team wijst een budget toe voor functieverbeteringen. Zowel nieuwe ideeën als verbeteringen van bestaande ideeën staan op de roadmap van elk team:
De voortgang van een idee
Jira Product Discovery biedt wel een aantal velden om de voortgang van de leveringstickets van een idee weer te geven. Maar we geloven niet dat dit automatisch de beste manier is om belanghebbenden op de hoogte te brengen van de voortgang. Of de taken van een epic nu voor 60% of 80% zijn voltooid, je kunt hier niet uit opmaken hoeveel vooruitgang het team echt boekt.
Een effectievere manier om belanghebbenden op de hoogte te brengen van de voortgang: markeer elk idee als 'op schema', 'in gevaar' of 'niet op schema' (via een veld) en geef commentaar (in de omschrijving van het idee). Dit is een heel eenvoudige vorm van samenwerking, maar het is zeer effectief om met belanghebbenden te bespreken waar je hulp bij nodig hebt.
Bekijk de voortgang van de communicatie met belanghebbenden in Jira Product Discovery.
Meer informatie over één idee in de weergave voor het delen van de voortgang.
Als je Atlas gebruikt, ben je al bekend met deze aanpak. Bekijk de video over hoe je ideeën uit Jira Product Discovery kunt koppelen aan Atlas-projecten in de sectie Resources. Met deze video wordt het verhaal duidelijker en preciezer verteld dan met onderstaande weergaven, waarin de voortgang wordt gemeten in de vorm van het percentage geleverde Jira-tickets:
Een weergave van Jira Product Discovery met de voortgang van tickets die in Jira zijn geleverd.
Meer informatie over één idee in de voortgangsweergave gericht op tickets.
Wat is er nog meer?
Door Ideeën te gebruiken als middel om oplossingen over te dragen via ideevorming, validatie en in de levering, kunnen productteams mensen georganiseerd en gefocust houden op resultaten.
In de rest van dit handboek leggen we in detail uit hoe je een productbacklog kunt gebruiken om:
- feedbackkanalen op te zetten en inzichten te verzamelen om ideeën te valideren
- de ideeën die impact hebben te prioriteren
- 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.
Productbacklog
Beheer productbacklogs effectief om ideeën te prioriteren, samenwerking te verbeteren en de productontwikkeling te stimuleren.
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.
