4 Grootste mythes over productontwikkeling & hoe je ze voorkomt
Waarom lopen we achter op schema? Wanneer maak je het productontwerp af? Als je die woorden eerder hebt gehoord, ben je niet de enige.
Veel bedrijven begrijpen niet hoe productontwikkeling werkt. Ze zien het als een lineair proces, alsof het toevoegen van extra middelen alles op magische wijze zal oplossen. In werkelijkheid is het veel contra-intuïtiever en complexer dan dat.
In de loop van mijn carrière heb ik mijn deel gehad aan het ontkrachten van enkele veelvoorkomende mythes over productontwikkeling. In een start-upomgeving kan dat erg chaotisch zijn, maar tegelijkertijd ook lonend. Zie het zo: het is gemakkelijker om iets te repareren voordat het vaart krijgt.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Maar de uitdaging is om iedereen op één lijn te krijgen voordat de schade is aangericht. Het laatste wat je wilt, is een touwtrekkerij op je werkplek. Als je dit niet onder controle houdt, wordt het een nieuwe brand die niet zo snel zal doven.
Als je je bezighoudt met productontwikkeling en je afvraagt waar het misgaat, bekijk dan deze veelvoorkomende mythes over productontwikkeling. Ze helpen je om goed te blijven presteren.
- Meer middelen betekenen betere prestaties
- Werken in grote batches verbetert het ontwikkelingsproces
- Vul het product met functies en klanten zullen er dol op zijn.
- Houd je aan het plan, koste wat het kost
Enkele professionele mythes ontkracht
Laten we één ding duidelijk stellen: productontwikkeling is een heel ander speelveld dan productie. In de productie kun je kosten beheersen en efficiëntie op de conventionele manier verhogen. Maar als je dat bij productontwikkeling doet, richt je uiteindelijk meer schade aan dan dat je goed doet.
Waarom? Omdat productie voorspelbaar is. Taken zijn repetitief, als tandwielen in een machine. Productontwikkeling daarentegen is dynamisch en voortdurend aan verandering onderhevig. Er is niet één juiste manier om het te doen: je leert gaandeweg. Dat brengt ons bij onze eerste mythe over productontwikkeling.
Mythe 1: Meer middelen betekenen betere prestaties
Meer input betekent meer output klinkt volkomen logisch, maar die redenering is gevaarlijk en misleidend bij productontwikkeling.
Volgens onderzoeken houden de meeste managers van productontwikkeling de benuttingsgraad boven de 98 procent. Het is logisch dat hoe meer een team werkt, hoe groter de output zal zijn die het oplevert.
In de praktijk werkt het niet zo. Een hoge benuttingsgraad leidt tot slechtere teamprestaties en een lagere output. Hoe goed je ook bent als manager, je kunt hier simpelweg niet omheen werken. Toch negeren veel managers dit om twee belangrijke redenen:
1. Ze onderschatten hoe onvoorspelbaar productontwikkeling is. Er kan op elk moment een project op je bureau belanden. Je kunt niet voorspellen om wat voor project het zal gaan, welke expertise je nodig zult hebben en hoe lang het zal duren.
Productontwikkeling is allesbehalve lineair. Het toevoegen van een hoge benutting van middelen aan de mix leidt tot meer vertragingen, problemen en wachtrijen. Dat komt doordat nieuwe projecten in de wachtrij moeten worden geplaatst als een team altijd op 100% werkt, omdat er geen capaciteitsbuffer is.
2. Eén ding dat productmanagers doen, is routinematig onderschatten hoe slecht wachtrijen kunnen zijn voor de prestaties. Wanneer een productontwikkelingsteam op maximale capaciteit werkt en meerdere projecten tegelijk beheert, zullen projecten onvermijdelijk op de plank blijven liggen omdat ze vastlopen in goedkeuringen en controles.
Stel dat je een product ontwerpt en halverwege niet verder kunt omdat je groen licht van de technische afdeling nodig hebt. Stel dat deze goedkeuring drie weken duurt. Wat doe je dan? Drie weken rondhangen of voorlopig een nieuw project oppakken? De meeste productontwikkelaars kiezen voor het laatste zonder te beseffen dat ze zichzelf daarmee alleen maar op een ramp voorbereiden.
Tegen de tijd dat je de goedkeuring krijgt, werk je aan een ander project en heb je niet de capaciteit om het oorspronkelijke project weer op te pakken. Daardoor blijft het oorspronkelijke project in de wachtrij staan, tenzij je capaciteit vrijmaakt om verder te gaan waar je was gebleven. Daarmee loopt het stilgelegde project het risico verouderd te raken als markttrends veranderen.
Ook dat is een gevolg van een hoge benuttingsgraad van middelen. Werken op maximale capaciteit leidt tot langere wachtrijen. Deze vicieuze cirkel blijft bestaan totdat je de achterstand wegwerkt of je werkcapaciteit vergroot door een nieuw team op te zetten. Met andere woorden, wachtrijen:
- Verhogen vertragingskosten, proceskosten en doorlooptijden.
- Zetten projecten op de plank. Hoe langer je projecten op de plank laat liggen, hoe kwetsbaarder ze worden voor marktveranderingen.
- Maken productontwikkeling nog variabeler.
Zo los je dit dilemma rond de toewijzing van middelen op:
- Beperk het aantal actieve projecten. Daardoor daalt je benuttingsgraad, komt er capaciteit vrij en ontstaan er minder wachtrijen. Bovendien zal het team zich meer richten op de taken die voorhanden zijn.
- Maak onderhanden werk (WIP) beter zichtbaar. Bij productontwikkeling is WIP onzichtbaar, en daarom is het zo moeilijk om middelen effectief toe te wijzen. Ik heb visuele controleborden in software voor productontwikkeling altijd erg nuttig gevonden om goed op de hoogte te blijven. Je kunt dagelijks vergaderingen van 10 minuten houden of veel post-itbriefjes gebruiken. Het doel is dat iedereen zo open mogelijk over zijn mijlpalen communiceert.
- Stem de doelstellingen van afdelingen op elkaar af. Denk nog eens aan dat voorbeeld waarin je drie weken moet wachten op goedkeuring. Wat als dat slechts een paar uur zou duren? Daarvoor moet je de doelstellingen van afdelingen op elkaar afstemmen door managementcontrolesystemen te wijzigen. De meeste managers willen de capaciteit verhogen zonder te beseffen dat ze er veel meer uit kunnen halen als ze de bedrijfsvoering aanpassen en efficiënter maken.
Mythe 2: Werken in grote batches verbetert het ontwikkelingsproces
Werken in grote batches werkt goed in de productie, maar niet bij productontwikkeling. Grote batches betekenen meer wachtrijen, en meer wachtrijen leiden tot meer onderhanden werk en langere doorlooptijden.
Stel dat een team 300 onderdelen van een machine moet bouwen. Het kan alle onderdelen tegelijk bouwen of in batches van 20 werken. Als het besluit alle onderdelen tegelijk te bouwen:
- De wachtrijen zullen langer zijn
- De doorlooptijden zullen langer zijn
- De feedback zal minimaal zijn
Een plan voor productontwikkeling verloopt mogelijk niet volledig volgens plan. Je zult technische specificaties of een andere producteigenschap moeten aanpassen. De enige manier om deze leercurve te doorlopen is via feedback.
Feedback is de informatie die je opdoet wanneer je het product test en ziet hoe het presteert. Die is nodig om te bepalen of het ontwikkelingsproces op basis van technische factoren moet worden aangepast. Minder feedback leidt tot langere doorlooptijden. Een doorlooptijd is de verstreken tijd tussen het voltooien van het ontwerp en de productie. Je kunt deze meten met behulp van de wet van Little.
In het tweede geval is de batchgrootte 90 procent kleiner.
- Er is weinig tot geen onderhanden werk
- Geen wachtrijen
- Snelle feedback
- Betere kwaliteit en efficiëntie, en kortere doorlooptijden
Veel productontwikkelaars kiezen voor de eerste aanpak, omdat ze denken dat werken in grote batches schaalvoordelen oplevert. Maar niets is minder waar. Het bereiken van een optimale batchgrootte draait om het in evenwicht brengen van transactie- en voorraadkosten.
Als je vandaag genoeg eieren voor een heel jaar inslaat, krijg je er misschien een goede prijs voor, maar de meeste eieren zouden bederven. Met andere woorden: je hebt lage transactiekosten, maar hoge voorraadkosten. De truc om het beste van beide werelden te krijgen, is de juiste balans te vinden.
De optimale batchgrootte bereiken is geen eenvoudige opgave. Deze verschilt per bedrijf. Als je bijvoorbeeld een supermarkt hebt, zijn je voorraadkosten veel hoger dan die van een staalfabrikant. Het komt erop neer dat je een batchgrootte kiest die geen nieuwe knelpunten veroorzaakt en de laagste kosten met zich meebrengt.
Gerelateerd artikel: Hoe creëer je een effectieve feedbacklus voor klanten voor productteams?
Mythe 3: Stop het product vol met functies en klanten zullen er dol op zijn.
Productontwikkelaars gaan er regelmatig van uit dat klanten een product beter zullen vinden naarmate ze er meer functies aan toevoegen. Dat is verre van waar en leidt vaak tot een ongeremde groei van functies. Hoe vaak heb je een product opgepakt en ontdekt dat het te ingewikkeld was om te gebruiken?
Het gebeurt voortdurend. Typische hoofdtelefoons hebben te veel knoppen aan de zijkant, afstandsbedieningen voor tv's zijn moeilijk te gebruiken, lcd-schermen zijn omslachtig om in te stellen en draadloos opladen is nog altijd een fantasie. Toch is het moeilijk een productontwikkelaar ervan te overtuigen het eenvoudig te houden, en dat komt voornamelijk door twee redenen:
1. Productontwikkelaars hebben de neiging om zo veel ideeën te bedenken zonder ze terug te brengen tot de essentie. Ik heb gemerkt dat er meestal geen filter is. Het is alsof een workaholic er niet tegen kan een leeg moment in zijn dag te zien. Die moet het met iets productiefs vullen.
Op dezelfde manier zien productontwikkelaars een kans wanneer ze een lege plek vinden waar ze meer functies aan een product kunnen toevoegen, ongeacht of de consument ze ooit zal gebruiken.
Apple Inc. is een uitstekend voorbeeld van het tegenovergestelde. Het bedrijf stelt eenvoud en elegantie altijd centraal. Productontwikkeling begint bij de eindgebruiker en werkt van daaruit terug naar de technologie. Met andere woorden: de consument stuurt de technologie aan, en niet andersom. Het ontwerpteam van Apple heeft zelfs het laatste woord voordat een product op de markt wordt gebracht.
Het stapelen van onnodige functies in een product voegt geen waarde toe voor de klant. McKinsey meldt dat de meeste bedrijven “de tevredenheid van klanten over de prestaties van het product monitoren [en dat] slechts 44 procent van hen de tevredenheid van klanten meet over de prijs die zij hebben betaald voor de ontvangen waarde.”
Bedrijven die meer vertrouwden op de laatstgenoemde maatstaf deden het beter wat betreft zowel de groei als de stabiliteit van hun winst op korte en lange termijn. Ondertussen liepen bedrijven die zich uitsluitend richtten op productprestaties groei op lange termijn mis.
2. Productontwikkelaars pronken graag met hun expertise. Zozeer zelfs dat ze soms vergeten dat het meer draait om de klantervaring dan om de technische details. Consumenten willen niets meer dan een naadloze gebruikerservaring: een oplossing die moeiteloos werkt.
Daarvoor moeten productontwikkelaars weten wat ze moeten weglaten. Verplaats je in de schoenen van de consument. Zou je een koelkast willen kopen met een ingebouwd audiosysteem? In eerste instantie klinkt dat leuk, maar het is gewoon omslachtig om naar liedjes te luisteren op een koelkast.
Beperk je lijst. De productfuncties die je kiest, moeten essentieel zijn of ervoor zorgen dat het product opvalt. Bedenk dat een product niet af is wanneer je geen functies meer kunt toevoegen; het is af wanneer het verwijderen van een andere functie het product slechter in plaats van beter zou maken.
Hier is een voorbeeld van het proces dat ik gebruikte toen ik samenwerkte met UX/UI-ontwerpers om een eenvoudige en gebruiksvriendelijke app voor winkeliers te bouwen.
- Ga aan de slag met ideevorming, wat in feite betekent dat je de juiste vragen stelt en de ‘hoe’-vragen beantwoordt. Dit is het moment om verder te kijken dan het voor de hand liggende en innovatieve oplossingen te zoeken door ideeën met je team uit te wisselen. We stellen ook een tijdslimiet in, zodat we er niet in doorslaan. Je wilt creativiteit niet inruilen voor tijd en efficiëntie.
- Nadat je je visie op het eindproduct hebt afgebakend, denk ik dat de belangrijkste stap die de meeste ontwikkelaars overslaan, is om aan het einde te beginnen en vervolgens terug te werken door achterwaartse engineering toe te passen. Dat helpt je om alle stappen te bepalen die nodig zijn om je eindproduct te bereiken. De meeste ontwikkelaars beginnen vanaf nul en verliezen uiteindelijk uit het oog wat ze oorspronkelijk hadden gepland.
- Zoals eerder vermeld kan het productontwikkelingsplan veranderen, en dat gebeurt ook. Bij het uitvoeren van alle stappen gaat het brainstormen nog steeds door, maar nu is het toegespitst op de technische details. Zie het als het verfijnen van je oorspronkelijke idee en het naar een hoger niveau tillen.
Mythe 4: Houd je aan het plan, wat er ook gebeurt
Zoals het gezegde luidt: “de best uitgewerkte plannen van muizen en mensen lopen vaak mis.” Dit had niet nauwkeuriger kunnen zijn. Van begin tot eind draait productontwikkeling volledig om vallen en opstaan. Door te experimenteren kun je de mazen herkennen die je eerder over het hoofd zag.
Een onderzoek van MIT onthult het dynamische karakter van productontwikkeling. Lucht- en ruimtevaartingenieurs die aan een subsysteem werkten, bekeken meerdere ontwerpen voordat ze het beste selecteerden. Tijdens het engineeringproces veranderden hun voorkeuren echter op basis van de testresultaten.
Productontwikkeling draait volledig om innovatie. Je begint met een eerste concept van het product en verfijnt het gaandeweg. Misschien wordt de glazen achterkant van de telefoon te warm, of passen de gps-antennes niet door de gebogen randen. Deze inzichten krijg je pas wanneer je begint met testen en experimenteren.
Zoals eerder besproken begint productontwikkeling bij de klant, en niet bij de technologie. Maar hoe bepaal je wat de klant nodig heeft? De meeste ontevreden klanten klagen niet over een product; ze vertrekken gewoon. Erger nog: wat als de voorkeuren van klanten tijdens het ontwikkelingsproces veranderen als gevolg van veranderende markttrends?
Het antwoord op al die vragen is dat je je ontwikkelingsplan aanpast. Dat betekent niet dat plannen nutteloos is; het betekent dat je tot in het kleinste detail nauwgezet te werk moet gaan. Behandel je plan als een hypothese en niet als een wet, want uiteindelijk wil je geen perfect plan, maar een perfect product.
Hier zijn enkele dingen die je kunt doen om je productontwikkelingsplan flexibeler te houden:
- Werk een overkoepelend plan uit. Zie het als een skelet, een basisstructuur die je ontwikkelingsproces zal sturen. Laat de details achterwege, want die zullen uiteindelijk vanzelf op hun plaats vallen. Misschien moet je de basisstructuur zelfs aanpassen om bepaalde details die absoluut essentieel zijn voor je product erin te verwerken.
- Houd rekening met tekortkomingen in je plan. Je kunt onmogelijk alles voorzien. Daarom moet je plan voldoende ruimte bieden om op terug te vallen. Werk alternatieven uit voor de basisstructuur die je al hebt opgebouwd.
Gerelateerd artikel: De beste software voor productplanning
Enkele afsluitende gedachten
Productontwikkelaars hebben zonder twijfel een van de moeilijkste banen ter wereld. Innovatie kost tijd en vereist veel experimenten. Je kunt innovatie niet behandelen als een alledaags proces zoals productie of fabricage. Als productontwikkelaar kan ik bevestigen dat de meeste managers dat niet begrijpen. Ze leven in deze mythes en iemand moet hen uit die droom helpen.
Hoe boeiend productontwikkeling ook is, het kan net zo frustrerend en uitputtend zijn, of je nu voor elke taak iemand hebt of producten beheert zonder een compleet team. De sleutel om aan de top van je spel te blijven, is komaf te maken met de bovenstaande mythes. Als je een nieuwe productmanager bent, hebben we je zojuist talloze kopzorgen en zinloze vergaderingen bespaard. Als je een ervaren professional bent, aarzel dan niet om andere mythes over productmanagement te delen in het gedeelte met reacties hieronder.
Voor meer inzichtelijke artikelen en tips over productmanagement van experts uit de sector, zodat je voorop blijft lopen, schrijf je in voor de nieuwsbrief van The CPO Club.
Of luister naar een van onze podcasts, zoals deze: Momentum cultiveren (met Paul Ortchanian van Bain Public)
