Mislukte producten
Opmerking: dit artikel is de schriftelijke versie van een presentatie die ik heb gegeven voor ontwikkelaars op de Craft Conference en voor productmanagers en designers op Mind The Product.
In dit artikel wil ik het hebben over de oorzaken waarom zoveel producten falen.
Waarom falen producten en productlanceringen?
Bij de meeste bedrijven zie ik dezelfde fundamentele manier van werken, en die is niet eens in de buurt van de werkwijze van echt goede bedrijven te vergelijken.
Laat me nog een waarschuwing meegeven, want deze discussie kan behoorlijk deprimerend zijn, vooral als je er zelf direct mee te maken hebt. Mocht dat het geval zijn, dan vraag ik je gewoon om even vol te houden.
Het productontwikkelingsproces
Laten we eerst eens kijken naar het proces dat de meeste bedrijven nog steeds gebruiken om hun producten te ontwikkelen. Ik zal proberen het voorlopig niet te beoordelen, maar simpelweg het proces te beschrijven:
Alles begint met ideeën. In het merendeel van de bedrijven komen deze ideeën van de directie, de belangrijkste stakeholders, de bedrijfseigenaren of grote klanten (of potentiële klanten). In elk geval is er een hele reeks dingen die we voor de verschillende onderdelen van een bedrijf moeten doen.
Vervolgens worden de ideeën in de meeste bedrijven geprioriteerd in een Roadmap en dat heeft twee redenen: Ten eerste wil men dat er eerst aan de meest waardevolle zaken wordt gewerkt, en ten tweede wil men kunnen inschatten wanneer deze zaken klaar zullen zijn.
Daarvoor is er vrijwel altijd een kwartaal- of jaarlijkse planningssessie, waarin het management de ideeën doorneemt en een Product Roadmap uitonderhandelt. Om alles echter te kunnen prioriteren, hebben ze eerst een soort Business Case nodig voor elk item.
Sommige bedrijven werken formele Business Cases uit, andere eerder informele, maar bij beide gaat het erom de volgende twee dingen te achterhalen:
1) Hoeveel geld kunnen we hiermee verdienen?
2) Hoeveel geld of tijd zal het kosten? Uit deze informatie wordt vervolgens de Roadmap opgesteld, meestal voor het volgende kwartaal, maar soms zelfs voor een heel jaar.
Op dit punt krijgen product en technologie het startschot en normaal gesproken worden de werkzaamheden dan op volgorde van prioriteit uitgevoerd.
Wanneer een idee de top van de prioriteitenlijst heeft bereikt, spreekt de productmanager als eerste met de stakeholders om het idee uit te werken en "requirements" te formuleren.
Dat kunnen User Stories zijn of een soort functionele specificatie; het doel moet in elk geval de communicatie zijn met de designers en ontwikkelaars die het product gaan bouwen.
Zodra alle requirements er zijn, wordt het User Experience Design team (ervan uitgaande dat zo'n team bestaat binnen het bedrijf) gevraagd om zich bezig te houden met het Interaction Design, Visual Design, en in het geval van hardware, met het productdesign.
Ten slotte bereiken de requirements en designspecificaties de ontwikkelaars. Dit is normaal gesproken het punt waarop Agile in beeld komt.
De rol van de developers in het ontwikkelproces
De ontwikkelaars verdelen het werk vervolgens in iteraties, die in Scrum "Sprints" worden genoemd. Het duurt dan ongeveer 1-3 Sprints om het idee te realiseren.
In het beste geval zijn QA-tests in de Sprint geïntegreerd. Zo niet, dan zal het QA-team nog een aantal tests uitvoeren om vast te stellen of het idee naar wens werkt en of er geen andere problemen optreden (ook wel regressie genoemd).
Zodra je groen licht krijgt van het QA-team, wordt het idee eindelijk gedeployed en bereikt het de gebruiker.
Vrijwel alle bedrijven waar ik binnenkom, of ze nu groot of klein zijn, werken al jarenlang op deze manier. En toch klagen al deze bedrijven consequent over het gebrek aan innovatie en de lange tijdspanne voordat een idee eindelijk in handen van de klant terechtkomt.
Agile vs. Waterval
Het is je misschien opgevallen dat, hoewel ik Agile heb genoemd en tegenwoordig bijna iedereen zogenaamd agile werkt, het zojuist beschreven proces in feite een waterval-proces is. Eerlijk gezegd moet ik zeggen dat de ontwikkelaars vaak zoveel uit Agile halen als binnen dit watervalproces mogelijk is.
Oké, dit is misschien de aanpak van de meeste teams, maar waarom is dit altijd noodzakelijkerwijs de oorzaak van zoveel problemen?
Waarom falen daardoor zoveel producten?
Ik ga je proberen te laten zien waarom deze veelgebruikte manier van werken in de praktijk meestal verantwoordelijk is voor het falen van producten.
Ik zou nu eindeloos kunnen praten over de problemen met dit proces, maar ik ga simpelweg de Top 10 van de ernstigste problemen met deze werkwijze opsommen. Ook al is elk van deze tien problemen op zich al zeer ernstig en zou het een team ten val kunnen brengen, de meeste bedrijven hebben veel of zelfs al deze problemen tegelijkertijd.
1) Laten we bovenaan beginnen – de bron van ideeën. Dit model leidt tot omzetgedreven aanbiedingen en stakeholdergedreven producten. Hier valt veel over te zeggen, maar voor nu wil ik gewoon zeggen dat dit niet de beste bronnen voor productideeën zijn. Een ander gevolg van deze aanpak is het gebrek aan empowerment van het team, want bij deze aanpak zijn ze alleen verantwoordelijk voor de uitvoering – huurlingen.
2) Laten we het hebben over de zwakte bij de Business Cases. Begrijp me niet verkeerd, ik vind business cases op zich prima, in ieder geval voor ideeën die een grotere investering vergen. Maar de manier waarop de meeste bedrijven ze op dit moment opstellen om tot een geprioriteerde roadmap te komen, is echt belachelijk. Herinner je je de twee dingen die aan elke business case ten grondslag liggen? Hoeveel je gaat verdienen en hoeveel het gaat kosten? Op dit moment kunnen we dat simpelweg niet weten, omdat we geen flauw idee hebben van ook maar een van deze twee factoren.
We kunnen simpelweg niet weten hoeveel we gaan verdienen, want dat hangt voornamelijk af van hoe goed onze oplossingen zullen zijn. Als het team fantastisch werk levert en extreem succesvol is, kan dat de hele koers van het bedrijf veranderen. Aan de andere kant is de trieste waarheid dat de meeste productideeën helemaal niets opleveren. En dat is geen overdrijving. Ik bedoel echt niets. In ieder geval is een van de belangrijkste lessen bij productontwikkeling om te weten wat we niet kunnen weten. En we kunnen op dit punt simpelweg nog niet weten hoeveel geld we gaan verdienen.
Net zo min hebben we enig idee wat de ontwikkeling van het product ons gaat kosten. Zonder een concrete oplossing is dat ook behoorlijk moeilijk in te schatten. Veel ervaren ontwikkelaars zullen weigeren om zo vroeg een inschatting te geven, hoewel sommigen ook het goede oude „T-shirt" compromis zullen sluiten: zeg op z'n minst of het „Small, Medium, Large of Extra Large" is!
Bedrijven willen nu eenmaal geprioriteerde roadmaps en daarvoor hebben ze een systeem nodig om de ideeën te kunnen beoordelen. Dus spelen mensen het Business Case-spelletje mee.
3) Dan volgt een nog groter probleem. Bedrijven zijn dol op Roadmaps. Ik heb al veel roadmaps gezien en de meeste daarvan zijn in principe gewoon geprioriteerde featurelijsten. Marketing heeft deze feature nodig voor een campagne. Sales heeft deze feature nodig voor een nieuwe klant. Iemand wil PayPal integreren. Ik denk dat je begrijpt wat ik bedoel.
Maar er is een probleem en het is misschien wel het grootste van allemaal. Ik noem het de „twee ongemakkelijke waarheden over producten".
De eerste waarheid is dat minstens de helft van onze ideeën gewoon niet zal werken. Er zijn zoveel redenen waarom een idee niet werkt. Het meest voorkomende is waarschijnlijk dat klanten gewoon niet zo enthousiast zijn over het idee als wij. Dus gebruiken ze het product niet. Soms willen ze het wel gebruiken, maar is het zo ingewikkeld dat het meer ergernis dan nut oplevert. Het resultaat is dus hetzelfde: de klanten gebruiken het niet. Soms zouden klanten het product geweldig vinden, maar blijkt er veel meer werk mee gemoeid dan we dachten en hebben we simpelweg niet het geld en de tijd om het te ontwikkelen.
Ik verzeker je dat minstens de helft van de ideeën op je roadmap niet zal opleveren wat je ervan had gehoopt. En trouwens, de echt goede teams gaan ervan uit dat minstens driekwart van de ideeën niet werkt zoals we dachten.
Alsof dat nog niet erg genoeg is, is de tweede waarheid dat je zelfs bij ideeën die echt potentie hebben, normaal gesproken meerdere iteraties nodig hebt voordat je ze zo ver hebt uitgewerkt dat ze daadwerkelijk de benodigde bedrijfswaarde opleveren. We noemen dat „Time To Money".
Het belangrijkste dat ik heb geleerd als het gaat om productontwikkeling is dat je aan deze twee waarheden simpelweg niet kunt ontsnappen – hoe slim je ook bent. Ik heb het grote geluk gehad om met veel echt uitzonderlijke productteams te mogen werken. Het verschil zit in hoe je met deze waarheden omgaat.
4) De rol van het product in dit model: eigenlijk zou ik niet eens van het product als rol spreken. In feite is het eerder een vorm van projectmanagement. In dit model gaat het meer om het verzamelen van requirements en deze documenteren voor de ontwikkelaars. Geloof me, dit heeft niets te maken met modern productmanagement.
5) Vergelijkbaar is het met de rol van design. Op dit punt is het al veel te laat om door middel van design echte waarde te creëren. Dan helpt men zich graag met het zogenaamde „Lipstick on the pig"-model. Het kwaad is al geschied en we proberen het alleen maar te verdoezelen. De UX designers weten dat dit niet goed is, maar proberen alles er zo goed en consistent mogelijk uit te laten zien.
6) Waardoor je bij dit model de meeste kansen misloopt, is waarschijnlijk het feit dat de ontwikkeling pas zo laat in het proces wordt betrokken. Men zegt dat als je je ontwikkelaars alleen gebruikt om code te schrijven, je de helft van de waarde mist die ze je zouden kunnen bieden. Ontwikkelaars zijn normaal gesproken de beste bron voor innovatie en toch worden ze niet eens bij het proces betrokken.
7) Niet alleen de ontwikkelaars, maar ook de principes en belangrijkste voordelen van Agile komen hier veel te laat in het spel. Teams die Agile op deze manier gebruiken, krijgen slechts ongeveer 20% van de waarde en het potentieel van agile methoden. Hier heeft Agile alleen betrekking op de oplevering, maar de rest van de organisatie en de context is nog steeds verre van agile.
8) Het hele proces is erg projectgericht. Een bedrijf financiert projecten, stelt personeel aan voor projecten, drijft projecten voort en voert ze uit. Helaas zijn projecten echter slechts Output, terwijl het bij productontwikkeling gaat om Outcome. Dit proces leidt onvermijdelijk tot verweesd achtergelaten projecten. Oké, er is uiteindelijk iets gereleased, maar het vervult niet het eigenlijke doel. Wat heeft het dan voor zin? Dit is een groot probleem en komt dicht in de buurt van hoe we onze producten bouwen.
9) De grootste zwakte van het oude watervalprocces is en was altijd het feit dat het hele risico pas aan het einde aan het licht komt. De validatie door de klant vindt simpelweg veel te laat plaats.
Je hebt hopelijk al gehoord van Lean Startup methoden, die zo ongeveer het exacte tegenovergestelde hiervan zijn. Het hoofdprincipe ervan is om verspilling te minimaliseren en de grootste verspilling is om een feature of product te ontwerpen, bouwen, testen en deployen, om er vervolgens achter te komen dat het niet nodig is. Ironisch genoeg denken veel teams dat ze de principes van Lean toepassen, maar volgen ze eigenlijk alleen het hierboven beschreven proces. En dan leg ik ze uit dat ze hun ideeën op de duurste en langzaamste manier uittesten die we kennen.
10) En tot slot, terwijl we bezig zijn met het proces en onze tijd en ons geld verspillen, vormen de opportuniteitskosten voor de dingen die een organisatie in plaats daarvan had kunnen en moeten doen, het grootste verlies. Die tijd en al dat geld krijgen we nooit meer terug.
Ik ben niet erg verbaasd dat zoveel bedrijven zoveel geld en tijd investeren en er zo weinig voor terugkrijgen. Ik had je gewaarschuwd dat dit deprimerend zou kunnen worden.
Het goede nieuws is dat ik je kan verzekeren dat de beste teams absoluut niet zo werken als ik heb beschreven.
Samenvatting
Ik heb al veel artikelen geschreven over de verschillende aspecten van de beste teams. Bij Product Discovery gaat het erom hoe we succesvolle oplossingen voor onze problemen vinden. Het is een actieve en doorlopende manier van samenwerking tussen de gebieden product, user experience design en ontwikkeling. [Continuous Discovery en Continuous Delivery](/nl/product-owner/discovery-vs-delivery/ "Discovery vs. Delivery) lopen parallel. Features op roadmaps (output) worden vervangen door bedrijfsproblemen die opgelost moeten worden (outcome). Het doel is dat het product zo goed mogelijk aansluit bij de vraag van de markt (Product/Market Fit).
Als jouw bedrijf nog steeds vasthoudt aan dit oude, achterhaalde proces, kun je hopelijk nu licht in de duisternis brengen en fris de toekomst instappen. En ik hoop dat je daarin slaagt voordat je wordt ingehaald door een startup of concurrent die veel sneller en effectiever is dan jouw bedrijf.
Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.
Voorbeeldtabel voor de Product Backlog
=> Zo kun je User Stories in de Product Backlog als tabel weergeven.
Het Product Goal Canvas
=> Bepaal je productdoel met het Product Goal Canvas.
