Van codekloppers naar klantdenkers: betrek developers in Product Discovery
De tijd waarin we dachten in een glazen bol te kunnen kijken om gebruikersbehoeften te voorspellen, te specificeren en over te dragen aan developers, ligt toch al ver achter ons? In productontwikkeling van deze tijd vertrouwen vertrouwen we niet langer op giswerk, maar op een gestructureerd proces om behoeften te ontdekken en te kapitaliseren. Dit vraagt niet alleen een denkomslag van de organisatie, maar in het bijzonder van software developers.
Productgoeroe Marty Cagan beschrijft in zijn boek Transformed waarom het voor organisaties die digitale producten ontwikkelen van vitaal belang is om het Product Operating Model te omarmen. Dit model richt zich op het continu leveren van waarde aan klanten via empowered product teams die verantwoordelijk zijn voor resultaten, niet slechts voor output.
Het model kent vier kerncomponenten:
1. Autonoom werkende productteams – Teams met de vrijheid om beslissingen te nemen binnen duidelijke kaders.
2. Product Discovery als kernproces – Het continu begrijpen, valideren en oplossen van klantproblemen.
3. Een heldere productstrategie – Richtinggevend en leidend bij het prioriteren van werk.
4. Een cultuur van continu leren – Feedback gebruiken om processen, producten en samenwerking voortdurend te verbeteren.
In plaats van functies als product, design en engineering gescheiden te houden, werkt dit model met multidisciplinaire teams die gezamenlijk eigenaarschap nemen over het productresultaat. Samen nemen ze verantwoordelijkheid voor het begrijpen van klantproblemen, het ontdekken van oplossingen en het leveren van waardevolle productresultaten, met ondersteuning van andere specialisten waar nodig. Deze teams delen de verantwoordelijkheid voor het leveren van waarde, bruikbaarheid en haalbaarheid van het product; kunnen we dit bouwen met de beschikbare technologie en middelen?
Een cruciaal inzicht hierbij is dat Product Discovery geen eenmalige fase is, maar een continu proces dat parallel loopt aan Product Delivery. In deze blog delen we 11 belangrijke redenen waarom developers hierin onmisbaar zijn.
Developers horen andere inzichten uit je klantinterviews.
Developers halen andere inzichten uit klantinterviews vanwege hun unieke perspectief en technische expertise. Waar een productmanager zich richt op inhoudelijke feedback over bijvoorbeeld content, en een designer zich focust op gebruikservaring, ziet een developer vaak technische verbeterpunten. Dit verschil in interpretatie is waardevol omdat het leidt tot een completer begrip van klantbehoeften. Developers selecteren en interpreteren data vanuit hun eigen kennis en ervaring, wat bijdraagt aan veelzijdige oplossingen. Product coach Teresa Torres benadrukt dat een product trio (productmanager, design lead en tech lead) samen het beste resultaat behaalt, omdat alle invalshoeken vertegenwoordigd zijn. Hierdoor kunnen developers unieke inzichten bieden die het productteam anders zou missen. Teresa benadrukt dat het belangrijk is dat er altijd een technische stem aanwezig is, maar dat hoeft niet altijd dezelfde persoon te zijn. Het hoeft niet altijd precies een trio te zijn. Het belangrijkste is dat de drie perspectieven – business, design en techniek – vertegenwoordigd zijn. Afhankelijk van de uitdaging kunnen er extra experts aansluiten om specifieke kennis in te brengen.
Developers bedenken vaak de beste oplossingen
Developers bedenken vaak innovatieve oplossingen dankzij hun diepgaande kennis van technologische mogelijkheden. Hun ervaring met technologie stelt hen in staat om te zien wat haalbaar is, zelfs als anderen dit niet direct voor zich zien. Deze oplossingen komen niet voort uit een grotere creativiteit, maar uit hun technische expertise en begrip van de grenzen en mogelijkheden van systemen. Echter, om optimaal bij te dragen, moeten ze ook de klantcontext begrijpen. Dit vereist deelname aan Product Discovery, omdat kennis over klantbehoeften cruciaal is om technologie effectief toe te passen. Developers die meedoen aan Product Discovery helpen dromen om te zetten in realistische oplossingen die vandaag gebouwd kunnen worden.
Product Discovery efficiënter maken met prototypes
Developers voorkomen dat het Product Discovery-proces vastloopt door hun technische vaardigheden in te zetten voor snelle prototypen. Wanneer ontwerpen afhankelijk zijn van echte data, kunnen ruwe mockups misleidend zijn of tot irrelevante feedback leiden. Developers kunnen kleine, tijdelijke oplossingen bouwen met echte data, waardoor de feedback nauwkeuriger en relevanter is. Dit voorkomt tijdverspilling aan complexe mockups die niet representatief zijn. Hun betrokkenheid maakt het mogelijk om snel en effectief te testen, zonder de volledige oplossing te hoeven bouwen. Dit bespaart tijd en middelen, terwijl het waardevolle inzichten oplevert.
De onmisbare analytische blik van developers in Product Discovery
Developers brengen analytische vaardigheden mee die essentieel zijn voor betrouwbare experimenten. Ze hebben vaak een sterke achtergrond in statistiek en wetenschappelijk denken, wat cruciaal is bij het ontwerpen en interpreteren van productexperimenten. Terwijl tools data leveren, helpen developers om deze data correct te interpreteren en valkuilen zoals valse positieven te vermijden. Hun expertise verhoogt de nauwkeurigheid van experimenten en voorkomt kostbare fouten. Zelfs als productmanagers en designers analytisch sterk zijn, biedt de input van developers een extra controlemechanisme dat fouten helpt voorkomen.
Waardelevering verloopt soepeler
Wanneer developers deelnemen aan Product Discovery, begrijpen ze de context van wat ze bouwen beter, waardoor minder vragen ontstaan tijdens de implementatie. Dit verlaagt de afhankelijkheid van de productmanager, die hierdoor meer tijd aan Product Discovery kan besteden. Developers kunnen sneller beslissingen nemen en zelfstandig handelen, wat de efficiëntie verhoogt. Teresa Torres benadrukt dat productmanagers vaak te veel tijd in delivery steken omdat developers afhankelijk zijn van hun kennis. Door developers te betrekken bij Product Discovery, worden zij zelfstandig genoeg om vragen te beantwoorden en problemen op te lossen zonder te veel te leunen op de productmanager.
Hoger leervermogen
Developers kunnen bijdragen aan het verhogen van de learning velocity door hun technische expertise in te zetten tijdens Product Discovery. Door hen actief te betrekken, kunnen teams sneller itereren, experimenteren en leren van gebruikersfeedback. Developers begrijpen bovendien de technologische mogelijkheden en beperkingen, waardoor ze sneller tot haalbare oplossingen kunnen komen. Dit voorkomt dat teams tijd verspillen aan ideeën die technisch niet haalbaar of kosteneffectief zijn.
Technische haalbaarheid direct inzichtelijk
Product Discovery gaat niet alleen over het begrijpen van klantbehoeften, maar ook over het inschatten van de technische haalbaarheid van oplossingen. Developers kunnen technische knelpunten al in een vroeg stadium opsporen en aangeven welke architecturale keuzes nodig zijn. Door developers vroeg te betrekken, kunnen ideeën sneller worden getoetst op technische haalbaarheid. Dit voorkomt verrassingen tijdens de ontwikkelfase en zorgt voor een realistischer verwachtingsmanagement. Ze kunnen direct inschattingen maken over de complexiteit en benodigde middelen voor verschillende oplossingen. Dit zorgt ervoor dat productteams zich kunnen focussen op ideeën die zowel waardevol voor de gebruiker als uitvoerbaar voor het team zijn. En daarmee een goede balans te vinden tussen haalbaarheid, het leveren van waarde aan gebruiker en organisatie die de waarde levert en het bewust omgaan met teamcapaciteit.
Van aannames naar inzichten: betere beslissingen met developers in discovery
Developers staan vaak bekend om het hebben van een mening. Ze hebben soms sterke meningen over wat er gebouwd moet worden, maar deze zijn vaak gebaseerd op aannames in plaats van op klantinzichten. Wanneer developers actief deelnemen aan Product Discovery, ontwikkelen ze beter onderbouwde meningen doordat ze rechtstreeks klantfeedback horen. Dit leidt tot kwalitatief betere discussies tijdens planningssessies en uiteindelijk tot betere productbeslissingen.
Developers stellen kritische vragen
Developers stellen kritische vragen die anderen misschien over het hoofd zien. Terwijl productteams soms verliefd worden op hun eigen ideeën, helpen developers om aannames te testen en valkuilen te identificeren. Hun focus op edge cases en foutscenario’s zorgt voor een realistische blik op nieuwe ideeën. Deze houding, vaak voortkomend uit hun dagelijkse werk met code, is onmisbaar om blinde vlekken te vermijden. Teresa Torres raadt aan om developers te betrekken bij pre-mortems om potentiële mislukkingen vooraf te analyseren. Hun kritische blik helpt productteams om aannames te valideren en betere beslissingen te nemen.
Diversiteit in probleemoplossing
Product Discovery uitgevoerd door alleen productmanagers en UX/UI designers, missen vaak een technisch perspectief. Developers brengen een andere manier van denken mee en kunnen innovatieve oplossingen bedenken die anderen niet zouden zien. Het is niet omdat developers de meest creatieve of slimste mensen in je team zijn (ook al denken sommigen dat misschien). Het is omdat ze een diepgaande kennis hebben van wat technisch mogelijk is, die vaak die van andere disciplines overtreft. Maar er is hier een belangrijke kanttekening. De beste oplossingen ontstaan door te begrijpen wat technologisch mogelijk is én door te begrijpen wat onze klanten nodig hebben. Dus als een developer die diepgaande kennis van technologie wil benutten, moet diegene ook een diepgaand begrip van de klantcontext opbouwen. De enige manier om dat te doen is door deel te nemen aan Product Discovery.
Verlagen van miscommunicatie
Ken je het spel nog toen je klein was? In een kringetje met andere kinderen een verhaal doorfluisteren in het oor. Dikke pret om steeds maar weer te zien hoe een verhaal zijn eigen leven gaat leiden. Als slechts een paar mensen in een organisatie direct contact hebben met klanten, ontstaat hetzelfde; misverstanden en vervormde informatie. Alleen heeft het dan vaak een minder prettige afdronk. Developers die direct deelnemen aan Product Discovery krijgen eerstehands klantinzichten, waardoor ze niet afhankelijk zijn van doorvertelde informatie. Dit leidt tot beter afgestemde productbeslissingen en voorkomt dat klantbehoeften verkeerd worden geïnterpreteerd. Bovendien maakt het teams minder afhankelijk van één bron. Een designer en een developer die vroeg betrokken zijn in een bepaald klantprobleem, kunnen dit prima vertalen en uitwerken naar een goede oplossing zonder te hoeven leunen op een product manager. En informatie uit eerste hand te delen met andere teamcollega’s in de product delivery fase.
Hoe je developers motiveert en selecteert voor Product Discovery
Het betrekken van developers bij Product Discovery lijkt misschien vanzelfsprekend, gezien de waarde die ze toevoegen aan het proces. Toch blijkt in de praktijk dat niet elke developer hier direct voor openstaat. Hoe zorg je ervoor dat ook zij enthousiast worden om deel te nemen aan deze ontdekkingsreis?
Herstel van vertrouwen en betrokkenheid
Historisch gezien zijn developers vaak behandeld als ‘uitvoerders’, wat hun motivatie om zich inhoudelijk te bemoeien met Product Discovery heeft ondermijnd. Door hen serieus te nemen, actief naar hun ideeën te vragen en successen te vieren, kan dit vertrouwen worden hersteld. Developers voelen zich dan gewaardeerd en worden meer betrokken bij het oplossen van klantproblemen.
Selecteer de juiste developers voor Product Discovery
Niet elke developer is geschikt of gemotiveerd om deel te nemen aan Product Discovery. Selecteer developers die intrinsiek geïnteresseerd zijn in klantproblemen, energie krijgen van meedenken over oplossingen én bijdragen aan oplossingen die het productteam helpen om de strategische doelen van het product te bereiken. Door developers te kiezen met een klantgerichte mindset, wordt de kwaliteit van de Product Discovery-sessies aanzienlijk verhoogd en ontstaat er meer betrokkenheid binnen het hele productteam.
Stel klantkennis als vereiste te stellen voor het geven van input over productbeslissingen
Teresa Torres adviseert om klantkennis als vereiste te stellen voor het geven van input over productbeslissingen. Wanneer een developer kritiek heeft op een productbeslissing, vraag dan naar de klantkennis die deze mening ondersteunt. Nodig hen uit om deel te nemen aan Product Discovery-activiteiten om deze kennis op te doen. Dit stimuleert hen om actief betrokken te zijn, zonder dat deelname wordt opgedrongen. Het zorgt ervoor dat alle productbeslissingen geworteld zijn in klantinzicht, wat de kwaliteit van beslissingen verhoogt.
Angst voor het onbekende wegnemen
Voor veel developers is Product Discovery onbekend terrein, wat weerstand kan oproepen. Door hen stapsgewijs kennis te laten maken met het proces, bijvoorbeeld door hen eerst interviews te laten observeren, wordt de drempel lager. Dit helpt hen vertrouwen te krijgen in de verschillende andere Product Discovery-activiteiten en stimuleert hun betrokkenheid bij het begrijpen van klantbehoeften.
Herziening van teamsamenstelling is soms onvermijdelijk
Technische hoogstandjes kunnen indrukwekkend zijn, maar zonder inzicht in wat klanten echt nodig hebben, blijven het lege hulzen. Developers die zich uitsluitend laten leiden door de technische uitdaging, missen de kans om daadwerkelijk impact te maken. Als je team voornamelijk bestaat uit developers die opgaan in complexe architecturen zonder zich te verdiepen in de waarde die het product levert, is het tijd om je teamsamenstelling te heroverwegen. Want échte waarde ontstaat wanneer technische vaardigheden worden ingezet om klantproblemen op te lossen.
Hoe zorg jij ervoor dat jouw developers niet alleen bouwen, maar ook actief bijdragen aan de toekomst van je product? Start vandaag nog met het betrekken van je developers en ontdek hoe je samen betere productbeslissingen neemt.
Bronvermelding
- Cagan, M. (2024). Transformed: Moving to the Product Operating Model. Wiley.
- Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value.
Product Talk LLC.
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!