Productontdekking

Herken je deze situatie? In je bedrijf is iedereen enthousiast over een bepaald productidee en jij als productmanager moet dit product definiëren. Je krijgt te horen dat de ontwikkelaars over vier weken klaar zijn met hun huidige project. Dat betekent dat je zoveel tijd kunt nemen als je wilt, zolang je maar over vier weken klaar bent…

Je zegt dat het geen probleem is (je hebt tenslotte soms maar een paar dagen, dus vier weken klinkt als een droom). Je gaat zelfs al die geweldige methoden gebruiken waar ik het altijd over heb. Je begint met een opportunity assessment om het probleem te begrijpen dat opgelost moet worden. Vervolgens voer je interviews met echte gebruikers en stel je een voorlopige lijst met vereisten op. Aan het begin van de tweede week zou je dus al met een interaction designer aan een prototype moeten kunnen werken. In de derde week kun je tests uitvoeren met dit prototype en in de vierde week werk je de details van de use cases uit en bespreek je het prototype en de specificaties met de ontwikkelaars.

De realiteit bij Product Discovery

Dat klinkt echt geweldig – maar wat er in werkelijkheid gebeurt, is meestal niet zo geweldig: Tijdens de eerste klantgesprekken blijkt dat de klanten lang niet zo enthousiast zijn over het product als het management was, en/of je hebt moeite om een prototype te ontwerpen waar de klanten mee uit de voeten kunnen, en/of de klanten vinden de ideeën die in het prototype zijn verwerkt niet echt geweldig. Maar nu is de tijd om en de ontwikkelaars staan klaar. In de volgende drie tot zes maanden wordt dus hetzelfde nutteloze en saaie product ontwikkeld dat je al als prototype hebt gezien. Wanneer het product dan wordt opgeleverd, is het management terecht teleurgesteld over het resultaat.

Wat is het probleem?

Het probleem ligt niet bij de betrouwbaarheid van de software. De ontwikkelaars kunnen er dus niets aan doen – ze hebben immers alleen gebouwd wat je van hen gevraagd hebt. Iedereen weet dus dat het jouw fout als productmanager is.

Het heeft namelijk geen zin om met gebruikers te praten, prototypes te ontwikkelen en die samen met de gebruikers te testen, als je vervolgens niets doet met wat je daarvan leert.

Het idee om requirements en design te zien als een sequentiële, voorspelbare en geplande fase in het productontwikkelingsproces, is zo diep geworteld in onze branche dat het voor productorganisaties vaak heel moeilijk is om deze gewoonte los te laten.

Maar dat moet je wel doen. In productorganisaties moet je begrijpen dat het bedenken van nieuwe producten in essentie een creatief proces is. Het is eerder een kunst dan een wetenschap. Ik noem deze fase daarom liever "Product Discovery" dan "requirements en design".

De term "Product Discovery" benadrukt twee bijzonder belangrijke punten:

• Ten eerste moet je uitzoeken of er echt klanten zijn die dit product willen hebben. Dat betekent dat je de markt moet definiëren en de productkans door je klanten moet laten bevestigen.

• Ten tweede moet je een oplossing voor dit probleem vinden die bruikbaar, nuttig en haalbaar is. Dat betekent dat je het product moet ontwerpen en het vervolgens samen met de klanten en het ontwikkelteam moet valideren.

Product Discovery in de farmaceutische industrie

De farmaceutische industrie is een extreem voorbeeld. Een markt vinden is niet zo moeilijk – er zijn altijd genoeg problemen die het waard zijn om op te lossen (bijvoorbeeld levens redden, levens verlengen of de levenskwaliteit verbeteren). De oplossing daarvoor vinden, dát is het moeilijke deel. Wanneer farmaceutische bedrijven met de "Discovery Phase" beginnen, zijn ze zich er volledig van bewust dat er geen garantie is dat ze een oplossing zullen vinden, of hoe lang het proces zal duren. In deze branche moet je dus met die onzekerheid om kunnen gaan (en het risico wordt weerspiegeld in de prijzen van de producten).

Redenen waarom Product Discovery moeilijk kan zijn

En hoewel we allemaal weten dat het moeilijk is en dat de meerderheid van alle software releases mislukkingen zijn omdat ze niet de gewenste doelen bereiken, staan we bij softwareontwikkeling nog steeds erop om de Discovery-fase te plannen alsof we een gebouw bouwen.

Vooral het management heeft moeite met het concept van Product Discovery. En ik denk dat daar twee redenen voor zijn:

• Ten eerste is het Discovery-proces niet voorspelbaar. Het management is bang dat je maandenlang aan iets werkt en er niets uit komt. Als je gewoon begint en iets ontwikkelt, kun je tenminste beweren dat je iets hebt opgeleverd. Dat is waarschijnlijk dezelfde reden waarom zoveel managers niet goed overweg kunnen met Scrum, want ze willen precies weten hoeveel Sprints van 30 dagen je nodig hebt voordat je klaar bent.

• Ten tweede worden de ontwikkelaars in een productorganisatie voor software altijd als schaarse resource gezien. Het idee dat een team van ontwikkelaars rondhangt en niets doet, behalve tafelvoetballen, drijft het management tot waanzin.

Ironisch genoeg is het juist deze redenering die ertoe leidt dat ontwikkelaars als resource worden verspild.

Bijna elk bedrijf gebruikt het zojuist beschreven Discovery-proces. In plaats van zich een paar weken bezig te houden met een prototype, laten ze het hele ontwikkelteam complete release-cycli doorlopen om de software te bouwen, die vervolgens door kwaliteitscontrole gaat en in productiesystemen wordt uitgerold. Dat is de reden waarom zoveel bedrijven drie of zelfs meer releases en één tot twee jaar nodig hebben voordat ze iets bruikbaars en waardevols opleveren. Ze gebruiken de ontwikkelorganisatie om een heel, heel duur prototype te bouwen en maken van hun klanten onvrijwillige testpersonen.

Dat is ook de reden waarom zoveel start-ups geen succes hebben. Ze hebben simpelweg niet het kapitaal om twee jaar te wachten voordat ze kunnen doorbreken. Dus pakken ze hun ontwikkelaars, laten ze hun best doen en kijken af wat er gebeurt.

Conclusie

Ik raad start-ups en grote bedrijven daarom aan om hun krachten te concentreren op dit veel snellere Discovery-proces. Zodra ze een oplossing hebben gevonden die werkt (die bruikbaar, nuttig en uitvoerbaar is), draait alles om het ontwikkelwerk. Tot dat punt hoeven ze nog niet zoveel ontwikkelaars te hebben. De ontwikkelaars die ze hebben, kunnen en zouden actief aan het Discovery-proces moeten deelnemen. Tot op zekere hoogte kunnen de ontwikkelaars tijdens het Discovery-proces ook alvast de infrastructuur voorbereiden.

Je kunt je management helpen om het Product Discovery-proces te begrijpen. Als je er consequent op wijst dat het je plicht is om ervoor te zorgen dat de ontwikkelaars ook iets nuttigs en bruikbaars creëren, en je actief bijdraagt aan de inspanningen voor een veelbelovende oplossing, dan kun je de aandacht van het management richten op deze uiterst belangrijke fase in het productontwikkelingsproces.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons in het Nederlands vertaald. 

Geweldige producten creëren

=> Discovery vs Delivery bij producten.

Een productstrategie ontwerpen

Ontdek hoe je bedrijfsstrategie vs. productstrategie van elkaar verschillen.