10 redenen voor succesvolle productontwikkeling
Precies een jaar geleden werd ik uitgenodigd voor de Craft Conference in Budapest, waar ik sprak over de 10 belangrijkste redenen waarom productteams falen. Ik had het toen vooral over waarom veel teams zo ineffectief zijn, en ondanks alle beweringen van het tegendeel zijn de meeste organisaties nog steeds niet echt "agile", omdat ze nog steeds volgens het watervalprinicpe werken. Dit jaar werd ik opnieuw uitgenodigd voor de conferentie, dit keer om te spreken over hoe de beste teams die ik ken te werk gaan. Dit artikel is een samenvatting van mijn presentatie.
Na mijn eerste presentatie namen een aantal mensen contact met me op en vroegen om meer informatie. Afgezien van het advies om mijn boek te lezen of een workshop te volgen, had ik niet het gevoel dat ik ze een bevredigend antwoord kon geven. Dat inspireerde me om wat dieper na te denken over de belangrijkste eigenschappen van extreem sterke productteams . Dus stelde ik mijn persoonlijke top 10 samen.
Continuous Discovery en Delivery
Net zoals ik de tien grootste problemen met het watervalmethode heb beschreven, heb ik ook de tien kenmerken van succesvolle teams beschreven met betrekking tot Continuous Discovery en Delivery (ook wel Dual Track Agile, Discovery Sprints of Delivery Sprints genoemd). Wat zijn dus de succesfactoren voor succesvolle productontwikkeling?
1. Bevoegde productteams
De belangrijkste factor is het absoluut fundamentele concept van sterke productteams. Maar wat betekent dat eigenlijk precies?
Ten eerste is het belangrijk dat het team op langere termijn in deze samenstelling blijft bestaan en dat teamleden niet als schaakstukken heen en weer worden geschoven. Als teams innovatief moeten zijn, hebben ze tijd nodig om meer te leren over zichzelf, de technologie, de klanten en de zakelijke context.
Ten tweede is ook de chemie tussen de teamleden doorslaggevend. Dat betekent dat ze elkaar goed genoeg moeten kennen en respecteren, zodat elk teamlid zich op z'n gemak voelt en het aandurft om dingen voor te stellen en zichzelf en anderen steeds weer te motiveren tot betere prestaties.
Ten derde moet een team over een zekere diversiteit aan vaardigheden beschikken, die normaal gesproken bestaat uit productmanagement, user experience design en development. Vaak horen ook data-analyse en gebruikersonderzoek daarbij.
En tot slot is het een voordeel als alle teamleden op dezelfde locatie samenwerken – ook al is dit voor veel bedrijven geen eenvoudig onderwerp. Productmanagers, productdesigners en de developers (of in ieder geval de leider van het developmentteam) zouden hun bureaus naast elkaar moeten hebben staan. Helaas is dat niet altijd haalbaar, maar je kunt het in ieder geval proberen. En om het even duidelijk te stellen: het zijn niet individuele teams op verschillende locaties die een probleem vormen. Het heeft negatieve gevolgen voor de Velocity en vooral voor de innovatie, wanneer de leden van hetzelfde team geografisch van elkaar gescheiden zijn.
2. Productvisie en -strategie
Om echt empowered en autonome productteams te krijgen, moeten de teamleden een goed begrip hebben van de zakelijke context. Dat begint met een heldere en overtuigende productvisie en de weg ernaartoe: de productstrategie.
De productvisie beschrijft de wereld die we in de komende twee tot vijf jaar willen creëren (bij hardware meestal iets langer).
De productvisie moet inspirerend zijn. Een goede productvisie is een van onze meest effectieve recruitmentinstrumenten en motiveert mensen om elke dag met plezier naar het werk te komen. Een inspirerende visie trekt goede vakmensen aan, want zij willen betrokken zijn bij iets dat ertoe doet.
De productstrategie is de volgorde van producten die we willen opleveren op weg naar de realisatie van de visie. Het zou een slechte strategie zijn om met slechts één Release alle betrokkenen tevreden te willen stellen. In plaats daarvan hebben we een geprioriteerde lijst van markten, regio's of persona's en richten we ons erop dat het product en de betreffende markt bij elkaar passen.
Hoe meer productteams je hebt, hoe belangrijker een uniforme visie en strategie zijn, zodat elk afzonderlijk team de juiste beslissingen kan nemen.
Het allerbelangrijkste is echter dat de productvisie inspirerend is en dat de productstrategie bewust wordt gekozen.
3. Bedrijfs Resultaat
Het tweede deel van de zakelijke context die een bevoegd en autonoom team nodig heeft om goede beslissingen te kunnen nemen, is een reeks geprioriteerde bedrijfsdoelen. Het OKR-systeem (Objectives and Key Results) is precies daarvoor bedoeld.
De OKR's weerspiegelen een lijst van specifieke zakelijke problemen die het team moet oplossen. Dit zijn echter geen features. Features zijn slechts potentiële oplossingen voor problemen. Een feature opleveren maakt een team niet succesvol; het oplossen van het daadwerkelijke probleem wel.
De twee principes achter deze methoden voor prestatiemanagement zijn:
1) Teams presteren beter wanneer je ze problemen geeft die ze zelf mogen oplossen, in plaats van ze de oplossingen voor te schrijven.
2) Het team wordt beoordeeld op resultaten, niet op output. Features op een roadmap opleveren is output; een zakelijk probleem oplossen is een resultaat.
4. Een competente productmanager
Helaas hebben de meeste developers nog nooit de kans gehad om met een bekwame productmanager samen te werken. Degenen bij wie dat wel het geval is, zijn ook degenen die erop staan om altijd zo'n persoon in het team te hebben. En nog erger is het feit dat veel developers niet eens precies weten wat de productmanager eigenlijk aan het team zou moeten bijdragen.
Stel je het als volgt voor: om als productteam echte zakelijke problemen op te lossen, is het niet voldoende dat een oplossing alleen technisch werkt of dat de klant de oplossing geweldig vindt. De oplossing moet ook voor je business werken – en dat is vaak het moeilijkste eraan.
Denk eens na over wat dat betekent. Stel je voor dat je voor Uber of AirBnB werkt en je te maken hebt met complexe wetgeving, werkgeversorganisaties en vakbonden. Of neem eBay, dat flink wat beperkingen moest overwinnen om als marktplaats in plaats van als e-commercesite te worden geclassificeerd. Of Tesla, waar aansprakelijkheidsvraagstukken rond de autopilot opgelost moesten worden. Elk bedrijf heeft zijn eigen unieke lijst van dit soort obstakels te overwinnen:
Juridische, financiële, verkoop- en prijsgerelateerde en merk- en marketinggerelateerde obstakels, privacy, beveiliging, samenwerkingsvoorwaarden enzovoort.
Helaas is de enige persoon die dit allemaal begrijpt de directeur, en in dat geval is het begrijpelijk waarom hij er zoveel moeite mee heeft om het team te machtigen om zelf de juiste beslissingen te nemen.
Er zijn drie manieren waarop een team kan werken. De eerste is dat de directeur of een andere leidinggevende alles beslist. De tweede is dat een productmanager een grote vergadering belegt en alles uitdiscussieert met de volledige directie („Design By Committee"), wat doorgaans slechte resultaten oplevert. De derde mogelijkheid is dat de productmanager zijn werk doet, zich verdiept in de obstakels en deze doorgeeft aan de teamleden, zodat zij de oplossing voor het probleem zelf kunnen uitwerken .
Combineer dat met een goed begrip van technologie en gedegen kennis van de gebruikers en klanten, dan kun je hopelijk inzien waarom dit een zware maar ook absoluut essentiële rol is voor een productteam, vooral als het team een zinvolle mate van autonomie moet genieten.
5. Oplossingen door samenwerking
„Samenwerking" is hier geen modewoord. Ik bedoel er simpelweg mee dat de drie gebieden product, design en ontwikkeling samen zouden moeten werken om een probleem op te lossen, in plaats van dat de productmanager „requirements" doorgeeft, de designer alles mooi verpakt en de ontwikkelaars de code schrijven die van hen gevraagd wordt. De reden hiervoor is dat technologie en functionaliteit bij goede oplossingen elkaar vooruit stuwen. Technologie maakt bepaalde designopties überhaupt mogelijk, net zoals het design de keuze van technologie beïnvloedt. En de designbeslissingen beïnvloeden de functionaliteit – en andersom.
Technologie, user experience design en functionaliteit zijn met elkaar verweven. Goede oplossingen ontstaan door een constant heen en weer, een permanent geven en nemen tussen de drie gebieden.
Dit is ook de belangrijkste reden waarom teams die op dezelfde locatie samenwerken, in de kern eigenlijk altijd beter presteren dan teams waarbij dat niet het geval is.
6. Product Discovery: Snel Leren
Geweldige producten hebben veel te maken met het vermogen van een team om snel veel ideeën uit te proberen. We willen zo snel mogelijk de goede van de slechte ideeën scheiden. Product Discovery omvat een hele reeks technieken die ons helpen om snel te ontdekken welke ideeën geweldig zijn en welke niet zo goed. Sommige ideeën zijn echt fantastisch en andere minder. Sommige zijn risicovol en sommige zijn kostbaar. Soms hebben we harde bewijzen nodig, andere keren alleen aanwijzingen.
Mensen beschrijven dit op de meest uiteenlopende manieren. Sommigen houden zich aan het motto „fake it before you make it", wat zoveel betekent als „doe alsof, tot het werkt". Anderen benadrukken dat je dingen moet bouwen die niet schaalbaar zijn. Het belangrijkste is dat we snel leren en waste minimaliseren (oftewel verspilling).
Een ontwikkelteam een echt product laten bouwen en op de markt brengen om een idee te testen, is zo ongeveer de langzaamste en duurste manier om iets te leren.
7. Focus op de belangrijkste risico's
Bij de Product Discovery zijn er een aantal belangrijke punten waar je rekening mee moet houden.
Allereerst moeten we ons richten op de vier belangrijkste risico's:
Waarde – zou iemand dit product willen kopen of gebruiken?
Gebruiksvriendelijkheid – zouden klanten begrijpen hoe ze het moeten gebruiken?
Haalbaarheid – kunnen onze ontwikkelaars het product bouwen met de beschikbare technologie, tijd en vaardigheden van het team?
Stakeholders – zijn alle betrokkenen binnen het bedrijf het eens met de voorgestelde oplossing?
Product Discovery is het zoeken naar goede antwoorden op deze vier vragen. Wanneer we die gevonden hebben, hebben we het nodige bewijs en zijn we er zeker van dat het ontwikkelteam een kwalitatieve en schaalbare oplossing kan bouwen en opleveren.
8. De rol van het MVP
Het concept van het Minimum Viable Product is een van de belangrijkste concepten in productontwikkeling, en toch is het ook een van de meest verkeerd gebruikte en verkeerd begrepen concepten.
Generaliseren is altijd gevaarlijk, maar ik ga nu even mijn nek uitsteken en beweren dat een MVP nooit een product zou moeten zijn. Elke keer dat ik een team tegenkwam dat met veel tijd en geld een MVP had gebouwd, kon ik dat team achteraf laten zien hoe ze hetzelfde leereffect hadden kunnen bereiken met veel lagere kosten en veel minder verspilling.
Een MVP is dus een experiment – een test. Normaal gesproken is het een soort prototype. Vaak is het een prototype voor de gebruiker, maar soms ook een live-data-prototype of wordt het gebruikt voor haalbaarheidsstudies. En soms is het een mix van deze dingen. In elk geval is het altijd slechts een klein deel van de ontwikkeling van een daadwerkelijk product.
9. Product Delivery: Geen compromissen bij de release
Het gaat me er hierbij niet om de developers te vertellen hoe ze software moeten ontwikkelen en releasen. Integendeel. Een probleem dat ontstaat wanneer een ontwikkelteam het MVP moet bouwen, is dat het team zich vaak gedwongen voelt om software te releasen waar ze niet achter staan. Ze staan er niet echt volledig achter. Misschien zijn er problemen met de betrouwbaarheid, schaalbaarheid of performance, maar de productmanager blijft gewoon zeggen: „Het is maar een MVP, ontspan je!"
Ik zeg alleen maar dat je geen concessies moet doen als het gaat om software waar klanten op vertrouwen om hun bedrijf draaiende te houden. Er zijn veel goede Product Discovery technieken voor het testen van MVPs, waarmee onze klanten, onze omzet, onze reputatie en onze medewerkers beschermd worden.
Gebruik dus je best practices en release alleen producten wanneer je het volste vertrouwen hebt in die release .
10. Geobsedeerd zijn door de klant
Dit laatste punt gaat een iets andere richting op. Bij bijna elk bedrijf waar ik kom, vertelt men me hoeveel ze van hun klanten houden. Dat maakt meestal deel uit van de kernwaarden of de missie van het bedrijf. Dat zeggen is makkelijk, maar er ook echt naar handelen is een stuk moeilijker.
Dat merk ik altijd vrij snel als ik met een team praat. Hoe gaat het team ermee om als er een probleem met de klant optreedt? Hoe urgent is dat? Neemt het team contact op met de klant om hem, indien nodig, beter te kunnen begrijpen? Kennen de teamleden de klanten bij naam? Welke relatie hebben ze met de klanten? Werken de klanten hen eerder op de zenuwen of zijn ze voor de teamleden misschien zelfs meer als collega's?
De beste manier om echte empathie en inzet voor de klant te wekken, is dat de teamleden (vooral de developers) direct contact opnemen met de klant.
Ik hoop dat dit je helpt om een beter gevoel te ontwikkelen voor wat geweldige productteams kenmerkt.
Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.
Outcome vs. Output
=> Het Minimum Viable Product (MVP) begrijpen
